Skip to main content
Floe publishes two images to GitHub Container Registry. docker-compose.yml pulls both, so self-hosting needs no clone, no Node, and no build. Both are public, so docker pull needs no login.

​
Tags

Pin a tag with FLOE_IMAGE_TAG:
.env
The variable is FLOE_IMAGE_TAG, not FLOE_VERSION. FLOE_VERSION belongs to the CLI installer and is written with a leading v, as in v1.10.11. Image tags carry no v, so reusing that name would resolve to a tag that does not exist.

​
Pinning a digest

A tag can be repointed. A digest cannot, so it is the strongest pin:
Terminal
Take the digest it prints and pin that instead of the tag:
docker-compose.yml
The digests a tag is built from are validated before it moves, and every tag is checked again afterwards, so a tag and its digest always refer to an image that was actually started and exercised. The second pass is detection rather than prevention: it runs after the tag moved, and its job is to make a bad publish loud instead of silent.

​
Architectures

Both images are published for linux/amd64 and linux/arm64. Docker picks the right one automatically, so Raspberry Pi, Oracle Ampere, AWS Graviton, and Apple silicon all work with the same commands as anywhere else.
Terminal
It lists one entry per platform, so you can confirm your architecture is covered. Each architecture is built and smoke-tested on its own hardware before any tag points at it, and a tag is only published once every architecture of both images has passed. A partly-built release is never visible. That matters more than it sounds. The image optimizer fails at load time rather than at build time, and when it fails it does not error: it quietly serves the original file. So a broken ARM image would look perfectly healthy to anything that only checks whether the page loads. The smoke test asserts the optimizer actually returns WebP, on real ARM. 32-bit ARM (linux/arm/v7, older Raspberry Pi models) is not published. Node dropped support for it and no prebuilt image-processing binaries exist.

​
Building from source

Contributors, and anyone who wants their own domain in share previews, add the build overlay:
Terminal
This path needs the repository checked out, since the overlay builds from ./client and ./server. The compose file alone is not enough. The overlay tags its output floe-server:dev and floe-client:dev, so a local build never replaces a pulled image under the same name. These have to be written into the HTML when the app is built, so a shared image cannot know which domain it will be served from. Claiming one would mean every self-hosted instance advertising somebody else’s site to crawlers, so the published image emits only what is true without knowing its own origin: To put your own domain in them, build the client yourself:
Terminal
This affects only SEO and link previews. Transfers, the signaling connection, and the relay are unaffected, and all of those are configured at runtime.

​
Updating

Terminal
See Operations for backups, logs, and health checks.