Open source
Apache 2.0.
One edition.
No paywall.
No license key, no enterprise tier, no feature gated behind a plan. The control plane, the agent and the MCP server are one source tree you can read, run and fork.
The real dashboard, Settings, Beta features. Anything still being proven carries a Beta badge and starts switched off.
No license key. No enterprise tier.
Everything below ships in the same binary, for everyone. SAML and SCIM are not supported yet.
- 01
OAuth sign-in
Sign in with an identity provider you already use, plus passkeys.
- 02
Two-factor authentication
TOTP codes for every account, in the same binary.
- 03
Audit logging
Who did what and when, exportable.
- 04
Resource-scoped IAM
Allow and Deny policies scoped to the apps and servers they should touch.
- 05
Scheduled backups
Database dumps on a schedule, to storage you choose, with a restore path.
What is not here yet.
A deploy platform is judged by its worst failure. These are the edges we know about, stated plainly.
- Pre-release
There is no stable release.
APIs, the app spec format and the on-disk layout can change between betas. Read the changelog before you upgrade.
- Well tested
One server is the well-tested path.
The control plane runs the node agent in the same process. That is the shape the end-to-end suite exercises most.
- Beta
Multiple servers are in beta.
Enrollment, cordon, drain and pinning work. Treat it as something to try, not something to depend on yet.
- Beta
The WireGuard mesh is not battle-tested.
It is the least verified part of multi-node, along with cross-host service names.
- Limit
Load balancing is HTTP only.
Traffic is balanced across replicas at the ingress. There is no TCP (layer 4) balancing.
- Limit
Private networks gate DNS names, not packets.
A private network decides which names resolve. It is not a firewall between containers.
- By design
Not a Kubernetes replacement.
No CRDs, no compatibility layer, nothing to learn beyond apps, domains and databases. Aimed at 3 to 50 services on 1 to 10 machines.
- By design
No autoscaling.
You choose the replica count. There is no scheduler with bin-packing.
- By design
No hosted offering.
It runs on servers you own. There is no managed cloud and no plan to sell one before real users exist.
Questions people ask first.
Not answered here? Ask in Discussions.
What is Levelrail?
A self-hosted platform that turns one or more Linux servers into a private cloud. Point it at a git repository or a Docker image and it builds, deploys, and keeps the app running, with TLS, logs, metrics, and rollback. The control plane and the node agent are each a single Go binary, and Docker is the only container runtime.
How is this different from Coolify or Railway?
Most self-hosted platforms in this category, Coolify included, manage remote servers by SSHing in and running docker CLI commands, then parsing the text output. Levelrail's agent dials out over mTLS and talks to the Docker Engine API directly, nothing shells out to the docker CLI, and a level-triggered reconciler replaces polling loops. Railway is a managed cloud you don't control, while Levelrail runs on servers you own. The comparison page covers where the other projects are the better choice.
Do I need to know Kubernetes?
No. Levelrail is not a Kubernetes alternative: there is no scheduler with bin-packing or autoscaling, no CRDs, and nothing to learn beyond apps, domains, and databases. It is built for running 3 to 50 services on 1 to 10 machines without operating a cluster.
Is it free?
Yes. Levelrail is Apache 2.0 licensed with one edition: no license key, no enterprise tier, and no feature gated behind a plan. OAuth sign-in, two-factor authentication, audit logging, resource-scoped IAM, and scheduled backups all ship in the same binary for everyone. SAML and SCIM are not supported yet.
Is it ready for production?
Not yet. There is no stable release, and APIs, the app spec format, and the on-disk layout can change between betas. A single node is the well-tested path, and the feature status page labels every area as stable, beta, or behind a flag, with the evidence for each.
Can I run it on a single server?
Yes, and that is the default. On one server the control plane runs the node agent in the same process and talks to it through an in-process transport, so there is nothing extra to install. The same code path serves one node or ten.
What happens if a deploy fails?
With the default blue-green strategy, and with rolling, traffic only moves to the new container once its readiness probe passes, not once the process merely starts. If the probe never passes, the old container keeps serving and the deploy fails with a specific reason such as OOMKilledDuringReadiness. The recreate strategy stops the old container before starting the new one, so expect a short gap. Prior images stay pinned, so garbage collection cannot remove a rollback target.
Does it support multiple servers?
Yes, and it is in beta. A second server joins with a one-time token and gets its own client certificate. Every agent dials out to the control plane, so managed servers need no inbound ports. You can cordon and drain nodes and pin apps to them. The WireGuard mesh and cross-host service DNS are the least verified part of this area.
Is there an AI or MCP integration?
Yes, in beta. An MCP server exposes up to 186 tools (145 in read-only mode) over the same HTTP API and permission model the dashboard uses, so an AI client can list apps, read logs, get metrics, diagnose a failed deploy, trigger a deploy, or roll back. A token limited to fewer abilities gets the same 403 the REST API returns. AI is never part of the reconciliation path.
Read it. Break it. Tell us.
- Repository Source, releases and the LICENSE file.
- Issues Bugs and requests. Report what broke.
- Discussions Questions, ideas and show-and-tell.
- Feature status Every area labelled stable, beta or flagged, with evidence.
- Roadmap What is being built, in order.
- Security overview How secrets, agents and sign-in are handled.