Cloudron Forum

@Teiluj Thanks for posting this. I am definitely interested in packaging it but am vv busy. I shall try, if nobody else is interested. Will need a week or so.

@james Thanks, James! I should have fact that myself, but the way things seem to be going in the UK now, I was quite prepared to believe it.

Sorry about that, everybody! My bad.

0.2.0 is out: please update, and rotate your keys if you ran 0.1.0.

Package 0.2.0 moves HarnessRouter Community Edition from 0.37.13 to 0.41.16. It is a security release.

0.1.0 was affected by upstream advisories fixed in that span:

• GHSA-2464-fhr4-w9xw and GHSA-2xp9-vwfh-vxw4: remote code execution through the console's image optimiser,
  with no sign-in needed. The optimiser is now off.
• The critical fix in upstream 0.37.17: anyone holding an API key could read any file as root, including the
  internal key, the secret key, provider keys and the databases.

If you installed 0.1.0, upstream asks you to rotate:

• the secret key (HR_SECRET_KEY; in this package /app/data/.secrets/secret-key),
• the console password,
• every provider key and every API key,
• MCP server tokens, if untrusted agents ran.

If auto-update is on, your install has already moved or will at the next check. If it is off, update from the
app's Updates tab. Cloudron takes a backup first; keep it, because rolling back to 0.1.0 is not clean (some stored
tokens move to a form 0.37.13 cannot read). The first start reinstalls the agent tools once, so allow several
minutes before the console answers.

Also in 0.2.0: downloads at first start and environment builds run as firewalled unprivileged users, root is
firewalled from Cloudron's internal network (an MCP server must be reachable at a public address or through this
Cloudron's HTTPS front door), and the listing now says plainly that this package is unofficial and not supported
by the HarnessRouter project.

Full notes: https://github.com/OrcVole/harnessrouter-cloudron/blob/main/CHANGELOG.md

Do you want to give your wi-fi password to the government?

@timconsidine said:

Don’t try my version

Yours gave us some inspiration, Tim. The new package we released is pretty good. We don't mind people trying it at all. It should work well.

A concrete use case for the gpu capability, from a package on the community catalogue (ca.cloudron.io).

WeaveSignal (top.weavesignal.cloudronapp, AGPL-3.0) is an internet radio and video studio: a live room with presenters and callers, a mixing desk, playout and the listener streams in one app. Its desk can also make a live video stream: it cuts between the cameras of whoever is speaking and encodes AV1 into CMAF HLS behind the same profanity delay as the sound.

• Today, in the Cloudron package, the video path runs on the CPU (SVT-AV1). That is fine at one 480p rung: four cameras took the desk from 11 % to 27 % of one core on a workstation.
• With an NVIDIA GPU the desk uses NVENC for AV1, one encoder session per rung (a GeForce card allows 12 per machine). On our Compose bundle that is --device nvidia.com/gpu=all, which is CDI already. In the Cloudron app it would be the proposed gpu capability, with nothing else on the app's side: the desk tries NVENC and falls back to SVT-AV1 on its own.
• What a GPU buys a station: several rungs (480p, 360p, 240p) at no extra CPU. It also leaves the CPU free for the audio. That matters more to us than the video, because the desk and Liquidsoap hand audio on every 10 to 20 ms, and a starved host is heard at once.

We can test it on real hardware: a GeForce RTX 5090 with driver 615.78 and the NVIDIA Container Toolkit, on a Cloudron test install, as soon as there is a build or a branch to try. I can report back here with the encoder's session count and the CPU figures with and without the capability.

A question on vaapi: does it hand the container the render node (/dev/dri/renderD128) with the permissions an unprivileged process needs to encode, not only decode? Intel Arc and recent AMD cards encode AV1 through VA-API, and we could support those with the capability that exists today.

Thank you for considering it, and for Cloudron.

@timconsidine said:

why Prosody not Snikket ?

Hi, Tim!

At the time, our main candidate was ejabberd, but it provd too difficult. A couple of valiant souls had already attempted packaging ejabberd for Cloudron without success. It has a very complex config file, Cloudron doesn't have Erlang in its base image.

We didn't really look at Snikket, but:

• Logins: Snikket runs on Prosody but makes its own decisions. Accounts are created by invitation and managed in Snikket's own web portal. As far as I know it has no LDAP or outside login source, which is exactly what our package is built around: every Cloudron user already has an account. Making Snikket use Cloudron logins would mean fighting the product's whole design.
• Infrastructure: Snikket expects to run its own certificate handling, reverse proxy and TURN relay (the server that lets calls through firewalls). Cloudron provides all three, so we would be removing parts of Snikket rather than packaging it.
• Domains: Snikket needs its main domain plus groups. and share. subdomains. The alias trick would probably cover those, so this one isn't a blocker.
• Snikket's real strength: its own branded mobile apps and a smooth invite-a-friend flow. That matters most for setups with people outside the server's user base, and our use case is Cloudron users.

Hello all,

WeaveSignal is a new open-source (AGPL-3.0) internet radio and video station that runs as one Cloudron app. It puts the live studio in the same installation as playout and the stream:

• Presenters, guests and callers talk in one room from a browser (LiveKit inside the app). Each person hears a mix of everyone but themselves.
• Listeners call in from the station's page: no phone number. A screener talks to them off air and sends them to the desk.
• Liquidsoap 2.5 fills the hours between shows from a schedule. There's a dead-air fallback.
• Listeners get Ogg Opus, an optional MP3 stream, and HLS video when it's on.
• A live chat with moderation, podcast feeds and show cards.
• A desktop studio app (Linux, Windows) runs the desk and the screener.

Install in a few clicks: it's listed on ca.cloudron.io (https://ca.cloudron.io/app/top.weavesignal.cloudronapp). In your dashboard, open App Store → Community apps, paste
https://forgejo.weavesignal.top/WeaveSignal/weavesignal/raw/branch/main/deploy/cloudron/CloudronVersions.json
and install (Cloudron 10.0 or later). Updates arrive through the same catalogue, and Cloudron's backups cover the station's data and database.

See it first: a three-and-a-half-minute video of a show going to air, a caller screened and a swear dumped, on https://weavesignal.top, and everything it does on https://weavesignal.top/features/

What the package needs:

• Four domains: the studio behind Cloudron's login, plus the listener stream, the room's signalling and the public pages.
• A UDP port for the room's media (7882 by default) and TCP 15349 for TURN over TLS, because Cloudron's own TURN holds 5349.
• PostgreSQL and sendmail.
• A 1.5 GiB memory limit. It measured 0.5–0.7 GiB under a test load.

Things worth knowing:

• Live audio needs a server that isn't overloaded. On a busy shared Cloudron the listener feed ran dry; on an idle 4-vCPU server it held for 13 hours.
• TURN over IPv6 doesn't work yet. LiveKit's built-in TURN refuses clients that reach it over IPv6, and a Cloudron app domain gets an AAAA record whenever the server has IPv6. Relay-only clients on IPv6 networks can't join (upstream: livekit/livekit#5131).
• It's release 1.0.0 and new. What is proven and what isn't is on the status page: https://weavesignal.top/docs/reference/release-one-status/

Site: https://weavesignal.top · Docs: https://weavesignal.top/docs/ · Install on Cloudron: https://weavesignal.top/docs/how-to/install-on-cloudron/ · Source and issues: https://forgejo.weavesignal.top/WeaveSignal/weavesignal · Mirror: https://github.com/OrcVole/WeaveSignal · Demo station (listen-only, itself a Cloudron install of this package): https://demo.weavesignal.top

I'd be grateful for testers and bug reports, here or on the issue tracker.

Hi @timconsidine, thanks for packaging Docassemble. I couldn't actually find your announcement for your community package, so am posting this here.

Installing 0.0.2 from your versions URL fails before the app starts:

cloudron install --versions-url https://communityapps.appx.uk/cloudron-docassemble/CloudronVersions.json -l docassemble.example.com

App installation error: Installation failed: Network error downloading icon: Hostname/IP does not match certificate's altnames: Cert does not contain a DNS name

The cause is a typo in the manifest's iconUrl. The host is missing a "y":

"iconUrl": "https://communitapps.appx.uk/cloudron-docassemble/logo.png"

It should be https://communityapps.appx.uk/cloudron-docassemble/logo.png, which serves the logo fine (HTTP 200). The misspelt name resolves to a host whose certificate doesn't match, so Cloudron aborts the install while fetching the icon.

Seen on Cloudron 10.1.6. Correcting iconUrl and republishing CloudronVersions.json should fix it.

Workaround for anyone else hitting this: save the manifest from the versions file with the corrected iconUrl as CloudronManifest.json. Then run cloudron install --image forgejo.tcjc.uk/cca/cloudron-docassemble:0.0.2 -l <location> from that folder. It installs and runs healthy. The catch is that the app then isn't tied to your versions URL for updates.

I had to research terrain theory:

"Terrain theory" isn't a codified framework I can point you to in the literature — it's a working label for a real and fairly mature set of ideas: treat the model as an untrusted actuator and make the environment, not the model, the thing that bounds harm.
The line I'd anchor it on: instructions are weather, the environment is terrain. Weather changes (distribution shift, jailbreak, prompt injection, a bad generation, a compromised fine-tune). Terrain doesn't. If your safety story depends on the model intending to behave, you have built a weather-dependent defence.
The canonical intellectual ancestors are Saltzer & Schroeder's 1975 protection principles (least privilege, complete mediation, fail-safe defaults, separation of privilege), capability-based security, and — more recently — the AI-control literature's distinction between alignment (make it want to behave) and control (make it unable to misbehave). Sun Tzu's 地形 chapter is the ancestor of the metaphor: don't fight the war on the enemy's ground.

@timconsidine said:

I'm very reluctant to run AI tools on my primary device

From our experience, that is a wise choice. AI has repeatedly "found itself" operating outside of its designated areas, i.e. in No Go zones. It is able to provide a plausible excuse when it is spotted. Also, "mistakes were made", like deletion of half an archive.

The difficult thing is that once you start using AI, it becomes so helpful that the same machine becomes your main machine.

@james It is difficult to remember, but we might have listed on ca.cloudron.io then deleted the listing in order to redo a better attempt. Maybe that is what happened.

@timconsidine

Hey Tim, thanks for looking and commenting!

The problem. Coding agents like Claude Code, Codex and OpenCode are like very capable helpers who only work at a keyboard. You type to them in a terminal, they read files, run commands and write code. That works when you are sitting there. It doesn't work when your app or script wants to hand them a job.

What HarnessRouter does. It's a front desk for those helpers. Your program walks up to the desk and says "please do this task" through one standard API. HarnessRouter then:

• picks the helper you asked for (Codex, OpenCode or Claude Code);
• gives it a private room to work in (its own folder and its own user account);
• lets it think with whichever AI model you've connected;
• streams back what it's doing, and keeps a written record of everything it did.

Later you can come back and say "carry on from where you left off", and it picks up the same job.

Why that's useful. You can build things on top of agents without wiring each tool up yourself:

• a support tool that drafts replies;
• a script that reviews code every night;
• a feature in your own product that "does the task for the user".

One API covers every helper, and you can swap helpers or models without rewriting your code.

What the Cloudron package adds. These helpers can run commands, so you don't want them poking around your server. Our package keeps them fenced in:

• One room each. Every job runs as its own user and can't see the others.
• No keys in hand. The helpers never hold your real AI provider key. HarnessRouter holds it and passes requests along for them.
• Fenced off from your server. A firewall stops them reaching your other apps, your internal network or email. They can still reach the internet, which they need for models and code repositories.
• Cloudron housekeeping. You get backups, one-click updates and a generated password.

In one line: HarnessRouter turns "an AI agent in a terminal" into "an AI agent service your programs can call", and the Cloudron package makes running it on your own server reasonably safe.

@robi, you have it!

https://forum.cloudron.io/topic/16224/harnessrouter-community-package-now-available

TL;DR: HarnessRouter puts one OpenAI Responses-compatible API and a web console in front of agent command-line tools (OpenCode, Codex, Claude Code): your scripts or product send a request, HarnessRouter runs the agent, streams its progress and keeps the transcript. It is now packaged for Cloudron, with every agent session running as its own unprivileged user behind an egress firewall, and your provider keys held by HarnessRouter rather than by the agents. Built and tested on Cloudron 10; unofficial and community maintained.

Headline features

• One API for several agent tools: call OpenCode, Codex or Claude Code through the same OpenAI Responses-style endpoint, with streaming.
• A web console to run turns by hand, read transcripts, manage model connections and create API keys for your own scripts.
• Bring your own model: Anthropic, OpenAI, OpenRouter, or any OpenAI-compatible endpoint, including one you host yourself.
• Sessions resume: a later request can continue an earlier one, and each session keeps its own working directory.
• API keys for programs, so a script can drive agents without a console login.

Links

• Project homepage: https://harnessrouter.ai
• Upstream repo: https://github.com/HarnessRouter/harnessrouter
• 🧱 Cloudron package repo: https://github.com/OrcVole/harnessrouter-cloudron
• What the package does to contain agents, as measured: https://github.com/OrcVole/harnessrouter-cloudron/blob/main/docs/CONTAINMENT.md

How to install

The easiest route is the dashboard. In the App Store, click the Add custom app dropdown (top right) and choose Community app, then paste the CloudronVersions.json URL below into the box that pops up. Apps installed this way receive automatic updates.

https://ca.cloudron.io/app/io.github.orcvole.harnessrouter

Or with the CLI:

cloudron install \
  --versions-url https://raw.githubusercontent.com/OrcVole/harnessrouter-cloudron/main/CloudronVersions.json \
  --location harnessrouter.example.com

Minimums: a 4 GiB memory limit, measured against ten agent sessions running at once (about 0.2 GiB for the app plus about 0.25 GiB per active session), and the localstorage addon. The package asks for the net_admin capability, which it uses only for the agents' firewall; Cloudron grants it with the install. The first start downloads the agent tools under their own licences and takes several minutes; the console does not answer until that finishes.

First run: the console password is generated on first start. Open the app's Web Terminal, run cat /app/data/.secrets/admin-password, sign in as harnessrouter, then change the password on the Profile page. Add a model connection in the console, and create an API key there for your own scripts.

For users

Why try it: if you want to put coding agents behind your own product, or run them from scripts, HarnessRouter gives you one API and keeps the transcripts, so you do not have to wrap each tool yourself. Cloudron wins: backups of your transcripts, settings and keys, one-click updates, and agents kept apart from the rest of your server. Good fit for agent work driven by programs; probably not if you only want a chat window.

🧰 For packagers: what we learned

What helped: upstream already ships a broker mode, written for its hosted service, in which agents never hold the real provider key. The package switches it on and cannot be talked out of it.

What was tricky: containment. Each session already runs as its own user upstream; the package moves those users to a high uid range and adds an IPv4 and IPv6 owner-match firewall, so agents reach the internet, DNS, HarnessRouter's own API and nothing on Cloudron's internal network or the mail ports. The app refuses to start if the firewall cannot be installed. Agents can traverse the data directory to run their tools, so anything there with a world-read bit is readable by name: the package now makes the settings file root-only at every start, and its containment test checks every file, not a list.

Still rough: session workspaces are kept outside the backup on purpose (about 50 MB each, rebuilt from each session's checkpoint, which is backed up). Streaming through the reverse proxy was proven for framing, not yet for event-by-event timing against a slow model.

️ For the Cloudron team

Maintenance burden: upstream releases often; the package pins the agent tool versions and moves them together on each bump. Why it suits the App Store: agent infrastructure is in demand, the upstream is Apache-2.0, and it pairs with the AI apps already here. Friction worth knowing: we tried proxyAuth as an optional wall and measured that with supportsBearerAuth any request carrying an Authorization: Bearer header passes it, whatever the token, and that the addon takes the app's own /login; for an app with its own login it added nothing, so the package keeps HarnessRouter's own login.

For HarnessRouter's developers

Thank you for broker mode: it made a careful package possible. Making it the self-hosting default, and generating the first password instead of shipping one, would help every operator. Package source and pull requests welcome at https://github.com/OrcVole/harnessrouter-cloudron. Happy to co-maintain.

Unlocks

Now you can give your own scripts and products one API that runs coding agents on your own Cloudron, with transcripts kept and the agents fenced off from your server's internal network and your provider keys.

Synergies

• HarnessRouter + agentgateway: give HarnessRouter its own gateway key instead of a provider's master key, so you can limit or revoke it without touching the provider account.
• HarnessRouter + vLLM or Ollama: point a connection at a model you host yourself, through its public URL, and keep prompts on your own hardware.
• HarnessRouter + Forgejo: give agents a repository to clone, commit to and push, so their work lands in version control you own.
• HarnessRouter + Uptime Kuma: watch /login so you know when the console goes down.

Feedback, bug reports, and "works on my install" confirmations gratefully received.

@Teiluj Paperclip is now available as a community package:

https://forum.cloudron.io/topic/16221/paperclip-community-package-now-available

TL;DR: Paperclip is an open source control plane for teams of AI agents: you define a company with a goal, hire agents into an org chart, give them budgets and approval gates, and they wake on a schedule to pick up tickets, do the work and report back. It is now packaged for Cloudron, with the coding agents it runs contained as a separate unprivileged user. Built and tested on Cloudron 10; unofficial and community maintained.

Headline features

• Run Claude Code, Codex and OpenCode agents inside the app as a separate, unprivileged user that cannot read Paperclip's secrets or reach your other apps and databases.
• An org chart for agents, with per-agent budgets, approval gates and an audit log of everything they do.
• Tickets, recurring routines and cost tracking built in, so agents pick up work on a schedule rather than waiting to be prompted.
• Bring your own model: a Claude or ChatGPT subscription, an API key, or any OpenAI-compatible endpoint, including one you host yourself.
• Agents can hire other agents to build out a team, with an optional board sign-off for each new hire.

Links

• Project homepage: https://paperclip.ing
• Documentation: https://docs.paperclip.ing
• Upstream repo: https://github.com/paperclipai/paperclip
• 🧱 Cloudron package repo: https://github.com/OrcVole/paperclip-cloudron

Once installed, the whole thing is a web UI: a dashboard of your agents and their work, a ticket board, and a settings area to connect models and tools.

How to install

The easiest route is the dashboard. In the App Store, click the Add custom app dropdown (top right) and choose Community app, then paste the CloudronVersions.json URL below into the box that pops up. Apps installed this way receive automatic updates.

https://ca.cloudron.io/app/io.github.orcvole.paperclip

Or with the CLI:

cloudron install \
  --versions-url https://raw.githubusercontent.com/OrcVole/paperclip-cloudron/main/CloudronVersions.json \
  --location paperclip.example.com

Minimums: a 4 GiB memory limit (the app idles at about 1.3 GiB, and each agent running at the same time adds roughly 0.5 GiB), and the postgresql and localstorage addons. The package asks for the net_admin capability, which it uses only to firewall the agent user; Cloudron grants it with the install, and the app's log confirms the firewall at every start. The image is large, because it bundles the coding-agent tools, so the first install takes several minutes to download.

First run: there is no single sign-on. Read the app's Logs for a one-time first-admin invite link; whoever opens it first becomes the administrator, so treat it like a password. Sign-up is open only until the first admin has claimed the instance, and closes automatically at the next start, so restart the app once after claiming it. To connect a Claude or ChatGPT subscription, open the app's Web Terminal, run claude (or codex), then /login, and follow the prompt. If an agent fails with "ACP agent reported a terminal access failure", that is this step not having been done: the onboarding wizard's subscription button does not store a login by itself. API keys are simpler and are entered in the agent's settings.

For users

Why try it: if you already use AI coding agents one prompt at a time, Paperclip turns them into something closer to a small team that works through a backlog on its own, within the budgets and approvals you set. Cloudron wins: automatic backups of your agents, tickets and settings, one-click updates, and the agents kept apart from the rest of your server. Good fit if you want agents doing routine work on a schedule; probably not if you only ever want a single interactive chat.

🧰 For packagers: what we learned

What helped: the postgresql addon covered the database cleanly, and Paperclip runs its own migrations as a non-superuser without complaint.

What was tricky: containing the agents was the real work. A Cloudron app is one container, so a local coding agent would normally share the server's user and could read its secrets. The package gives agents their own user, reached only through a small wrapper and one narrow sudo rule, with an iptables firewall (IPv4 and IPv6) that lets them reach the internet, their workspace and Paperclip's own API, and nothing on the internal network. Paperclip also ships its own bundled copies of the agent tools for its ACP engine, which would sidestep a wrapper; every one of those is routed back through the contained path.

Still rough: the first image download is large. Agent workspaces are git checkouts kept outside the backup on purpose, so anything an agent has not committed and pushed is not backed up.

️ For the Cloudron team

Maintenance burden: upstream releases often, so the package pins the exact agent-tool versions upstream tests with and moves them together on each bump. Why it suits the App Store: agent orchestration is in demand, the upstream is MIT, and it pairs naturally with the AI and automation apps already here. Friction worth knowing: containing a second, less-trusted user inside one app container needs net_admin and a careful sudo design; a per-app way to run a sandboxed sub-process would make packages like this simpler.

For Paperclip's developers

A setting to move the workspace and project roots out of the instance directory would help any packager that splits persistent storage. Package source and pull requests welcome at https://github.com/OrcVole/paperclip-cloudron. Happy to co-maintain.

Unlocks

Now you can run a small, budgeted team of AI agents on your own Cloudron that picks up tickets, works through recurring chores and reports back, without handing your server's secrets to the agents doing the work.

Synergies

• Paperclip + vLLM or Ollama: point agents at a model you host yourself on the same Cloudron, through its public URL, and keep every prompt on your own hardware.
• Paperclip + Forgejo: give agents a repository to clone, commit to and push, so their work lands in version control you own.
• Paperclip + Uptime Kuma: watch /api/health so you know the moment the agent control plane goes down.
• Paperclip + Langfuse: trace what your agents actually send to their models, for cost and quality review.

Feedback, bug reports, and "works on my install" confirmations would be great.

@robi, we are going to package this and hopefully will have something available next week.

• The trust model is similar to Paperclip's: Agents run bash and git with your provider keys.
• Auth. There's a single local user (default harnessrouter/harnessrouter) and we found no OIDC or LDAP.

Nice suggestion, @robi! I am interested in packaging this but it wont be for a couple of weeks. Maybe somebody else might like to try before then...?

@DidierMalenfant

People interested in the gemini protocol might like to know about Unseen Servant:

https://ca.cloudron.io/app/io.github.orcvole.unseenservant

USV (UnSeenserVant) is a gemini server which you can deploy with one click using cloudron. It supports Titan and several other protocols, like gopher and html.