Your own cloud. No Kubernetes.git push. Get a running app.Any server. One control plane.Ship it. Only when healthy.Broke prod? One command back.No SSH keys. No inbound ports. Your own cloud. No Kubernetes.

Levelrail, one word. People often search for it as "Level Rail" or "LevelRail", and all of those mean the same open source, self-hosted deployment platform at levelrail.com, not a railway product.

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.

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.

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.

Yes. Levelrail is Apache 2.0 licensed with one edition: no license key 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.

A single node is the well-tested path. APIs, the app spec format, and the on-disk layout can change between releases on the way to 1.0. 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.

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.

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.

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.

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.