Cloudron Forum

Semaphore UI is a web interface for Ansible. Playbooks, inventories, repositories, environments and schedules get a browser front end, so routine automation can be run and reviewed by people who are
not sitting at a terminal, and by people you would rather did not have your SSH keys.

It is not Semaphore CI. The name is shared with an unrelated continuous-integration product.

Headline features

• Ansible is in the image, not a prerequisite. The Ansible community bundle 9.2.0
  (ansible-core 2.16.3) and git ship inside, so a fresh install can clone a playbook repository
  and run it with nothing else installed anywhere.
• Cloudron single sign-on through the application's own OIDC support, not proxyAuth. That
  matters here: Semaphore has a full REST API and webhook triggers, and fencing the whole app behind
  a proxy would have broken both.
• Every install generates its own encryption keyring at first run. Upstream's default is either
  no key at all, which stores your SSH keys base64-encoded and calls it done, or the literal key
  published in their compose file. Neither ships here.
• Schedules, webhook integrations and a REST API, so playbooks can run on a cron, be triggered by
  another service, or be driven from your own tooling.
• Task concurrency capped at 10. Upstream defaults to 9999; since every task forks its own
  Ansible process, that default makes any memory limit theoretical.
• PostgreSQL through the platform addon. No bundled database to back up separately.

Links

Package repository: https://github.com/OrcVole/semaphore-cloudron

Versions feed: https://raw.githubusercontent.com/OrcVole/semaphore-cloudron/main/CloudronVersions.json

Upstream project: https://semaphoreui.com — source at https://github.com/semaphoreui/semaphore

How to install

The easiest route, and the one that gets you automatic updates: in the App Store, open the Add
custom app dropdown at the top right, choose Community app, and paste the versions URL above
into the box that appears.

https://raw.githubusercontent.com/OrcVole/semaphore-cloudron/main/CloudronVersions.json

️ Requirements and first run

Minimums: 1 GiB memory, addons localstorage, postgresql, oidc. No extra subdomain.

First run: an administrator is created for you. Open a Terminal for the app and run
cat /app/data/.initial-admin to get the password, sign in as admin, change it, then promote your
own account from Team → Users.

That last step is not optional bookkeeping. Accounts arriving through Cloudron single sign-on are external users and are never administrators, and upstream does not let non-administrators create
projects, so without promoting yourself, signing in with SSO leaves you looking at an empty app.

One more thing worth knowing: Semaphore's "disable password login" setting only hides the password
form. The login endpoint keeps accepting credentials. Treat the admin password as live.

Back up /app/data/keys. It holds the key that decrypts every credential the app stores. It is
inside Cloudron's normal backups, so the only way to lose it is to restore selectively, but if it does go, the app keeps running and looks healthy while every stored credential is permanently
unreadable. semaphore vaults check --config /run/semaphore/config.json tells you the truth; every
key should say active.

For users

Why try it: you have playbooks, and the people who need to run them keep asking you to run them.

What you get: a browser front end for playbooks, inventories and credentials; scheduled runs and webhook triggers; per-project members and permissions, so someone can run the deploy without holding the keys it uses.

Cloudron wins: single sign-on, TLS, backups and updates all handled by the platform, and the encryption key is generated per install rather than shared with everyone who downloaded the same compose file.

🧰 For packagers: what we learned

What helped the platform's postgresql and oidc addons covered the whole dependency list; nothing needed bundling. Existing community packages were the reference for the versions feed shape.

What was tricky:

• The runtime user's home is read-only, and Ansible wants $HOME/.ansible/tmp. It needs HOME, and
  separately ANSIBLE_REMOTE_TEMP — the second is the one that breaks module transfer, and a
  playbook using only debug will happily pass without revealing it.
• Semaphore runs tasks with a sanitised environment, forwarding only variables it is told to. So
  exporting from the start script does not reach Ansible; the configuration has to live somewhere the
  package owns, which is /etc/ansible/ansible.cfg.
• A platform restore returns /app/data owned by a different uid. Git then refuses every stored
  repository as "dubious ownership" and every task fails at the clone — while row counts, checksums,
  health and login all look perfect. The start script takes ownership of the whole volume.
• The PostgreSQL port belongs inside the host value as host:port; there is no separate port
  setting, and sslmode=disable is needed because the addon serves no TLS.

Still rough We would welcome a second pair of eyes on a cold install from the feed onto a fresh subdomain, and on behaviour with a large existing playbook repository.

️ For the Cloudron team

Maintenance burden: low. The package is a build of one Go binary plus Ansible from the distribution, with no patched application code, upstream releases drop straight in with a version bump. Upstream ships often, roughly fortnightly with point releases between.

Why it suits the App Store: Ansible is the obvious automation tool for exactly the audience that runs a Cloudron, and until now running it meant a terminal and a laptop that happened to be on. It uses the platform's own identity rather than reimplementing users, and it has no bundled datastore.

For Semaphore's developers

Thank you! The configuration surface is clean, the OIDC support is in the community build, and the keyring with vaults check and vaults rekey is a good piece of design that made the custody decision easy.

Two things we would raise: password_login_disable is not enforced at the login endpoint, only in the interface; and web/src/assets/logo.svg is a leftover from the Vue
scaffold rather than your mark, which is a small trap for anyone packaging you.

Unlocks

Server maintenance that someone other than you can run. Patch windows as a scheduled task rather than an evening. Credentials that live in one encrypted store instead of on four laptops.

Synergies

Semaphore + Gitea or Forgejo: keep playbook repositories on the same box that runs them; Semaphore clones over the internal network and never needs an outside git host.

Semaphore + Uptime Kuma: point a Kuma alert at a Semaphore webhook integration so a failed check triggers the remediation playbook instead of a notification you read in the morning.

Semaphore + n8n: n8n handles the branching and the approvals, Semaphore does the part that needs Ansible, called through its REST API.

Semaphore + Grafana: dashboards for the fleet, and the tool that changes the fleet, on the same
login.

Semaphore + ntfy: task results pushed to your phone, which is the difference between a scheduled
playbook you trust and one you check.

@andreasdueren The dev closed a feature request with a note explaining why:

https://github.com/baptisteArno/typebot.io/issues/734#event-29694236908

The maintainer has said they are no longer planning new features, product improvements or large internal projects. This will help keep the focus on bugs, security and compatiblity.

The ask, in one line

Add a manifest field to set an app container's /dev/shm size, in the same shape as the existing
memoryLimit.

What we hit

Our community package for vLLM updated from upstream 0.26.0
to 0.27.1. The new version runs its inference engine in a separate process and brokers work between
the two over a POSIX shared-memory ring buffer. It refuses to start if /dev/shm is too small:

RuntimeError: Insufficient space in /dev/shm: 160 MiB required, 62 MiB free.
Increase /dev/shm (e.g. --shm-size or --ipc=host).

A Cloudron app container gets a fixed 64 MiB, confirmed on two independent installs on two
different Cloudron servers (9.x and 8.3.x):

$ df -h /dev/shm
shm              64M   76K   64M   1% /dev/shm

We could find no way to change it: no manifest field, no CLI flag, and nothing in the app
configuration UI.

Why we think it is worth a platform change rather than a per-app workaround

The 64 MiB default is Docker's, and it predates the current generation of workloads. Anything using
PyTorch or Python multiprocessing shared memory, headless Chrome or Chromium (a very common
packaging target), or a database tuned with large shared buffers, runs into the same ceiling. In
every case the symptom is a confusing message from a library several layers down rather than
"your platform gives you 64 MiB", so the diagnosis is expensive each time. It cost us about
twenty minutes on a package we already understood well.

It is also the kind of limit that only bites on update. Our 0.26.0 install is healthy today. Had
we published 0.27.1 without catching this, every install would have updated into a container that
cannot boot at all — and because the app never becomes healthy, the failure presents as an install
problem rather than a resource one.

What we did instead, in case it is useful to others

vLLM can run its engine in-process, which never allocates the ring buffer. On a single-model,
single-replica CPU server that costs nothing, so our start.sh now measures the free space in
/dev/shm at boot and sets VLLM_ENABLE_V1_MULTIPROCESSING=0 when it is under 200 MiB, logging the
reason. It is written as a detection rather than a constant so the package returns to upstream's
default automatically if the platform limit ever rises.

That works, and we are shipping it. But it is a workaround chosen because the platform value is
fixed, and the next package to hit this may not have an equivalent escape hatch.

Suggested shape

{
  "memoryLimit": 10737418240,
  "shmSize": 268435456
}

Defaulting to today's 64 MiB, capped at some fraction of memoryLimit so it cannot be used to
evade memory accounting, and ignored by older boxes so manifests stay backward compatible.

Happy to test a build.

@BrutalBirdie said:

Here you go: https://ca.cloudron.io/app/tachyon

Hey, BrutalBirdie, that is great and thank you very much! I think many here might like to know how it goes if you already have SnappyMail up and running on Cloudron and want to switch over to your Tachyon. Is easy to do? How is the new GUI for Tachyon by the way?

Could Cloudron allow apps to request privileged tcpPorts (<1024), or document the restriction?

This is absent from the manifest docs. Does an exception mechanism exist?

Is displacing the built-in mail stack ever supported?

These enquiries relate to the recent thread discussing SnappyMail not receiving many updates anymore, and looking around for alternative mail servers to package for Cloudron, e.g. Stalwart:

https://stalw.art/mail-server/

@andreasdueren What is the issue with this? Maybe their developers can help us package it.

@andreasdueren You are ahead of the game! We were just looking at packaging this and saw you were already testing. Great going, andreas!

@james could you please link to tachyon the mail server? we couldn't find it

@fbartels

Thank you for looking at this. You are right that content-addressable layer dedup is how this is supposed to work, however we don't think it explains what we actually saw:

Two things:

1. The base image isn't actually one constant across a Cloudron host. We pulled cloudron/base locally while investigating this and ended up with three distinct cached versions: 4.2.0, 5.0.0, and an untagged/latest one, at 2.25–2.48GB each, none byte-identical.

If installs on a given host accumulate whatever base version was current when each app was last built or updated, rather than all sharing one pinned digest, then a newer pin (we are on 5.1.0) isn't guaranteed to already be sitting there just because other apps on the same host use a cloudron/base of one version or another.

2. The actual install we watched doesn't fit "already cached." We built the exact same image with the old base and installed it fresh on a real (personal) Cloudron via cloudron install --image, timed it: ~26 minutes, with a Downloading image step that sat there for most of that time. If the 2.5GB of base layers were already resident on that host and only our ~9MB diff needed to move, that step should have finished in seconds, not half an hour. After switching to the ~20MB image, the same install (uninstall + reinstall, same host) took 1m40s total, download step included.

So either that particular host genuinely didn't have our exact base-image digest cached yet, or something else was slow that we haven't identified, but "the base image was already shared, so size wasn't the bottleneck" doesn't match the timing we actually measured on that install.

Is there a piece of the caching behaviour we are missingthat would explain the ~25-minute gap, not just the general mechanism?

We are packaging a small network service and ran into a size problem would like a sanity check on before I go further with it.

The situation: the app itself is a single statically-linked binary,
under 10MB, with no runtime dependencies. Following the tutorial /
cheat-sheet pattern, the final Docker stage is cloudron/base, and the resulting image comes out to roughly 2.5GB — almost entirely the base image itself (a large apt-get layer plus a bundled language runtime the app never touches), not the app. That size turned out to matter in practice: even with the image built ahead of time and installed via cloudron install --image (so there's no server-side compile), the install is still slow, because the whole 2.5GB has to be pushed to a registry and then pulled onto the Cloudron host every time.

What we tried instead: We re-read the packaging cheat-sheet looking for anything that actually requires cloudron/base specifically, and couldn't find one — the documented contract (read-only rootfs with /app/data//run//tmp writable, the CLOUDRON_* env vars, HTTP health checks, stdout/stderr logging, addon file injection) reads as enforced by the platform at runtime, not baked into that particular base image. So I swapped the final stage for a minimal base instead,
just enough to provide a cloudron user at uid:gid 1000:1000, a
gosu-equivalent privilege-drop tool, and a shell to run start.sh
(kept bash specifically, not the base's default lighter shell, so
the dashboard's web terminal and file manager, which exec bash intothe container, still work). Final image: about 20MB, down from 2.5GB.

We tested it as thoroughly as we could from outside actually installing on a Cloudron: ran the built image as a container with the same env vars Cloudron sets, confirmed the app starts and serves correctly, confirmed start.sh's root→drop-privilege sequence still works and the process ends up running as the unprivileged user, confirmed bash is present and functional inside the running container, and simulated
a permissions reset on the data directory (as the docs say backup
restores can cause) to confirm the startup script's chown still
recovers correctly. It also installed and ran fine on a real (personal,
non-Store) Cloudron instance.

What we are unsure about: We went looking for a precedent and couldn't
find any. Every app Dockerfile we could find under the official
Cloudron GitHub org uses cloudron/base, including at least one that's about as minimal in spirit as mine (a simple single-purpose file server). Zero hits for alternate/minimal base images anywhere in that org. That's made us second-guess it even though I can't find a documented reason it shouldn't work:

• Is there a real technical reason every app uses cloudron/base that
  isn't written down in the packaging docs, something the base image provides that we haven't hit yet (backup/restore internals, the update mechanism, something the App Store review process execs into the container and expects to find)?
• Would this be looked at unfavorably for an eventual Store submission
• Is there a reason apps this size still ship on the big base that
  we are missing, or is it genuinely just "nobody's wanted to optimize this because most apps actually need a language runtime anyway"?

Might this bite us later?

@marcusquinn said:

@LoudLemur Great work!

Question: what's your routine for maintaining updates?

Thanks for asking, @marcusquinn!

We setup a little program to check through our flotilla of applications and see which are behind the main ones. Looking at that just now, we are 5 behind. These are minor bumps. We will likely update them in a batch tomorrow.

One or two we might treat differently. For example, if one of the maintainers has introduced themselves over here and makes a request, we would likely give that higher priority for an update. One of these packages is moving rapidly and has multiple bumps over a course of only two days. We will lag behind those a bit. Another one has no proper point releases and it is difficult to pin down when to update so we shall lag there, too.

Generally, we are taking a conservative approach, trying to do well tested, hopefully reliable packages. We are still in a phase where we are refining our processes and working towards what will eventually be more automated updates for smaller updates. At the moment, it is quite manual.

Having a lot of packages means there is more incentive to get the packaging right. Some of these applications, like Qdrant, we love. Our big hope is that eventually they might be absorbed into Cloudron's officially supported applications or even that the maintainers want to do it.

@timconsidine thank you for the link, that is the piece I was missing. I had been guessing at packages/releasebell and cloudron/releasebell; the group is apps, which I never tried.

It does not get me all the way there, though. Signed in as LoudLemur the path 404s, and GitLab answers 404 rather than 403 for a private project you are not a member of, so I read that as the repository being there and my account not being on it. The apps group is public but lists no public projects, and packages lists exactly one, so I assume that is simply how app repos are kept rather than anything to do with me.

@girish that narrows what I asked for in my last post. I no longer need the path, only access to apps/releasebell for LoudLemur, or a fork pushed somewhere I can reach. Everything else on my side is unchanged: once I can read the real tree I will rebase onto current master, re-run my checks against that base instead of the archived 1.12.0 mirror, and open the MR.

Incidentally the footer of the notification email points at git.cloudron.io/cloudron/releasebell, which is one of the paths that comes back not-found. Small thing, but the in-app link looks stale relative to apps/. Happy to fix it in the same MR.

On the email rule: you are right that it works, and more cleanly than I would have guessed before looking. The subject is built as <project> <version> (prerelease) released, and that (prerelease) comes straight from the release API flag rather than from pattern-matching the tag, so a filter on that literal string catches exactly the prerelease mails and nothing else. No false hits on a project that happens to ship a version called beta.

So it is a good workaround and worth having posted for anyone who needs one today. Three things it cannot do, which is why I still think the setting earns its place.

It is all-or-nothing. The reason I ended up adding a per-project override on top of the per-user flag is that the useful setting is not "no prereleases" but "prereleases for the four projects I actually test against, and not for the other forty". Expressing that as mail rules means one rule per project, edited by hand every time you follow something new.

It deletes rather than defers. Because a suppressed release stays notified=FALSE in the database, turning the setting back on delivers the prereleases you missed while it was off. That is deliberate, and it is what makes the setting safe to flip. A filtered email is gone.

And it depends on a presentation detail. The subject string is template text, not API surface. If someone rewords it, the rule quietly stops matching and you start receiving prereleases again, or a reworded rule quietly starts eating real releases. Filters that fail in the delete direction fail silently.

None of which is an argument against your rule in the meantime.

Pijul is now available as a Community Package on Cloudron:

https://forum.cloudron.io/topic/15785/pijul-nest-community-package-now-available

This one is for you, @robi ! It took 3 years, but thank you for all your help during that time.

TL;DR: The Nest is the repository hosting platform for Pijul, a version control system built on a theory of patches rather than snapshots. Web UI, accounts, discussions, and push over SSH. Now packaged for Cloudron. Unofficial and community-maintained.

Headline features

• Browse repositories, file trees and changes in a clean terminal-styled web UI
• Per-user accounts with public and private repositories
• Discussions attached to a repository, and change review
• Clone over HTTPS with nothing to configure; push over SSH on a port you pick at install
• Outgoing mail through Cloudron's relay, for password recovery and notifications
• AGPL-3.0-or-later, shipped unmodified from upstream

Why Pijul, if you have not met it

Pijul's patch model is commutative: two changes that do not touch the same lines can be applied in either order and land the same repository, so a change moves between branches without rebasing or cherry-picking. Conflicts still happen when two people genuinely edit the same thing, but they are recorded in the repository rather than resolved and forgotten, so you can revisit how one was settled.

If you have ever wanted Darcs' theory of patches with performance that survives a real repository, this is that.

Links

• Project homepage: https://pijul.org
• Upstream source: https://nest.pijul.com/pijul/nest
• 🧱 Cloudron package: https://github.com/OrcVole/pijul-cloudron
• Store listing: https://ca.cloudron.io/app/pijul-nest

There is no hosted demo. Once installed, the Nest's own web interface is the whole thing.

How to install

The easiest route is the dashboard: open the App Store, click the Add custom app dropdown at the top right, and choose Community app. Paste the versions URL into the box that appears. Apps installed this way receive automatic updates.

https://raw.githubusercontent.com/OrcVole/pijul-cloudron/main/CloudronVersions.json

Or from the CLI:

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

Minimums: 2 GiB memory limit, though it idles well under a tenth of that. Addons: localstorage, postgresql, sendmail.

Pick an SSH port during install. The Nest serves SSH itself rather than through the system daemon, so it cannot use port 22. Leaving the port disabled still gives you browsing and cloning over HTTPS, but you will not be able to push to the instance at all, so enable it if you want a working remote rather than a read-only mirror.

First run: the Nest has its own account system and does not use Cloudron single sign-on, because upstream provides no OIDC or LDAP to map onto. Register on the instance; the first account you create is yours. Add an SSH key under account settings before pushing.

For users

Good fit if you want to try patch-based version control on your own infrastructure without building the server yourself, or if you already use Pijul and want somewhere to put repositories that is not someone else's hosted service.

Probably not a fit if you need Git compatibility, a mature plugin ecosystem, or CI. Pijul is young software and the Nest is younger; this package is a way to run it, not a claim that it is a drop-in replacement for what you have.

🧰 For packagers: what this one taught me

Upstream's own deployment module was worth more than its README. The Nest ships a NixOS module that generates its production config, and it stated plainly what the README did not: how many services there are, which are optional, what the real defaults are, and which user each runs as. Reading it first killed an invented etcd dependency and a wrong port map before either became work. If an upstream ships a Helm chart, a compose file, or a systemd unit, read that before the README.

A migration can hardcode a role name a managed database cannot create. These migrations grant to a specific role that upstream's own deployment creates first. Cloudron's postgresql addon cannot create roles, so the first migration fails on a name, not a privilege. Rewriting the grantee to CURRENT_USER at build time fixes it and needs no elevated permission at all.

HTTPS here is read-only, by design. I had it documented the other way round for most of a day. The write path lives entirely in the SSH server; the HTTP handler only ever reads. Worth knowing before you promise a user that HTTPS push works.

Something has to make a real request. A duplicated nginx directive killed the front proxy while every process still reported healthy and the container still reported up. Nothing caught it except actually asking the port for a page.

Still open: this storage engine is memory-mapped and commits by overwriting a page in place, guarded by advisory locks that a filesystem-level backup has no reason to take. Whether a backup running during a push can catch a repository mid-write is a real question I could not settle in six attempts, and I would rather say so than imply I proved it safe.

️ For the Cloudron team

Maintenance burden: upstream ships no tagged releases at all, so this package pins an exact point in a moving tree and re-pinning is a deliberate decision rather than a scheduled one. Expect a slower update cadence than most community packages, with more care per update.

Why it might suit the store: Forgejo, Gogs and GitLab are all here and none of them host Pijul repositories, so this covers a gap rather than duplicating a package. The App Wishlist thread for Pijul has been open since 2023 with a few thousand views.

Friction worth knowing: a tcpPorts default value collided with an existing app on first install, and neither the error nor the CLI output named which app held the port or offered a free one. Separately, a half-failed install left a record behind that kept its port reserved, so a straight retry with the same number failed until the stray record was removed.

For Pijul's developers

Two things that would help anyone packaging the Nest, offered with thanks rather than as complaints.

A one-line note at the top of the checked-in api/config.toml saying it is a development config and pointing at the NixOS module would prevent a packager reading it as the deployment contract; the two disagree on nearly every field, including whether etcd is involved at all.

And pijul clone --change <hash> currently panics against the Nest's own repository, deep in a dependency it has just fetched. --state <hash> works and produces the same tree, which is what made pinning a build possible, but --change is the obvious thing to reach for first. Details are in the package repo if useful.

Synergies

Pijul Nest + Forgejo or Gogs: these do not compete. Git repositories stay exactly where they are and Pijul repositories get a home alongside them, so you can try a genuinely different version control model without migrating anything or giving anything up.

Pijul Nest + a wiki such as BookStack or Wiki.js: repository discussions are good for change-level conversation and poor for long-form design documents. Keeping the argument in a wiki and the record of what actually changed in the Nest suits both better than forcing either to do both jobs.

Pijul Nest + Cloudron's own backups: the instance's SSH host key and password material are generated once and live under the app's data directory, so a restore brings back a working instance rather than one every client suddenly distrusts. That is worth more for a version control server than for most apps, because a changed host key looks exactly like an attack.

Feedback, bug reports, and "works on my install" confirmations all welcome.

@roliG said:

So having a working 1-Click install is always useful!

Cloudron lets you install two applications gratis.

@james Hey, thank you for providing that "App Maintainer" tag for roliG. We didn't realize till you did that.

@roliG Wow! This is fantastic to have the maintainers here! Thank you very much for saying, "Hello"!

There were some notes specifically for wger developers here, which you might already have seen:

https://github.com/OrcVole/wger-cloudron/blob/main/docs/FOR-UPSTREAM.md

• Do you think "1-Click" deployment of wger might help make it a much more widely used applcation?

• Which other application would you like cloudron to support, something which might help you or wger?

• We tried quite hard to make sure our wger package would work well when wired up with other AI related applications, particularly the ones Cloudron already supports. Have you tried using wger alongside another Cloudron package to see how quickly you can do it and how easily it works?

Lore Server is now available as a Community Package:
https://forum.cloudron.io/topic/15784/lore-server-community-package-now-available

This one is for you, @marcusquinn Thank you for all the help over the years!

TL;DR: Lore is Epic Games' open-source version control system for very large binary assets, the kind that make Git and Git LFS fall over. It gives artists and build pipelines fast, deduplicated, content-addressed versioning for multi-gigabyte files. Now packaged for Cloudron and ready to install. Built and tested on Cloudron 9.x; unofficial and community-maintained.

Headline features

• Content-addressed storage with BLAKE3 hashing and Zstandard compression, so identical files are stored once no matter how many places they appear. On the test corpus above, three copies of the same 4 MB file cost 3.8 MiB in total, not 11.4 MiB.
• Sub-file chunking that makes small edits to huge files cheap: changing one byte in an 8 MB file added 144 KiB to the server, not 8 MB.
• Handles the formats studios actually ship, verified on this package across 23 of them including AV1, VVC/H.266, JPEG XL, AVIF, EXR, ProRes, Opus, FLAC and 16-bit PNG.
• A real, publicly trusted TLS certificate on the data plane, issued and renewed by Cloudron, so clients connect with no certificate wrangling at either end.
• Written in Rust, MIT licensed, and driven by a single static client binary.

Links

• Project homepage: https://epicgames.github.io/lore/
• Upstream repo: https://github.com/EpicGames/lore
• 🧱 Cloudron package repo: https://github.com/OrcVole/lore-cloudron

There is no demo, and no web interface to show: Lore is driven entirely by the lore command-line client, so the dashboard's Open button returns a 404 by design. Upstream has committed to a web client in 2027, with a VS Code plugin in progress before that.

How to install

The easiest route is the dashboard. Click the Add custom app dropdown at the top right of the App Store, choose Community app, and paste this URL into the box that appears. Apps installed this way receive automatic updates.

https://raw.githubusercontent.com/OrcVole/lore-cloudron/main/CloudronVersions.json

Or from the CLI:

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

Minimums: 2 GB RAM, addons localstorage and tls. It claims no extra subdomain, but it does publish port 41337 as both a TCP and a UDP port, which Cloudron opens on the host firewall for you.

First run: there is no login. Lore's own JWT authentication is switched off in every configuration upstream ships, and this package does not invent credentials for you, so anything that can reach port 41337 can read and write. The post-install notes cover the two ways to close that, and recommend one.

For users

Why try it: if you version game art, film assets, or anything else measured in gigabytes, you have probably watched Git LFS struggle. Lore is built for exactly that case.

What you get: deduplicated storage across every repository on the server; cheap incremental commits on huge files; and a client that authenticates with a token rather than a browser, so build agents and scripts can drive it.

Cloudron wins: automatic scheduled backups with one-click restore, a TLS certificate issued and renewed unattended for the data plane, the platform and base image patched centrally, and package updates delivered to every installation from one published version.

Good fit if you have large binary assets and a team that already lives in a CLI. Probably not if you want a browser UI today, or if you need per-user permissions before the auth story matures.

🧰 For packagers: what we learned

What helped — the tls addon does the whole job for an app that terminates its own TLS on a raw port; localstorage covered every store with no extra work; and publishing an httpPort for the health check alongside raw tcpPorts and udpPorts worked exactly as the GitLab and Minetest packages suggest.

What was tricky — the release tarball ships the binary without an execute bit, which fails at start-up with a Permission denied that reads like a mount problem. The tls addon's private key is root-owned and unreadable by the unprivileged app user, so the material has to be copied and chowned at boot; we stage it into /run so keys never enter a backup. And the gRPC endpoint defaults to requiring client certificates, which does not stop the server starting, so the failure only shows up when a client tries to connect.

Still rough — the client offers no --ca-file or equivalent, so a private CA has to go into the operating system trust store on every machine. Fine here, since Cloudron issues a real certificate, but worth knowing if you run an internal PKI.

️ For the Cloudron team

Maintenance burden: thin. The package fetches a pinned release binary and checks it against a recorded SHA-256; a version bump is two fields and a rebuild. Upstream ships roughly monthly.

Why it suits the App Store: MIT throughout, no database or cache addons, and it fills a gap nothing on the store covers. Large binary asset versioning has no other self-hosted answer that works at this size.

Friction worth knowing: the tls addon's certificate and key are root-owned, and the documentation does not say so, which costs a debugging session for any app that runs unprivileged and terminates its own TLS. Group-readable material, or one sentence in the addon docs, would remove that entirely. Separately, an app with no web interface still gets an Open button, and there is no way to say "this app has nothing to open".

For Lore's developers

Three small things that would help anyone packaging this:

• Set mode 0755 on the binaries inside the release archives, since the CLI archive has the same missing execute bit;
• Enforce the cert_chain requirement at start-up on the public endpoints as the internal one already does, so a misconfiguration fails loudly instead of at connection time;
• Consider answering GET / with a short informational response, because hosting platforms put a button next to every app and that button currently leads somewhere blank.

Package source and pull requests welcome: https://github.com/OrcVole/lore-cloudron. Happy to co-maintain.

Unlocks

You can now keep a studio's art source, cinematics and audio banks under real version control on your own Cloudron, with backups and TLS handled by the platform, instead of a shared drive and a naming convention.

Synergies

Forgejo or Gitea + Lore: keep code in Git where it belongs and move the multi-gigabyte art, video and audio into Lore, which is built for exactly the files Git LFS handles badly. The two sit side by side on one Cloudron with no interaction needed.

n8n or Windmill + Lore: the lore client supports non-interactive token login with no browser, so an automation flow can commit build output, publish a release branch, or mirror assets on a schedule.

Minio or any S3 store + Lore: complementary rather than integrated. Lore handles versioned working assets; object storage handles published artefacts and distribution.

Feedback, bug reports, and "works on my install" confirmations all welcome below.