Saltbox: Ansible-Driven Media Server Stacks on Ubuntu
Ansible-based solution for rapidly deploying a Docker containerized cloud media server.
At a glance
- What is it?
- Saltbox deploys a Docker containerized media server on a single Ubuntu host using Ansible, with no dashboard of its own. It is a good fit for a narrow, well-defined machine profile and a poor fit for anyone outside it.
- Who is it for?
- Adopt Saltbox if you have a dedicated x64 machine running Ubuntu Server 24.04 or 26.04 LTS (or an existing 22.04 LTS install), you are comfortable editing files in a text editor and working on the command line, and you want Plex, Sonarr, Radarr, rclone and the rest wired together by Ansible rather than by hand.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem Saltbox Solves: A Media Stack That Takes Days to Assemble
Standing up a self-hosted media server means installing and configuring a long list of applications that have to talk to each other: a media server such as Plex or Emby, indexers and download clients, request management, subtitle and library tooling, and a reverse proxy to expose the whole thing. Each application has its own install method, its own config format and its own assumptions about paths and permissions. Doing this by hand is slow, and it is worse the second time, because nothing about the first install is written down.
Saltbox addresses that by treating the whole stack as an Ansible-managed deployment. The README describes it as an Ansible-based solution for rapidly deploying a Docker containerized cloud media server, and notes it is heavily based on Cloudbox. The intended audience is clear from the platform constraints: a single x64 machine running Ubuntu Server. This is not a tool for a Kubernetes cluster, a mixed-architecture fleet, or a laptop. It is for one server that should end up running a known set of containers in a known configuration, reproducibly.
What Actually Gets Installed, and How the Pieces Are Wired
The README lists the featured applications rather than the full catalogue: Plex, Emby, Sonarr, Radarr, Lidarr, Rclone, SABnzbd, Tautulli, NZBHydra2, Jackett, Overseer, Autoscan, Cloudplow, Organizr, Portainer, Traktarr, Plex Dupefinder and Plex Patrol, with the list closing on "and more". The repository topics add Authelia, NZBGet, ruTorrent, Prowlarr and Traefik to that picture.
Those names describe a data flow. Indexers (Jackett, NZBHydra2, Prowlarr) feed search results to the automation applications (Sonarr, Radarr, Lidarr), which hand releases to download clients (SABnzbd, NZBGet, ruTorrent). Completed downloads land on disk, Autoscan triggers a library refresh, and the media server (Plex or Emby) plays the result. Traefik sits in front as the reverse proxy, and Authelia provides authentication for the services behind it. Rclone and Cloudplow handle the cloud storage leg, which the README describes as a lesser function relative to acquisition and playback.
The mechanism that holds this together is Ansible. Rather than shipping a shell script that runs once, Saltbox expresses the deployment as playbooks and roles, so the same description can be applied to a machine repeatedly. Docker provides the runtime isolation for the applications themselves. The README does not spell out the role layout in the material available here, so the exact inventory of playbooks has to be read from the repository and docs.saltbox.dev rather than inferred.
Supported Platforms: a Narrow List, Stated Without Hedging
The README is unusually direct about what Saltbox will and will not run on. Fresh installations are supported on x64 machines running Ubuntu Server 24.04 or 26.04 LTS. Existing Ubuntu Server 22.04 LTS installations remain supported. Non-LTS Ubuntu releases and Ubuntu Desktop installs are not supported. Linux distributions other than Ubuntu are not supported. ARM processors are not supported.
That is four separate exclusions, and they matter more than the feature list. Anyone running Debian, Rocky Linux or Arch is out. Anyone with an ARM board, including the popular single-board servers, is out. Anyone who installed the desktop flavour of Ubuntu is out, even though the underlying packages may look similar. The supported surface is one architecture and one distribution family, on server releases.
This is a deliberate trade-off rather than an oversight. Supporting one platform lets the Ansible roles assume specific package names, service names and paths. The cost is that Saltbox is not portable, and the project does not pretend otherwise. If you need portability across distributions or CPU architectures, this is the wrong tool, and the README says so before you install anything.
Getting It Running: Command Line, Text Editors, No Dashboard
The README states explicitly that Saltbox does not have a dashboard or GUI of its own, and that all Saltbox-specific setup and commands are done in text editors and on the command line. That single sentence sets the operating model. You will not click through a web installer. You will edit configuration files and run Ansible.
The README does not reproduce the install commands in the material available here, so the authoritative source is docs.saltbox.dev. What the repository does tell you is where to look for verification: the CI workflow lives at .github/workflows/saltbox.yml, and the badge at the top of the README links to it. Reading that workflow before you run anything shows which steps the project exercises automatically, which is more useful than a prose install guide when you are deciding whether to trust a playbook on your own machine.
Once the stack is up, Portainer appears in the featured list, so container-level inspection is available through it. That is not a Saltbox interface; it is a general Docker management UI that Saltbox deploys. The distinction matters when you are troubleshooting, because Portainer will show you container state but not Saltbox's own configuration model.
The practical expectation is that setup is a reading exercise. You read the docs, you edit files, you run the playbook, and you read the output when it fails. If that workflow is unfamiliar or unwelcome, Saltbox is the wrong choice regardless of how well it matches your hardware.
Where Saltbox Breaks Down: Platform Lock-In and the Absence of a GUI
The most obvious failure mode is trying to run Saltbox outside its supported matrix. An ARM host, a Debian box, an Ubuntu Desktop install or a non-LTS release will not be supported, and the README gives no fallback path. This is not a case where you can adapt the playbooks with minor edits and expect a working stack; the constraints are stated as absolutes.
The second limitation is the interface. Saltbox has no dashboard of its own. For an operator managing one server, that is fine. For a household where several people need to add media, adjust settings or restart a service, the absence of a unified control panel pushes that work onto whoever can use a terminal. Organizr appears in the featured applications and is commonly used as a portal for self-hosted services, but the README does not describe it as a Saltbox management interface, and it should not be treated as one.
The third consideration is scope of responsibility. Saltbox deploys containers; it does not take over the ongoing operation of them. Updating the stack, handling a failed download client, rotating credentials, and dealing with an indexer that changed its API are all outside what the README describes. The project automates the build, not the maintenance.
Finally, the README does not state whether Saltbox supports partial deployments, meaning installing only a subset of the featured applications. If you want Plex and Sonarr but not the download automation, that is a question to resolve in the documentation before adopting, not after.
Alternatives: Docker Compose by Hand Versus Ansible at Scale
The closest alternative in spirit is a hand-written Docker Compose file, or a set of them, describing the same containers. The difference is in what each approach optimizes for. Compose describes containers and their relationships declaratively, and it is portable across architectures and distributions, because it does not assume a particular host. Saltbox assumes a specific host and uses Ansible to configure it, which lets it do things Compose alone cannot: install packages, manage the host-level state, and re-apply the whole description to a fresh machine.
That is the real trade. A Compose stack is easier to move and easier to understand piece by piece, but you own every host-level detail yourself. Saltbox gives you a reproducible deployment on a supported machine and takes ownership of the host configuration, at the cost of the portability you gave up.
For a single Ubuntu server that will not change, Saltbox's approach is the more complete one. For a mixed environment, or for someone who wants to run the same stack on a NAS and a VPS, Compose is the better foundation, and Saltbox's platform restrictions make it a non-starter rather than a preference.
A third path is a general-purpose self-hosting platform that provides a web UI for deploying and managing containerized applications. Those trade the specificity of Saltbox's media-oriented roles for a broader catalogue and a graphical interface. The README's featured list is the clearest signal of which side Saltbox is on: it is opinionated about the applications, not about giving you a control panel for them.
Licence, Maintenance and What to Check Before You Commit
Saltbox is licensed under GPL-3.0. The practical consequence for most users is that running Saltbox on your own server does not trigger distribution obligations, because you are not conveying the software to anyone. If you modify Saltbox and distribute the modified version, GPL-3.0's copyleft terms apply to that distribution. This is a general description of how the licence works, not legal advice; if you plan to redistribute a modified Saltbox, read LICENSE.md and consult someone qualified.
The project is not archived, and the last push recorded is 2026-09-09. No releases were retrieved in the material available here, which means versioning, if it exists, is not visible from the release feed. For a deployment tool, that is worth noting: there is no release artefact to pin to, so the practical upgrade path is tracking the master branch. Upgrading means re-running the playbooks against a stack that is already running, and the README does not describe a rollback procedure. Take a snapshot of the machine before you upgrade.
The homepage is https://docs.saltbox.dev, and it is the source for install commands and configuration keys, neither of which appears in the README. The README points to a Discord server for support, which is where operational questions about a project without releases tend to land. The README also notes that Saltbox is heavily based on Cloudbox, so anyone migrating from Cloudbox should read the documentation for the differences rather than assuming the two behave identically.
Editorial conclusion
Adopt Saltbox if you have a dedicated x64 machine running Ubuntu Server 24.04 or 26.04 LTS (or an existing 22.04 LTS install), you are comfortable editing files in a text editor and working on the command line, and you want Plex, Sonarr, Radarr, rclone and the rest wired together by Ansible rather than by hand. Do not adopt it on ARM, on Ubuntu Desktop or a non-LTS release, on a non-Ubuntu distribution, or if you need a web UI for stack management, because the README states plainly that Saltbox has no dashboard or GUI of its own. Before committing, read docs.saltbox.dev end to end, confirm the supported Ubuntu version for your host, and check the CI workflow at .github/workflows/saltbox.yml to see what the project itself exercises on each push.
Community notes