SwiftWave: a Go-based self-hosted PaaS that targets single-server deployments

The problem SwiftWave addresses: PaaS ergonomics without a managed control plane

Managed platforms such as Heroku, Netlify and Render give you a deploy command and a dashboard, and in exchange they own the machine your code runs on. SwiftWave inverts that. The README describes it as a self-hosted, lightweight PaaS for deploying and managing applications on any server, and lists bare metal, Raspberry Pi, and VPS providers including Hetzner, DigitalOcean, Linode, AWS and GCP as supported targets. The intended user is someone who already pays for a box and does not want a second bill or a second set of credentials. The repository topics reinforce the shape of the thing: docker, lightweight, paas, swarm-mode. That last topic is the most informative single word in the metadata, because it tells you the deployment substrate is Docker Swarm rather than a Kubernetes cluster or a plain container runtime. The audience is therefore narrow in a useful way. If you are comfortable with systemd, a reverse proxy and a firewall on a single host, SwiftWave is aimed at you. If your mental model of infrastructure starts with a cluster API, the project is not trying to meet you there.

What the repository actually tells you about the mechanism

The primary language is Go, which matters for two practical reasons: a compiled binary rather than a language runtime you must keep patched, and a small set of dependencies to audit. Beyond that, the repository is thin on mechanism. The README does not describe the control plane, the API surface, the database, or how a deploy request becomes a running container. It points outward instead, to swiftwave.org for a description of what is special about the project and to a separate installation guide. The contributor list shows three repositories in the organisation: the main swiftwave repository, app-store, and dashboard. The presence of a separate dashboard repository indicates a web UI is part of the product rather than an optional add-on, and app-store indicates a catalogue of deployable applications exists outside the core repo. That is a reasonable reading of the layout, and it is also the limit of what can be confirmed. Anyone who needs to know whether SwiftWave builds images from a Dockerfile, pulls from a registry, or does both will have to read the documentation site, because the README does not say.

Platform claims: architectures, distributions and what they imply

SwiftWave claims compatibility with AMD64, ARM64 and ARMv7, and with Debian, Ubuntu, Raspbian, Fedora, CentOS, AlmaLinux and Rocky Linux. ARMv7 is the interesting entry. It means the project is willing to support 32-bit ARM, which is the architecture of older Raspberry Pi boards and a class of cheap VPS instances, and it constrains the dependency set: anything that ships only 64-bit binaries cannot be in the critical path. The distribution list is broad in the RPM family and the DEB family, which suggests the installer handles package-manager differences rather than assuming apt. Note that the README says SwiftWave and its dependencies are compatible with those platforms, which is a compatibility statement, not a statement that the installer has been exercised on each combination. The installation guide is where you would check whether every listed distribution has its own instructions or whether some are covered by a general note. The repository does not answer that.

Getting it running: what the README gives you and what it withholds

The installation section of the README consists of a single instruction: check out the guide at swiftwave.org/docs/installation to install SwiftWave on your server and deploy your applications. There are no commands, no configuration keys, no environment variables, no systemd unit files, and no example manifest in the repository README. For an article of this kind that is a real limitation rather than a stylistic one, because it means the reproducibility of the setup cannot be assessed from the repository alone. The practical consequence for an evaluator is that the documentation site is not supplementary material, it is the specification. Before committing a server, read the installation guide end to end and confirm three things: that your distribution and architecture appear in it, that the guide states which ports and firewall rules the installer expects, and that it describes how to remove SwiftWave cleanly. The last point is the one most often missing from self-hosted installers, and it is the one that determines whether a failed trial leaves your box in a usable state.

Release cadence and the upgrade question

The recent release list shows 2.23.1-1 in August 2026, 2.22.4-1 in May 2026, and 2.22.3-1 in September 2025. The version strings carry a suffix, which suggests a packaging revision distinct from the upstream version, and the gap between 2.22.3-1 and 2.22.4-1 is roughly seven and a half months while the gap to 2.23.1-1 is about three months. That is a moderate cadence, not a fast one, and it is consistent with a small maintainer group. The default branch is develop rather than main or master, which is worth noting: the branch you land on when you clone is the development branch, so the code you read first is not necessarily the code behind the latest tagged release. For upgrade cost, the repository provides nothing. There is no changelog in the supplied material, no migration notes, and no statement about whether a minor version bump requires manual database steps. If you run SwiftWave in production, the upgrade procedure you follow has to come from the documentation site, and you should verify it exists before your first deploy rather than after your first incident.

Where SwiftWave is the wrong tool

The clearest failure mode is scale beyond one host. Docker Swarm can run multi-node clusters, but the project describes itself as lightweight and targets any VPS in the singular. Teams that need horizontal scheduling across many machines, per-workload autoscaling, or a service mesh will find themselves building those on top of a tool that was not designed around them, and the effort will exceed the cost of a platform that was. A second case is a team with no appetite for host maintenance. Self-hosting moves the patching, the TLS certificate renewal, the disk monitoring and the backup job onto you. SwiftWave reduces the work of deploying applications; it does not remove the work of running a server. Third, anyone who needs to audit behaviour from source before adopting will struggle, because the README documents almost no behaviour. That is not a defect in the software, but it is a real cost for a regulated environment where every component needs a written justification.

The alternative worth comparing: Dokku on the same box

The most direct comparison is Dokku, a single-server PaaS built around git push deploys and Heroku buildpacks. The difference in approach is architectural rather than cosmetic: Dokku is a set of shell tooling layered on Docker and nginx, driven from the command line, while SwiftWave is a Go application with a separate dashboard repository and an app-store repository, which points to an API-driven control plane with a web interface on top. That distinction shapes daily use. A Dokku workflow is a git remote and a terminal; a SwiftWave workflow appears, based on the repository layout, to include a UI for managing applications and a catalogue for installing them. Which is better depends on who does the deploying. If the answer is one engineer with SSH access, the command-line model is fewer moving parts. If the answer includes people who should not have shell access to the host, a dashboard is the reason to pick SwiftWave. Neither project's repository README settles the question of resource overhead, and that comparison would need to be made on your own hardware.

Licence and the maintenance arithmetic

SwiftWave is Apache-2.0. That is a permissive licence with an explicit patent grant and no copyleft obligation on your own code, which means you can run it commercially, modify it, and keep your modifications private. It also means the project carries no obligation to provide support, and nothing in the repository suggests a commercial backing entity. The README asks for stars for discoverability and directs financial support to GitHub Sponsors, which is the pattern of a maintainer-funded project rather than a vendor-funded one. Budget accordingly: the cost of adopting SwiftWave is not the licence fee, it is the time to read the documentation site carefully, plus the recurring time to track releases and apply them. If that recurring time is not something you can commit, a managed platform is cheaper in practice even though it has a monthly invoice. The Apache-2.0 terms themselves are short and worth reading directly rather than through a summary; this is a description of the licence, not legal advice.

Editorial conclusion

Adopt SwiftWave if you already run one VPS or a Raspberry Pi and want PaaS-style deploys without a managed control plane, and if you are willing to treat the linked installation guide as the real specification. Do not adopt it if you need a documented upgrade path, an in-repo configuration reference, or a compatibility matrix you can read without leaving GitHub. Verify first that the swiftwave.org installation guide covers your distribution and architecture, and that its upgrade instructions match the 2.23.1-1 release you intend to run.

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. swiftwave-org/swiftwave on GitHub