🚀 Lore Server: community package now available

[LoudLemur]

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.

[marcusquinn]

@LoudLemur Great work!

Question: what's your routine for maintaining updates?

[LoudLemur]

@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.