A self-hosted alternative to Heroku, and where it falls short

What carries over from a push-to-deploy platform

If you like the Heroku workflow, the shape is familiar: push to a git repository or an image tag, and Levelrail builds, deploys and keeps the app running with TLS, logs, metrics and rollback. The difference is where it runs. Levelrail is software you install on Linux servers you own, so there is no per-dyno or per-app fee. You pay for the servers.

A new container takes traffic only after its readiness probe passes, and the previous images stay pinned, so the rollback target is already on the node. There are previews, scheduled jobs and pipelines, and managed databases with scheduled backups that can be restore-tested. The side-by-side with Heroku lists 28 capabilities, each with a link to the project's own documentation, and marks anything not stated there as not stated.

What is different, and what you take on

• Builds use your Dockerfile, or Railpack when there is none, or a prebuilt image. They are not Heroku buildpacks, so check that your stack builds cleanly before you move.
• There is no `git push heroku` style remote by default. Deploys come from a connected git provider, a repository URL or a container image. A native git push remote exists but is beta and off.
• Add-ons are replaced by databases and templates you run yourself: the catalog has 359 one-click service templates, and databases are managed by the platform on your servers.
• Nobody else runs the servers. You apply updates, watch disk, keep the master key backed up and are the one on call. A hosted platform charges for taking that off you, and this one does not.
• There is no hosted offering. Help comes through GitHub Discussions, issues and the community Discord.

Who it fits

• Your apps are containers, or can be, and you are leaving a hosted platform because of per-seat, per-dyno or usage pricing.
• You run, or are willing to run, one or a few Linux servers and want git-driven deploys without assembling the pieces yourself.
• You want observability in the core: metrics and searchable logs stored on the node that produced them, with crashloop detection and alerts.

Who it does not fit

• You want the vendor to handle operations. With a self-hosted platform you are responsible for the servers.
• You depend on Heroku buildpacks, release phase behavior or a marketplace of vendor-run add-ons and do not want to replace them.
• You need a global edge network, an edge runtime or built-in image optimization. Those are not provided.
• You need a platform with a long record in production. Levelrail is young and the evidence is below.

What is verified

Levelrail labels every feature by how well it is tested. See what is verified. A single node is the well-tested path, multi-node is in beta and load balancing is HTTP only. Deploy approvals, Postgres point-in-time restore, post-deploy watch with automatic rollback on hard signals, and sleep when idle are labelled stable, each backed by a live end-to-end test on one machine. None of them has a run on a fresh VPS with a real public domain.

On a 2 vCPU, 8 GB Linux test box on 2026-10-19 the control plane idled at 200 MB of memory and 1.5 percent CPU with no apps. Of 100 templates smoke-tested on 2026-10-25, 93 started healthy, on one arm64 Mac with a harness that emulates compose, not on a VPS. Each claim, its source and its date are on the verified page, together with what is not verified yet.

A sensible way to move

Run Levelrail next to your current platform first. Start with one low-risk app and keep the old deployment live until the new one has run cleanly for a while. The Heroku alternative guide in the docs and the alternatives page list what moves and what you rebuild by hand.

Next

• What is verified
• Compare with Heroku, sourced
• All alternatives
• Coolify alternative
• Lightweight self-hosted PaaS
• Free and open source
• Install