Runtipi: One-Click Self-Hosted App Management on a Home Server

What Runtipi Solves and Who It Is For

Running self-hosted applications on a personal server typically means writing Docker Compose files, configuring reverse proxies, managing environment variables, and tracking updates manually. Runtipi takes that work off the developer and puts it behind a web interface. The README describes it as "a personal homeserver orchestrator that makes it easy to manage and run multiple services on a single server."

The target audience is individuals who want services like password managers, media servers, or note-taking tools on hardware they control, without becoming Docker or Linux networking experts. The README confirms this: Runtipi is "designed to be easy to use, so you don't have to worry about manual configuration or networking." The warning in the README is equally direct: Runtipi is built and maintained by volunteers, carries no guarantee of support or security, and is still in active development. Anyone considering it for a business or production workload should take that warning seriously.

Architecture: TypeScript, NestJS, React, and Docker

Runtipi is built with TypeScript, NestJS on the backend, and React on the frontend. The package.json in the repository root shows a monorepo structure managed with Bun and Turborepo, with packages for the backend, frontend, and shared common code. Version 4.1.0 is listed in the root package.json.

The production runtime is Docker-based. The Dockerfile uses a multi-stage build: a Bun-based builder compiles the TypeScript code, and a Node.js Alpine runner executes it. Docker Compose is embedded into the container image at build time for the target architecture (arm64 or amd64), which means Runtipi does not require a separately installed Docker Compose on the host. Every application that Runtipi installs is also a Docker Compose service, so the underlying model is a managed collection of Compose stacks rather than a container scheduling system.

The start:prod script in package.json is:

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

This command starts the Runtipi orchestration layer itself. Each installed application runs under its own Compose project rather than sharing the runtipi project namespace.

Installing Runtipi and Reaching the Dashboard

The README directs readers to runtipi.io/docs/getting-started/installation for full installation steps, rather than embedding them in the README. The documentation is on the project website. A live demo is available at demo.runtipi.io with the credentials listed in the README:

username: [email protected]
password: password

The .env.example file in the repository contains only `LOG_LEVEL=debug`, indicating that most configuration is handled through the web interface rather than a pre-deployment environment file. For development, the repository includes a docker-compose.dev.yml and the script:

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

This is exposed via the npm script `start:dev` in package.json. The development setup requires cloning the repository and having Bun and Docker available. There is also a portless development variant (`start:dev:portless`) using a separate shell script for environments where the standard port setup conflicts with existing services.

The App Store Model and Community Extensions

Applications in Runtipi are installed from an app store repository. The official store is at github.com/runtipi/runtipi-appstore. The README also mentions that community app stores exist, and that users can create their own. This design means the set of installable applications is not fixed: if an app is missing from the official store, it may exist in a community store, or the user can package it.

The README links to a creating apps guide at runtipi.io/docs/developers/creating-apps, which covers the format for packaging an application for the store. Each app is essentially a Docker Compose descriptor with metadata that Runtipi reads to render its UI card, manage updates, and wire up networking.

The crowdin.yml file in the repository indicates that the interface is localized through Crowdin, supporting contributors who want to translate the dashboard. The codecov.yml and playwright.config.ts files show that the project has code coverage tracking and end-to-end tests.

Runtipi vs Umbrel and Casaos: Different Tradeoffs

Umbrel is the most frequently compared alternative, appearing both in the related searches and in the search questions. Both Umbrel and Runtipi present a consumer-friendly web interface for self-hosted applications on top of Docker. Umbrel has its own app marketplace and has moved toward a hardware-first model with its own branded devices, while Runtipi remains focused on the software orchestration layer that runs on any Linux server the user already owns.

CasaOS is another frequently compared tool. Like Runtipi, it runs on Docker and provides a GUI for managing self-hosted services. The difference in philosophy, as reflected in search behavior, tends to come down to app store breadth and interface design rather than a fundamental technical divergence. All three tools are ultimately managing Docker Compose stacks on behalf of the user.

Runtipi's comparison with Proxmox is worth addressing separately: Proxmox is a hypervisor-level virtualization platform, not a homeserver application manager. Using Runtipi and Proxmox together (Runtipi running inside a Proxmox VM) is a common setup, but comparing them as alternatives misses the distinction between infrastructure virtualization and application management.

Limitations and Cases Where Runtipi Is the Wrong Tool

Runtipi is a single-server tool. The README states it manages services on a single server; there is no clustering or load balancing built in. An organization that needs high availability, horizontal scaling, or multi-server orchestration should look at Kubernetes or Docker Swarm instead.

Security is flagged explicitly in the README: the project carries no guarantee of security when in use. The Runtipi orchestrator itself runs as a Docker container with access to the Docker socket, which gives it broad privileges on the host. Anyone installing Runtipi on a server exposed to the internet needs to consider this surface area carefully.

Application updates in Runtipi depend on the app store maintainers pushing updated Compose definitions. If an application has a critical security patch and the store has not yet updated the package, users have no in-dashboard path to the fix; they would need to update the underlying Docker image manually.

The README also warns that pull requests from unvouched authors are closed automatically unless they change 50 lines or fewer. This keeps the contribution flow manageable, but it also means external contributors need to follow the issue or discussion process before submitting code changes.

License and Contribution Model

Runtipi is licensed under the GNU General Public License v3.0. The README summarizes the implications: users may copy, distribute, and modify the software, but changes must be tracked with dates in source files, and any modifications to or software including GPL-licensed code must be made available under the GPL with build and install instructions. For a user who only runs Runtipi on their own server without distributing modified versions, this creates no practical obligations.

For a business that wants to take the Runtipi codebase and build a commercial product on top of it, the GPL-3.0 requires that the resulting software also be GPL-3.0 licensed and source-available. This is the key license consideration before adopting Runtipi in a context beyond personal use.

The project is developed by volunteers under the leadership of Nicolas Meienberger and a group of contributors listed in the README. There is no commercial support contract offered directly; the community is on Discord.

Editorial conclusion

Runtipi fits individuals and small teams who want to run self-hosted applications on a single Linux server without managing Docker Compose files manually. It is not a fit for production infrastructure with strict security requirements, as the README explicitly warns that there is no guarantee of support or security. Before deploying, verify that your server meets Docker requirements, that the apps you need are in the official or a community app store, and that the GPL-3.0 license is acceptable for any code you plan to modify and distribute. The self-hosting examples repository at github.com/runtipi/self-hosting-examples provides additional reference configurations.

Frequently asked questions

Official sources

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