SwiftWave: a self-hosted PaaS that runs on one VPS

The problem SwiftWave targets: a deploy pipeline without a cloud account

The README states the project is a "self-hosted, lightweight PaaS solution for easily deploying and managing your applications on any server" and calls itself an open-source alternative to Heroku, Netlify, and Render. That framing is precise about the audience. The person who benefits is not a platform team with a Kubernetes cluster; it is an individual or a small group that already pays for a VPS at Hetzner, DigitalOcean, Linode, AWS or GCP and wants the push-to-deploy loop without the per-seat pricing or the vendor account.

SwiftWave is also positioned for hardware that managed platforms do not touch. The README lists bare metal, Raspberry Pi and VPS as install targets, and says SwiftWave and its dependencies are compatible with AMD64, ARM64 and ARMv7, on Debian, Ubuntu, Raspbian, Fedora, CentOS, AlmaLinux and Rocky Linux. That ARMv7 line matters: a 32-bit Raspberry Pi is below the floor of most container platforms, and the project explicitly claims it.

The trade is stated by the name. A lightweight PaaS gives you a smaller surface than Kubernetes, and it gives you less of the ecosystem. Everything the platform does not implement, you implement on the host.

How SwiftWave is built: Go services around Docker Swarm, HAProxy and Postgres

The repository layout reads as a set of managers rather than a monolith. Alongside main.go there are container_manager/, haproxy_manager/, ssl_manager/, udp_proxy_manager/, git_manager/, docker_config_generator/, ssh_toolkit/, task_queue/, pubsub/ and swiftwave_service/. The names describe the division of labour: one component talks to the container runtime, one rewrites proxy configuration, one obtains and renews certificates, one handles UDP ingress, one clones and pulls source, one renders Docker configuration files.

go.mod confirms the dependencies that make those directories work. The project requires github.com/docker/docker v27.1.1, which is the client library for the Docker API, and the repository topics include swarm-mode, so the scheduler underneath is Docker Swarm rather than a bespoke orchestrator. It requires github.com/mholt/acmez v1.2.0 for ACME certificate issuance, github.com/labstack/echo/v4 for the HTTP layer, github.com/99designs/gqlgen for GraphQL, gorm.io/gorm with gorm.io/driver/postgres for persistence, github.com/go-redis/redis/v8 for caching or queueing, and github.com/rabbitmq/amqp091-go for AMQP. The task_queue/ and pubsub/ directories line up with that Redis and RabbitMQ pair.

Source code arrives through go-git rather than a shell-out to the git binary, and schema changes are managed with golang-migrate plus ariga.io/atlas-provider-gorm. The presence of atlas.hcl, generate_migration.sh and rehash_migration_records.sh at the top level suggests migrations are a first-class, scripted concern rather than an afterthought. That is a reasonable design for a platform that has to upgrade itself in place on a server you own.

The data flow implied by this layout is: a deploy request reaches the Go service, the git manager fetches the repository, the container manager creates or updates a Swarm service, the docker config generator writes the configuration files that service needs, and the HAProxy and SSL managers update routing and certificates so the new version is reachable over HTTPS. The dashboard is a separate front end that talks to the same backend.

Installing SwiftWave and deploying a first application

The README does not carry install commands. It points to a guide: "Checkout this guide to install swiftwave on your server and deploy your applications", linking to https://swiftwave.org/docs/installation. That page is the authoritative source for the install steps, and it is where you should start, because the exact commands depend on your OS and architecture.

What the repository does document is how the binary and the bundled dashboard are produced. The Makefile defines the build chain, and package.json defines the dashboard build. If you are building from source rather than following the install guide, the sequence is: build the dashboard, then compile the Go binary with the dashboard assets embedded, then copy the binary into place. The Makefile targets are build_dashboard, build_service and install.

npm run build:dashboard

This runs prepare:dashboard_build, which initialises the dashboard git submodule, installs its npm dependencies, clears swiftwave_service/dashboard/www and recreates it, then builds the dashboard in production mode and copies dashboard/dist/* into swiftwave_service/dashboard/www. Because the dashboard is a submodule, a fresh clone without --recurse-submodules will not have the sources this step needs.

make build_service

build_service depends on build_dashboard, then runs CGO_ENABLED=0 go build . to produce the swiftwave binary in the repository root. The CGO_ENABLED=0 setting is what makes a single static binary feasible across the architectures the README lists.

make install

The install target depends on build_service and copies the resulting swiftwave binary to /usr/bin/swiftwave. That is the entire install target, so anything beyond placing the binary (service units, database, proxy configuration) is handled by the swiftwave.org install guide rather than by the Makefile.

Once the service is running, the deploy loop is the one the README describes: point SwiftWave at a git repository, let the git manager fetch it, and let the container manager run it as a Swarm service behind HAProxy with a certificate from the SSL manager. The dashboard is the interface for that; package.json's build:dashboard script is what populates it.

Where SwiftWave is the wrong choice

The dashboard is a git submodule, and that is a real operational constraint rather than a packaging detail. package.json's prepare:dashboard_build script runs git submodule update --init and then npm i inside dashboard/. Anyone building from source needs Node and npm on the build machine, and anyone upgrading has to keep the submodule in step with the main repository. A self-hosted PaaS that requires a JavaScript toolchain to produce its own admin UI is heavier than the word "lightweight" suggests.

The scheduler choice is the second constraint. Docker Swarm mode is the substrate, and Swarm's own trajectory is well known. If your team has standardised on Kubernetes, adopting SwiftWave means running a second orchestrator with a different API, a different mental model for services and a different ecosystem of operators. SwiftWave does not bridge that gap; it substitutes for it.

The third limitation is what the repository does not say. The README documents no backup procedure, no rollback path for a failed deploy, no high-availability story for the control plane, and no upgrade procedure beyond the Makefile's install target. For a platform that holds your database credentials and terminates your TLS, those are the questions that matter most, and they are not answered in the README. The docs site at swiftwave.org may cover them; the repository alone does not. Treat that as work you will do yourself.

Finally, single-server is the design centre. The README's install targets are all one machine. If you need multi-node scheduling with a control plane that survives the loss of a node, this is not that product.

SwiftWave compared with Dokku and Coolify

The closest alternatives are Dokku and Coolify, and the difference is architectural rather than cosmetic. Dokku is a thin layer over Docker on a single host: you push with git, a post-receive hook builds and runs the container, and nginx handles routing. There is no Swarm, no separate API server, no GraphQL layer and no database of its own beyond what the app uses. SwiftWave instead runs a persistent Go control plane with Postgres, Redis and RabbitMQ, and schedules onto Docker Swarm. That gives SwiftWave a real API and a dashboard, and it gives it more moving parts to keep alive.

Coolify is the other obvious comparison, and the difference is scope. Coolify spreads across more deployment targets and integrates a wider catalogue of databases and services; SwiftWave's own ecosystem is split into separate repositories, with swiftwave-org/app-store and swiftwave-org/dashboard listed among the contributors in the README. If you want a broad one-click catalogue, the app-store repository is where SwiftWave's version of that lives, and you should check its activity separately from the main repository.

A fourth option, which is not a competitor so much as the baseline, is a Compose file and a reverse proxy. If your deployment is three containers that change twice a month, SwiftWave's control plane is more infrastructure than the problem requires. SwiftWave earns its place when you have several applications, want per-application domains and certificates, and want that managed through an interface rather than by editing YAML.

Maintenance, releases and what Apache-2.0 means here

The repository is not archived and the last push was on 2026-09-03. Releases are tagged with a two-part version plus a build suffix: 2.23.1-1 on 2026-08-02, 2.22.4-1 on 2026-05-02, and 2.22.3-1 on 2025-09-19. The gap between 2.22.3-1 and 2.22.4-1 is roughly seven and a half months, so release cadence is not uniform, and you should read the release notes rather than assume a monthly train. The move from 2.22.x to 2.23.x is a minor version bump, which in most projects of this shape means migration work; the repository ships golang-migrate and an atlas.hcl configuration, so schema migrations are part of the upgrade path rather than something you improvise.

Upgrade cost has three parts you can see in the files. First, the Go toolchain: go.mod declares go 1.25.0, so a build machine needs a toolchain at least that new. Second, the dashboard submodule, which must be updated and rebuilt with npm. Third, the database migrations, run through the migration tooling the repository provides. None of these are unusual, but all three are manual, and the Makefile's install target only copies a binary.

The licence is Apache-2.0, stated in the README and present as LICENSE at the repository root. That is a permissive licence with an explicit patent grant, and it does not impose copyleft on your application code. It also means no vendor is obligated to support you. If you need a support contract or an SLA, the README points to a Slack channel and GitHub Sponsors rather than a commercial offering, and you should read that as the actual support model. This is a description of the licence text, not legal advice; if your organisation has licence review requirements, route it through them.

Editorial conclusion

Adopt SwiftWave if you already run a Linux VPS, are comfortable with Docker Swarm as the scheduler, and want the deploy loop on hardware you control; the Apache-2.0 licence and the AMD64/ARM64/ARMv7 builds make it usable on a Raspberry Pi as well as a Hetzner box. Do not adopt it if you need a managed control plane, a support contract, or a dashboard you can install without running npm. Before committing, verify three things in your own environment: that swiftwave.org/docs/installation covers your OS and architecture, that your server can expose the ports HAProxy and the SSL manager need, and that you are willing to rebuild the dashboard submodule on every upgrade.

Frequently asked questions

Official sources

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