Runtipi wraps Docker Compose in a web app store for a single server

The catalog lives in a separate repository, so your app list is not a property of the version you installed

Runtipi describes itself as a personal homeserver orchestrator: a single server, many services, one web interface for adding and managing them. The layer underneath is Docker, and the project states that you do not have to wire up configuration or networking yourself. The list of installable software lives in its own repository, runtipi/runtipi-appstore. Community app stores exist as well, and you can publish your own. That separation has a consequence worth sitting with: the set of apps you can install is not fixed by the version of Runtipi you ran. It is whatever your stores expose on the day you open the interface, and a store you add yourself is content you chose to trust, not something the orchestrator checked on your behalf.

Two Compose files sit behind the local run scripts, and you can read them

The contributor entry points show how little is hidden. The root package.json drives docker compose under the project name runtipi, once against docker-compose.dev.yml and once against docker-compose.prod.yml, both with the build flag set:

docker compose --project-name runtipi -f docker-compose.dev.yml up --build

A third path, the start:dev:portless script, calls a shell file instead:

bash ./scripts/start-dev-portless.sh

Which file gets selected is the real fork in the road. If you have read a compose file for a homeserver before, you can predict the shape of what Runtipi produces, because Compose is not hidden behind an abstraction. What you cannot get from the compose files is the app catalog logic, which lives in the app store repository.

There is no install command in the repository, and no rollback or upgrade notes

The Getting started section routes you to the installation page at runtipi.io/docs/getting-started/installation and, for looking before you install, publishes a live demo at demo.runtipi.io with a shared account:

username: [email protected]
password: password

Because those credentials are printed in public, treat anything you open in that demo as readable by everyone else. The visible part of the README does not cover rollback, upgrades or what happens to stored data; the repository also has a docs directory. Plan your upgrade path before you install, not after.

The image build branches on two CPU architectures and has no fallback

The Dockerfile takes a build argument named TARGETARCH and branches on it twice: arm64 downloads docker-compose-linux-aarch64, amd64 downloads docker-compose-linux-x86_64, both pinned to DOCKER_COMPOSE_VERSION v2.40.3. In the build script there is no third branch and no fallback path, so any other value leaves the file named docker-binary absent when the next layer runs chmod +x docker-binary, and the build fails rather than degrading to something architecture neutral. The rest of the toolchain is pinned just as tightly: Node image jod, Alpine 3.24, Bun 1.4.4. If your hardware is outside those two architectures, you find that out during an image build, not from a published support matrix.

The shipped .env.example is a single line, so the configuration surface is invisible in the repository

Open .env.example here and you get LOG_LEVEL=debug. That is the entire file. The file lists no other setting. The practical effect is that the example file tells a contributor almost nothing about configuration. The test wiring expects more than it ships: the e2e scripts run through dotenv-cli and load both .env and .env.e2e, neither of which is in version control, so the first thing a new contributor writes is a file the repository never gave them.

The manifest says 4.1.0 while the releases say v4.10.2, and the nightly tag stopped in 2024

The root package.json names the project and sets version 4.1.0, while the published releases include v4.12.0 dated 2026-10-31. Those numbers measure different things, and only the tag tells you what shipped. Any script that reads the version out of the repository to decide whether a host is current will report a host as unpatched on an install that is actually several generations ahead,. The release list also still carries a tag named nightly dated 2024-02-09, so nightly is not a rolling channel here by the look of its date. Track the release tags, not the manifest.

Every service you run sits behind a layer its authors decline to guarantee

The project carries a warning that it is built and maintained by volunteers, that there is no guarantee of support or security when you use it, and that while the system is considered stable it is still in active development and may contain bugs. That is a candid statement and it should shape your deployment. Runtipi is not one service among many; it is the layer that starts, stops and wires up the rest. A defect there takes down or exposes everything above it at once, including the apps holding your files, your mail and your password database. The last push was on 2026-11-01, so the code is moving, and moving volunteer code is not the same as a maintained deployment you can page someone about.

Contributing means Bun, Turbo, Biome and a generated client, not a Node install

The workspace is managed by Bun 1.4.4 with Turbo driving dev, build, bundle, test and typecheck runs, Oxlint handling lint, and Playwright covering end to end flows. The TypeScript client is not written by hand: the gen:api-client script runs openapi-ts, and arktype is ^2.1.29 in the workspace catalog and ^2.2.9 in the overrides while drizzle-orm ^0.45.4 is the single runtime dependency at the root. For an operator none of that matters at runtime, and the runner stage shown in the Dockerfile only adds curl, openssl, git, tar, pigz and file to the Alpine base. For anyone planning a fork it matters a lot: the contributor floor is a specific Bun toolchain, and the API client is generated, so editing it by hand does not survive a regeneration.

Editorial conclusion

Runtipi suits one person who wants a single web interface over a handful of services and accepts reading the website docs for anything operational. It does not suit multi-user deployments that need a support contract or a security SLA. Before you hand it a machine, match your CPU architecture against the image build, decide who is responsible for the app stores you add, and accept that upgrades, backups and data ownership stay with you.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes