Swizzin: A Modular Seedbox Installer for Debian and Ubuntu

What Swizzin Solves and Who It Is Built For

Setting up a seedbox by hand means installing a torrent client, a web server, a reverse proxy, per-user authentication and a stack of media automation tools, then wiring them together so several users can share one machine without seeing each other's files. Swizzin packages that work into a single installer. The README describes it as a light, modular seedbox solution installed on Debian 11/12 or Ubuntu 20.04/22.04/24.04, and it ports over the QuickBox package repository, including the panel as an optional component.

The audience is narrow and specific: someone with root on a Debian or Ubuntu server who wants a multi-user seedbox without writing the provisioning themselves. The modular part matters. Packages are installed individually rather than as one monolith, so a box running qBittorrent and nginx does not have to carry rTorrent, ruTorrent, Sonarr, Radarr, SickRage, SickGear, Medusa, Transmission, Deluge or Plex. The README's own example, box install sickrage couchpotato plex, shows the model: you name what you want.

It is not a hosted service and not a control panel you install on top of an existing stack. Swizzin assumes it owns the machine's service layout, which is why the installation instructions are written for a fresh root login rather than for a server already running other web applications.

How the Installer and the box Command Fit Together

The repository layout is the architecture. setup.sh at the top level is the entry point. scripts/ holds the per-package install, remove and upgrade logic, which is why the README can point at scripts/upgrade when describing box upgrade. sources/ holds the package sources that the installer pulls from, and unattended.example.env is the template for non-interactive runs.

The data flow is straightforward. You run the installer as root. It asks questions interactively, or reads answers from flags and an env file. It then resolves each requested package against the script repository, installs it, and leaves a box command on the system for later changes. box list enumerates what the repository offers along with a description where one exists. box install takes one or more package names. box remove takes them away. box adduser, box deluser and box chpasswd manage the people who share the machine, one user per command invocation. box update pulls the newest changes from GitHub, and box upgrade targets a single package, with nginx given as the README's example.

Two commands sit slightly outside that pattern. box rmgrsec removes grsec kernels installed by OVH, which is a host-specific cleanup rather than a package operation. box rtx starts the ruTorrent extras management interface, and the README notes that typing rtx alone also works. The presence of both tells you the project expects to run on rented dedicated servers, not only on hardware you control.

Installing Swizzin and Running a First box install

The README recommends the quick installation method and states that it must run as root. It is explicit about how to become root: log in directly, or use su - or sudo -i. Do not use su or sudo -s. The reason given is environmental. Since mandatory cracklib checks were added, users who escalate with su can fail the check because /sbin and derivative paths are not set correctly, so the installer cannot find the cracklib-check binary even though it is installed.

The quick start is one line. The README gives both a wget and a curl form, and both end by sourcing .bashrc so the box command becomes available in the current shell.

bash <(wget -qO - s5n.sh) && . ~/.bashrc

After it finishes, the README states you should have a working box command. Running box list shows every package the repository offers with a description where one is available, which is the practical way to decide what to install next.

box list

Installing packages afterwards is a single command with one or more names. The README's example installs SickRage, CouchPotato and Plex together.

box install sickrage couchpotato plex

For anything scripted, the advanced setup supports flags. The --local flag installs from a clone of your own fork instead of cloning upstream, which is the path to take if you intend to modify package scripts.

git clone https://github.com/<your-fork>/swizzin.git
sudo bash swizzin/setup.sh --local

A fully unattended run takes the user name, password and package list as arguments. The README's example installs qbittorrent, nginx and panel for a user named tester.

bash <(curl -sL git.io/swizzin) --unattend qbittorrent nginx panel --user tester --pass test1234

For anything longer than a few packages, the --env flag reads a configuration file instead, and the README points at unattended.example.env as the template. The README labels the advanced setup as new and asks users to raise problems in Discord rather than treating it as settled.

Where Swizzin Is the Wrong Tool

The support matrix is the first constraint. The README lists long-term support branches only: Debian 11/12 and Ubuntu 20.04/22.04/24.04. Nothing else is claimed. The related searches include a Raspberry Pi question, and the README does not list ARM or Raspberry Pi OS as supported, so treat that as unverified rather than implied.

The second constraint is the privilege model. Swizzin installs services directly onto the host and expects a full root login. On a server where you already run other web applications, the nginx configuration and service ports are shared resources, and installing a package can collide with what is already there. There is no documented isolation boundary between Swizzin packages and the rest of the system.

The third constraint is the management surface. box update pulls the newest changes from GitHub, and box upgrade handles one package at a time. The README does not document rollback, so upgrading a package that breaks your setup has no described way back other than whatever your own backups provide. That is a real gap for anyone running this on a production box that other people depend on. The README also directs technical support away from GitHub issues, which are reserved for bug reports, and toward Discord and the documentation; if you need an auditable support trail, that is a structural mismatch.

Finally, the advanced setup is described in the README as fresh. Unattended installs and the --env workflow are the parts most likely to change, so automating around them carries more risk than the interactive path.

Swizzin Compared with Running a Containerized Seedbox

The obvious alternative, and one the search data reflects, is a Docker-based seedbox stack where each application runs in its own container with its own filesystem and network namespace. The difference in approach is not cosmetic. Swizzin installs packages onto the host through Shell scripts and manages them with box. A container stack builds images, mounts volumes, and manages services through a compose file or an orchestrator.

That changes the failure modes. With containers, a broken application upgrade is usually a matter of reverting an image tag, and two applications cannot fight over the same system library. With Swizzin, packages share the host's nginx, its ports and its users, and the upgrade path is box upgrade followed by whatever the package script does. The README documents no rollback, so the container approach has a clear advantage there.

Swizzin's advantage runs the other way. There is no container runtime to install or maintain, no image build step, and the multi-user model is built in through box adduser, box deluser and box chpasswd rather than delegated to per-container authentication. The panel is available as a package, and the QuickBox package repository was ported over, so a large set of applications is reachable through one command. If you want a single Debian host with several human users and a short list of packages, the host-install model is less machinery than a container stack. If you want per-application isolation and cheap rollbacks, it is more.

Maintenance, Licensing and Upgrade Cost

The repository is not archived, and the last push was on 2026-09-07, which is recent. The README labels the current line 3.15.0 Stable. There are no retrieved releases, so the CHANGELOG.md at the top level is the place to look for what changed between versions rather than a release feed.

Ongoing maintenance is a Shell-script problem. box update pulls the newest changes from GitHub, which means the box tracks the master branch rather than a pinned version. That is convenient and also means an update can change package scripts underneath you. box upgrade applies to one named package at a time, so a full refresh is a sequence of commands rather than one operation. Plan for the fact that the README documents no rollback for either command.

The licence is GPL-3.0. If you modify the scripts and distribute the result, the copyleft terms of that licence apply to the derivative work. Running a modified Swizzin on your own server for your own users is a different situation from shipping it to customers, and the distinction is worth confirming with someone qualified if you intend to redistribute. This is a description of the licence identifier in the repository, not legal advice.

The contribution path is documented: bug fixes and new applications go through pull requests, with a CONTRIBUTING.md at the top level and a commitlint configuration in the repository, which suggests commit message format is enforced. Feature requests and issues belong in GitHub discussions, and community help is on Discord.

Editorial conclusion

Swizzin fits administrators who want a Debian or Ubuntu host turned into a working seedbox through one interactive script and then managed with box install, box remove and box update. It is the wrong choice if you want container isolation, a non-Debian distribution, or a Raspberry Pi deployment, since the README lists only Debian 11/12 and Ubuntu 20.04/22.04/24.04 as supported. Before committing, verify three things on your own machine: that you can escalate with su - or sudo -i rather than su or sudo -s, that the package list from box list covers what you actually need, and that the unattended.example.env keys match the packages you intend to pass to --unattend.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Project website
4. README
5. swizzin/swizzin on GitHub