Deployrr: one command to set up a Docker homelab, with a real list of limits

What Deployrr actually sets up for you

Deployrr is described as an all-in-one solution for automated Docker-based homelab deployment, and the project description says it automates homelab setup using Docker and Docker Compose, turning a complex setup into a click.

The scope is bigger than an application launcher. The supported application list in the README includes Socket Proxy, Traefik with Let's Encrypt certificate fetching, Authentik, Authelia, TinyAuth, Portainer, Plex, Jellyfin, the Starr apps, Gluetun, Dozzle, Uptime Kuma, Homepage and CrowdSec, and the full list lives in a separate file in the repository. The README counts 160 plus pre-configured applications.

The security story is the part that distinguishes it from a compose file generator. There is Socket-Proxy protection, CrowdSec integration, and a choice of authentication front ends, with Authentik, Authelia, TinyAuth and Google OAuth named. So the tool does not merely start containers, it puts an identity layer and a crowd-sourced intrusion response in front of them.

Networking is handled with Traefik as the reverse proxy, with a choice of exposure mode, internal, external or hybrid, and support for several servers and several domains under one deployment.

Beyond the core, there are curated bundles for self-hosted AI, with Ollama, Open-WebUI and Flowise, and for automation, with n8n and Node-RED. The management side is a stack manager interface, automated backup and restoration, monitoring and logging, and remote share mounting over SMB, NFS or Rclone.

The whole thing is described as a path to homelab mastery rather than just another container manager, and the stated goals are simpler deployments, rapid testing and experimentation, learning by doing, and quick recovery when something breaks.

Two install paths, and Node.js is optional

The installation section of the README offers two methods, and the choice is about whether you already have Node.js on the machine.

The recommended one runs the published package through npx, with the system-wide privileges the deployment needs:

sudo npx @simplehomelab/deployrr@latest

The second method is a standalone installer script, and its selling point is that it removes the Node.js and npm dependency entirely:

sudo bash -c "$(curl -fsSL https://files.deployrr.app/install.sh)"

Whichever route you take, the tool is then launched from anywhere with the deployrr command, and updated with:

deployrr update

The prerequisites for the npx route are Node.js and npm, and the README gives the installation for each major Linux family. On Ubuntu and Debian it uses the NodeSource setup script and then installs the package:

curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
sudo apt-get install -y nodejs

Fedora and RHEL or Rocky get the rpm variant of the same script with dnf and yum, and Arch gets nodejs and npm straight from the package manager.

There is a design point in the second method worth naming. A curl to bash installer with sudo is exactly the pattern that makes people cautious, and the project offers it as the option that removes a runtime dependency rather than as the recommended path, which is a reasonable ordering of preferences for a tool that will be running with root privileges on a home server.

The version 5 line is frozen but still downloadable

The README has a section on version 5 support, and it is written for people whose installation stopped working rather than for people choosing between versions.

The explanation is that a version 5 install that stopped working is probably on a version older than 5.11.2, which is the latest and the last version of the 5 line. If you need continued access to version 5, you download that release manually from the v5 branch of the repository, and the commands are given:

wget https://github.com/SimpleHomelab/Deployrr/raw/refs/heads/v5/deployrr_v5.11.2.app
chmod +x deployrr_v5.11.2.app
./deployrr_v5.11.2.app

There is a separate artifact for ARM machines, and the README says to use that one if you are on ARM architecture.

So the shape of the versioning is: version 5 is a maintained archive that is only fixed at the end, version 6 is the current line, and the current line is installed through the package manager or the installer script. The version 5 artifacts are distributed as an application bundle rather than through the installer, which is consistent with a line that predates the current distribution mechanism.

The release history in the repository shows how the two lines overlap. Version 5.11.1 came in November 2025, 5.11.2 in March 2026 and 6.0.26 in April 2026, so the older line was still getting a release after the new one had shipped its first major version.

The limitations list is short and specific

Most tools of this kind bury their limits. This one has a section titled known limitations, and there are three entries, each of which is a real constraint on a deployment.

The first is the DNS challenge provider, which is currently Cloudflare only. If you host DNS somewhere else and want the certificate flow to work without manual steps, that is a boundary, not a configuration option.

The second is port forwarding, where 80 and 443 are required. That is the Traefik consequence, since the reverse proxy has to answer on the standard ports for certificates to validate and for clients to connect without extra configuration.

The third is the most operational: specific database-dependent apps may require manual database removal. In other words, when you remove an application from a stack, the tool will not always clean up the data behind it, and you have to do that part by hand.

The platform support is stated in the same spirit. Ubuntu and Debian-based systems are the primary platform, while Arch, CentOS, RHEL and Rocky are described as working but unsupported. The deployment options are broader, with baremetal, a virtual machine, Windows with WSL, and LXC containers all named.

The contrast between that section and the marketing voice elsewhere in the README is the interesting editorial point. The features are sold in superlatives, and the limits are listed without softening. A reader who reads both will get a much better picture of the tool than one who reads only the first.

Free tier, paid tiers, and a licence file you should read

Deployrr is a product with a commercial shape, and the README lays it out plainly.

There is a free tier with the essential features for basic setups, and then paid tiers named Basic, Plus and Pro, with a comparison page on the site. It also notes that annual website memberships include full Deployrr access, which is a separate purchase from the tool itself.

That is a meaningful distinction for anybody planning to adopt it, because the repository carries its own licence, and the listing records it as a custom licence that GitHub cannot classify, with the details in the licence file in the repository root. So the source terms and the product terms are two different documents, and the free tier is a product tier rather than an open source licence. For a project that intends to modify Deployrr, the file in the repository is the starting point, and for a project that just wants to run it, the pricing page is.

The open-source side of the business is acknowledged too. Part of the revenue supports open-source projects through OpenCollective, and the repository carries a changelog and an announcement directory alongside the application definitions.

Support is organised around a documentation site, a Discord community and a YouTube channel, with a set of introductory videos for both major versions, including a long tutorial for version 5 and a shorter introduction to version 6. Testimonials are collected on the project's own site, which is a marketing artefact rather than evidence, and the repository's own record is the release history and the changelog.

Editorial conclusion

Adopt Deployrr if you want a Docker homelab assembled in a single run rather than a weekend of compose files, and you are on Ubuntu or Debian, since those are the supported platforms and the system checks and the reverse proxy assumptions are built for them. Do not adopt it if you cannot accept the two hard constraints, a Cloudflare-only DNS challenge and the need to forward ports 80 and 443, and read the licences carefully, because the product has free and paid tiers while the repository carries its own licence file. Before you deploy, read the known limitations list, check whether any of your applications are the database-dependent ones that need manual cleanup, and decide whether you want version 6 or the frozen version 5 line.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. SimpleHomelab/Deployrr on GitHub