# Levelrail: full text > Levelrail is a self-hosted deployment platform. It turns one or more Linux servers into a private cloud: push to a git repository or an image tag 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, Docker is the only container runtime, and the license is Apache 2.0. It is pre-release: a single node is the well-tested path and multi-node is in beta. ## Key facts - Agents dial out to the control plane over mutual TLS; nothing connects in, so no inbound ports or SSH keys are needed on managed servers. - A level-triggered reconciler compares desired and observed state on every pass and records a status condition with a reason. - State is SQLite in WAL mode; ingress, TLS and HTTP load balancing use an embedded Caddy; metrics and logs stay on the node that produced them. - Idle footprint on a development build: 68 MB of memory with no apps, 91 MB with 500 suspended apps, 1.6% CPU at 500 suspended apps. - 358 one-click service templates; 48 of the top 50 passed a live smoke run on 2026-10-19, the rest pass structural checks only. ## Known limits (stated plainly) - Pre-release: no stable release; APIs, the app spec and the on-disk layout can change between betas. - A single node is the well-tested path; multi-node is in beta and the WireGuard mesh is not battle-tested. - Load balancing is HTTP only; there is no TCP (layer 4) balancing yet. - Private networks gate DNS name resolution, they are not a packet filter. - Not a Kubernetes replacement: no bin-packing scheduler and no CRDs; autoscaling is beta. - No hosted offering: it runs on servers you own. ## Pages ### Home https://levelrail.com/ What Levelrail is, the three tiers (edge, control plane, nodes), the dashboard, the template gallery and the install command. ### Deploys and rollback https://levelrail.com/deploys/ Readiness-gated cutover, digest-pinned images, one-command rollback, previews, schedules and pipelines. ### Observability https://levelrail.com/observability/ Per-app metrics, searchable logs, automatic crashloop context and alerts, kept on each node and queried on demand. ### Networking: seven layers, three of them run by Levelrail https://levelrail.com/networking/ Levelrail runs layer 7 (ingress, TLS, HTTP balancing, request firewall), layer 3 (WireGuard mesh, private networks, mesh DNS) and part of layer 4. The rest stays with your host and your app. ### Architecture https://levelrail.com/architecture/ The level-triggered reconciler, agents that dial out, and the four written decisions (ADR 002, 003, 007, 008). ### Service templates https://levelrail.com/templates/ 358 one-click self-host templates across databases, CMSs, analytics, automation, storage and monitoring. ### Comparison https://levelrail.com/compare/ A sourced comparison with Coolify, Dokploy, CapRover, Dokku, Kamal, Vercel, Heroku, Railway and Cloud Run across 28 capabilities, including what Levelrail does not do yet. ### Migrate to Levelrail https://levelrail.com/migrate/ A read-only importer with a dry run for Coolify, Dokploy and CapRover: the four steps, what does not migrate, and manual paths for other platforms. ### Migrate from Coolify https://levelrail.com/migrate/coolify/ Import Coolify apps, databases, env vars and domains with a dry run first, what is done by hand, and how to cut over. ### Migrate from Dokploy https://levelrail.com/migrate/dokploy/ Import Dokploy apps, databases, env vars and domains with a dry run first, what is done by hand, and how to cut over. ### Migrate from CapRover https://levelrail.com/migrate/caprover/ Import CapRover apps, databases, env vars and domains with a dry run first, what is done by hand, and how to cut over. ### Install https://levelrail.com/install/ The one-line server install, requirements, what the installer does, supported hosts, the CLI-only install and uninstall. Latest release v0.8.4, published October 24, 2026; downloads for Linux amd64 and arm64, Docker images, CLI, checksums and cosign signatures. ### Levelrail vs Coolify https://levelrail.com/compare/coolify/ Sourced side-by-side with Coolify: where each is ahead, the capability table, migration and FAQ. ### Levelrail vs Dokploy https://levelrail.com/compare/dokploy/ Sourced side-by-side with Dokploy: where each is ahead, the capability table, migration and FAQ. ### Levelrail vs CapRover https://levelrail.com/compare/caprover/ Sourced side-by-side with CapRover: where each is ahead, the capability table, migration and FAQ. ### Levelrail vs Dokku https://levelrail.com/compare/dokku/ Sourced side-by-side with Dokku: where each is ahead, the capability table, migration and FAQ. ### Levelrail vs Kamal https://levelrail.com/compare/kamal/ Sourced side-by-side with Kamal: where each is ahead, the capability table, migration and FAQ. ### Levelrail vs Vercel https://levelrail.com/compare/vercel/ Sourced side-by-side with Vercel: where each is ahead, the capability table, migration and FAQ. ### Levelrail vs Heroku https://levelrail.com/compare/heroku/ Sourced side-by-side with Heroku: where each is ahead, the capability table, migration and FAQ. ### Levelrail vs Railway https://levelrail.com/compare/railway/ Sourced side-by-side with Railway: where each is ahead, the capability table, migration and FAQ. ### Levelrail vs Cloud Run https://levelrail.com/compare/cloud-run/ Sourced side-by-side with Cloud Run: where each is ahead, the capability table, migration and FAQ. ### Why Levelrail https://levelrail.com/why-levelrail/ The problem, how an agent-based control plane differs from SSH shelling, who it is for and not for, and the honest limits. ### Use cases https://levelrail.com/use-cases/ Seven jobs it is built for, each with what you get and what to know first. ### Self-host Next.js and Node apps with Levelrail https://levelrail.com/use-cases/self-host-nextjs/ Deploy Next.js and Node apps from GitHub to your own server with Levelrail: Dockerfile builds, PR previews, safe cutover and one-command rollback. ### Database backups and restore drills with Levelrail https://levelrail.com/use-cases/databases-backups/ Run Postgres, Redis, MySQL and other databases on your own servers with Levelrail: scheduled backups, Postgres point-in-time restore and restore drills. ### Run side projects on one cheap VPS with Levelrail https://levelrail.com/use-cases/side-projects/ Host several side projects on one small VPS with Levelrail: a domain and logs per app, metrics, rollback and sleep-when-idle, with no per-service fee. ### Self-Host Internal Tools with Access Control | Levelrail https://levelrail.com/use-cases/internal-tools/ Self-host dashboards, automation tools and wikis on your own server with Levelrail: one-click templates, two-factor sign-in, scoped tokens, audit log. ### Host Client Apps as an Agency or Freelancer | Levelrail https://levelrail.com/use-cases/agencies/ Host client apps on servers you control with Levelrail: scoped tokens limit a contractor to one app, an audit log records who deployed what. ### Run a Homelab and VPS Fleet from One Panel | Levelrail https://levelrail.com/use-cases/homelab/ Manage a home server, a VPS and a cloud VM from one Levelrail control plane. Agents dial out over mutual TLS, so managed machines open no inbound ports. ### Operate servers from an AI agent with Levelrail MCP https://levelrail.com/use-cases/ai-agents/ Let an AI assistant read your Levelrail apps, logs and crashloops over MCP, with read-only mode, scoped tokens and confirm-gated writes. ### Alternatives https://levelrail.com/alternatives/ What you keep and give up moving from Vercel, Heroku, Railway, Coolify, Dokploy or CapRover, with links to sourced comparisons and migration guides. ### Pricing https://levelrail.com/pricing/ Free: Apache 2.0, one edition, no license key and no paid tier. You pay only for your servers. ### Security https://levelrail.com/security/ Envelope-encrypted secrets, mutual TLS agents, scoped tokens, IAM policies, an audit log, and what is not true yet. ### Open source https://levelrail.com/open-source/ Apache 2.0, one edition, no license key and no enterprise tier; what is not here yet; frequently asked questions. ## Comparison matrix (as of 2026-10, from each project's official documentation) | Capability | Levelrail | Coolify | Dokploy | CapRover | Dokku | Kamal | Vercel | Heroku | Railway | Cloud Run | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | No SSH: agents dial out | yes | no | no | no | no | no | not applicable | not applicable | not applicable | not applicable | | Level-triggered reconciler with status reasons | yes | not stated in their docs | not stated in their docs | not stated in their docs | no | no | not applicable | not applicable | not applicable | not applicable | | Single control plane binary | yes | no | no | not stated in their docs | not applicable | not applicable | not applicable | not applicable | not applicable | not applicable | | Metrics and log search built in | yes | partly | partly | partly | no | no | partly | partly | yes | yes | | Crashloop diagnosis with last log lines | yes | not stated in their docs | not stated in their docs | not stated in their docs | partly | not stated in their docs | not stated in their docs | partly | partly | partly | | One-click rollback with pinned images | yes | yes | yes | yes | partly | partly | partly | yes | partly | yes | | Readiness-gated deploys (zero-downtime on one node) | yes | partly | partly | yes | yes | yes | not stated in their docs | partly | partly | partly | | Preview environments per pull request | yes | yes | partly | not stated in their docs | not stated in their docs | not stated in their docs | yes | yes | yes | partly | | Docker Compose apps | partly | yes | yes | partly | not stated in their docs | not stated in their docs | no | not stated in their docs | partly | partly | | Git push deploys from GitHub, GitLab, Bitbucket | partly | yes | yes | partly | partly | not stated in their docs | yes | partly | partly | yes | | Builds from source without a Dockerfile | partly | yes | yes | partly | partly | partly | yes | yes | yes | yes | | Scheduled jobs | yes | yes | yes | not stated in their docs | yes | not stated in their docs | yes | partly | yes | partly | | Managed databases with scheduled backups | partly | yes | yes | partly | partly | partly | partly | partly | partly | not stated in their docs | | Encrypted secrets for env vars | yes | partly | partly | not stated in their docs | not stated in their docs | partly | yes | not stated in their docs | yes | yes | | Private networking between apps or nodes | partly | partly | not stated in their docs | yes | partly | partly | partly | partly | yes | partly | | Load balancing across replicas | partly | partly | yes | yes | partly | not stated in their docs | not applicable | yes | yes | yes | | Request firewall, rate limits, bot protection | yes | partly | not stated in their docs | not stated in their docs | not stated in their docs | not stated in their docs | partly | not stated in their docs | partly | partly | | Automatic TLS certificates | partly | yes | yes | yes | partly | partly | yes | yes | yes | partly | | Multi-node | partly | yes | yes | yes | partly | yes | not applicable | not applicable | not applicable | not applicable | | One-click service templates | yes | yes | yes | yes | not stated in their docs | not stated in their docs | partly | partly | yes | not stated in their docs | | Autoscaling | partly | no | not stated in their docs | no | no | not stated in their docs | yes | partly | no | yes | | CLI and HTTP API | yes | partly | partly | partly | partly | not applicable | yes | partly | partly | yes | | Deploy and alert notifications | partly | yes | yes | partly | partly | partly | partly | partly | yes | partly | | MCP / AI assistant integration | yes | yes | not stated in their docs | not stated in their docs | not stated in their docs | not stated in their docs | yes | yes | yes | partly | | Runs on servers you own | yes | yes | yes | yes | yes | yes | not applicable | not applicable | not applicable | not applicable | | Open source license | yes | yes | not stated in their docs | yes | yes | yes | not stated in their docs | not stated in their docs | not stated in their docs | not stated in their docs | | IAM, audit log and 2FA in the free edition | yes | partly | partly | partly | partly | partly | partly | partly | partly | partly | | SAML or SCIM single sign-on | partly | partly | yes | not stated in their docs | not stated in their docs | not applicable | partly | partly | partly | not stated in their docs | Sources for every researched cell are linked on https://levelrail.com/compare/. Product names and logos belong to their owners and are used for identification only. ## Use cases ### Self-host Next.js and Node apps from GitHub https://levelrail.com/use-cases/self-host-nextjs/ JSON: https://levelrail.com/use-cases/self-host-nextjs.json Levelrail builds a Next.js or Node app from your Dockerfile on every git push and runs it on a server you own. The new version takes traffic only after its readiness probe passes, and earlier images stay pinned for rollback. Coming from Vercel? Here is [how the two compare](/compare/vercel/). What you get: - Four git hosts: Connect GitHub, GitLab, Bitbucket or Gitea. A push triggers a build, and traffic moves to the new version once its readiness probe passes. - Pull request previews: Each pull request gets its own preview environment. Stable on GitHub, beta on GitLab and Bitbucket. - Encrypted environment: Environment variables are encrypted per app. Set environment variables such as NEXT_PUBLIC_* before the build, since Next.js inlines them at build time. - Database next door: Add Postgres or Redis as a managed resource beside the app, with scheduled backups. Databases with backups covers how those get checked. - One-command rollback: Roll back to a pinned earlier image with one command. The older version must pass its health checks before it takes traffic again. More on how deploys work. Steps: 1. Install on a server: Run the install command on a Linux server. 2. Connect the repository: Add a Dockerfile to the repository, then connect it from the dashboard and pick a git host, build pack and deploy trigger. 3. Configure and push: Set your environment variables, add a domain and push. Good to know (scope and maturity): - Apps run as containers on your own server, which covers builds, previews, rollback and a database. There is no built-in edge runtime, ISR cache, image optimization service or visitor analytics, so put a CDN in front if you want edge delivery. - Browser-trusted certificates work once you enable public ACME (Let's Encrypt) in settings. Until then certificates are self-signed and browsers show a warning. Networking covers domains and TLS. - Deploys start from a webhook sent by your git host, and that is the supported path. A native git push remote exists, but it is in beta and off by default. FAQ: Q: How do I self-host a Next.js app? A: Install Levelrail on a Linux server, add a Dockerfile to your repository and connect it. Every push then builds the image and deploys it. Use output: 'standalone' in next.config, as in the example above. Q: Does Levelrail support the Next.js edge runtime and image optimization? A: No. The app runs as a plain container, so features that depend on a managed edge network, such as an edge runtime or built-in image optimization, are not provided. Put a CDN in front if you want edge caching. Q: Can I get preview deployments for pull requests? A: Yes. Pull requests get their own preview environment on GitHub (stable) and on GitLab and Bitbucket (beta). Set an apps base domain for clean preview URLs. Q: How do I roll back a bad deploy? A: Run the rollback command and Levelrail switches back to a pinned earlier image once it passes health and readiness checks. Every deploy is listed with its status and logs on the deploy history page. Docs: - [Self-host Next.js guide](https://docs.levelrail.com/self-host-nextjs) - [Migrating from Vercel](https://docs.levelrail.com/migrating-from-vercel) - [Preview environments](https://docs.levelrail.com/previews) - [Rollback](https://docs.levelrail.com/rollback) Source: - [Cutover logic](https://github.com/glincker/levelrail/tree/main/internal/cutover) - [Rollback logic](https://github.com/glincker/levelrail/tree/main/internal/rollback) - [Preview environments](https://github.com/glincker/levelrail/tree/main/internal/preview) - [Git host webhooks](https://github.com/glincker/levelrail/tree/main/internal/webhook) ### Self-hosted databases with backups you can restore https://levelrail.com/use-cases/databases-backups/ JSON: https://levelrail.com/use-cases/databases-backups.json Levelrail creates Postgres, Redis, MySQL and other databases from the dashboard, CLI or API, links them to your apps and backs them up on a schedule to storage you own. A backup file is not a backup until a restore of it has worked, so [restore drills](docs:/prove-your-backups-work) are built in. What you get: - Thirteen engines: Thirteen engines are defined, including Postgres, MySQL, MariaDB, Redis and MongoDB. You create them like any other resource and attach them to apps such as Next.js and Node services. - Scheduled backups: Backups run on a schedule with retention, to any S3-compatible bucket. Storage credentials are write-only once saved. - Postgres point-in-time: Point-in-time restore for Postgres, covered by a live end-to-end test against object storage that recovers data after both the data volume and the WAL archive volume are deleted. (stable) - Restore drills: A drill restores a backup into a scratch resource, validates it and destroys it. It runs weekly by default. - Control plane snapshots: Snapshots of the control plane itself, with the master key kept out of the snapshot. The architecture page shows what the control plane holds. Steps: 1. Create the database: Create the database from the dashboard, CLI or API and note the connection details Levelrail generates. 2. Attach and schedule: Attach it to an app, then add a backup schedule and an S3-compatible storage target. 3. Run a restore drill: Run a restore drill from the Backups page and read the result before you rely on the backup. Good to know (scope and maturity): - Postgres is the stable path: point-in-time restore and the dump, restore and verify cycle both work today. Other engines are beta until each has a live restore run, and their drills check the object and its checksum, which proves the file is whole but not that it replays. Details in backups and storage. - Point-in-time WAL is shipped to the backup target only for databases on the control plane's own node, so plan on scheduled dumps for databases placed elsewhere. - Keep a copy of the master key apart from the data directory. Backed-up secrets cannot be decrypted without it, and the control plane snapshot leaves it out on purpose. See security for how secrets are handled. FAQ: Q: How do I know my database backup works? A: Run a restore drill from the Backups page. It checks the object, compares its checksum, restores it into a throwaway resource, validates the result and removes the scratch copy. Drills also run automatically once a week by default. Q: Does Levelrail support Postgres point-in-time recovery? A: Yes, for Postgres. You turn it on per database, and you can recover only from the moment it was enabled. Other engines get scheduled dumps or snapshots and are labeled beta. Q: Where are database backups stored? A: In an S3-compatible bucket that you own, such as AWS S3, Cloudflare R2, Backblaze B2, MinIO or Wasabi. Credentials are write-only once saved. Docs: - [Managing databases](https://docs.levelrail.com/managing-databases) - [Prove your backups work](https://docs.levelrail.com/prove-your-backups-work) - [Backups and storage](https://docs.levelrail.com/backups-and-storage) - [Control plane backup](https://docs.levelrail.com/control-plane-backup) Source: - [Backup engine](https://github.com/glincker/levelrail/tree/main/internal/backup) - [Control plane backup](https://github.com/glincker/levelrail/tree/main/internal/cpbackup) - [Database access](https://github.com/glincker/levelrail/tree/main/internal/dbaccess) ### Host side projects on one cheap VPS https://levelrail.com/use-cases/side-projects/ JSON: https://levelrail.com/use-cases/side-projects.json Levelrail runs several side projects on one small Linux VPS. The control plane and the agent run together in one process, so there is nothing extra to install, and the only bill is the server you already rent. A single node is the best-tested setup. What you get: - Two binaries: One binary is the control plane and one is the agent. On a single server they run together. - Built-in observability: Metrics at 15 second resolution and searchable logs stay on the node, so there is no Grafana or log shipper to set up. - Sleep when idle: An app with no requests for a time you choose stops, frees its memory and wakes on the next request. Setup is in sleep when idle. - Template catalog: Pick the database or tool a project needs from the template catalog, including one-click Postgres and Redis. - No license key: Levelrail is Apache 2.0 licensed, with no license key and no paid tier. See pricing. Steps: 1. Install on a VPS: Rent a small Linux VPS and run the install command. 2. Create apps: Create an app from a repository or an image, then point a domain at the server. 3. Enable sleep: Turn on sleep when idle for the projects that get little traffic. Good to know (scope and maturity): - A 1 vCPU, 1 GB RAM server is enough to boot the control plane. Builds and several running apps are more comfortable with 2 vCPU and 2 GB. No minimum has been benchmarked, so treat both as starting points. - A sleeping app takes seconds to wake, mostly the time your app needs to boot, and the first visitor waits for it. Leave sleep off for anything that must answer instantly. - The idle footprint figures come from a development build and vary with hardware. Read the benchmarks before you size a server. FAQ: Q: How big a VPS do I need to self-host side projects? A: A 1 vCPU, 1 GB server runs the control plane, and 2 vCPU with 2 GB is more comfortable once builds and apps run. These are starting points, not benchmarked minimums. Q: Can I run several projects on one VPS? A: Yes. Each project is its own app with its own domain, environment variables, logs and rollback history, and single-node installs are the best-tested setup. If the server sits at home instead of in a data center, see the homelab use case. Q: Does Levelrail cost anything? A: No. There is no license key and no paid tier, so your cost is the server itself. Docs: - [Quickstart](https://docs.levelrail.com/getting-started) - [Sleep when idle](https://docs.levelrail.com/sleep-when-idle) - [Benchmarks](https://docs.levelrail.com/benchmarks) Source: - [Sleep when idle](https://github.com/glincker/levelrail/tree/main/internal/appsleep) - [Idle footprint](https://github.com/glincker/levelrail/tree/main/internal/footprint) - [Command line entry point](https://github.com/glincker/levelrail/tree/main/cmd/levelrail) ### Self-host internal tools with roles, two-factor and an audit log https://levelrail.com/use-cases/internal-tools/ JSON: https://levelrail.com/use-cases/internal-tools.json Levelrail lets you run a dashboard, an automation tool or a wiki on your own server: deploy it from the [template catalog](/templates/), attach your domain, and decide who can reach the platform. Sign-in, roles and the audit log are all in the free binary. What you get: - Template catalog: About 360 one-click templates cover databases, CMSs, analytics, automation, storage and monitoring. Set the variables, then deploy. (beta) - Sign-in options: Email and password with TOTP two-factor, OAuth and OpenID Connect providers, and passkeys per account. The security model explains how sessions and tokens are handled. - Scoped IAM policies: Allow and Deny IAM policies can be scoped to one app or database, on top of the admin, operator and viewer roles. A teammate can get the one app they work on and nothing else. - Audit log: Sensitive requests are logged with the actor and the caller surface (dashboard, CLI, MCP or API). Export the log as CSV from the CLI or the API. - Protected environments: Mark an environment as protected and moves into it wait for an approval. Deploy freezes block moves until you override them with a reason. Steps: 1. Pick a template: Pick a template from the catalog, fill in its variables and deploy it. Check that it boots before you tell the team about it. 2. Add domain and access: Add your domain, then create users or tokens with the narrowest ability that does the job. The Identity and access guide lists every ability. 3. Enable two-factor: Turn on two-factor for every account that holds root. The Security center lists the accounts that still lack it. Good to know (scope and maturity): - Templates are labeled beta. Live tests deploy a sample of them and the rest pass structural checks, so boot the one you need in a staging environment first. - OAuth and OpenID Connect sign-in work today. SAML single sign-on and SCIM are beta and off by default, and they have not yet been checked against a live identity provider, so keep them out of your critical path for now. - Projects and organizations are labels. Access is enforced by roles and IAM policies rather than project membership, so use policies to limit who sees what. Agencies shows a per-client setup. FAQ: Q: How do I restrict who can use a self-hosted internal tool? A: Use roles and IAM policies to control who can manage the tool on the platform. Who can open the tool itself depends on how you expose its domain and on the tool's own login, so set both. Q: Does Levelrail support single sign-on for the dashboard? A: OAuth and OpenID Connect sign-in are included and ready to use. SAML and SCIM sit behind a beta toggle and have not been verified against a live identity provider, so treat them as experimental. If your tools keep data in a database, read databases and backups too. Docs: - [Self-host gallery](https://docs.levelrail.com/self-host) - [Identity and access](https://docs.levelrail.com/identity-and-access) - [Security center](https://docs.levelrail.com/security-center) - [Environments](https://docs.levelrail.com/environments) Source: - [Template catalog](https://github.com/glincker/levelrail/tree/main/internal/catalog) - [TOTP two-factor](https://github.com/glincker/levelrail/tree/main/internal/totp) - [OpenID Connect](https://github.com/glincker/levelrail/tree/main/internal/oidc) - [IAM policy engine](https://github.com/glincker/levelrail/tree/main/internal/accesspolicy) ### Host client apps on servers your agency controls https://levelrail.com/use-cases/agencies/ JSON: https://levelrail.com/use-cases/agencies.json With Levelrail an agency can keep client apps on its own infrastructure, hand a contractor a token that reaches exactly one app, and keep a record of who deployed what. Start with the [IAM policy guide](docs:/identity-and-access) to see how scoping works. What you get: - Scoped IAM policies: Write IAM policies scoped to app:name or database:name. An explicit Deny always wins, even over root. - Queryable audit log: Every sensitive request is logged with actor, ability, method, path and caller surface, and you can filter the log by any of them. - Group client work: Projects, organizations and environments group each client's work and share environment variables. See managing apps at scale. - Client importer: A read-only importer with a dry run brings a client over from Coolify, Dokploy or CapRover without touching the old server. The Coolify migration guide walks through it. - Per-client nodes: When a client needs its own server, provision one on Hetzner, DigitalOcean, AWS, Azure or GCP from the same control plane. Steps: 1. Group by client: Put each client under a project and tag its apps with an environment. 2. Mint scoped tokens: Create one token per contractor with a single ability, then add an Allow policy for that client's app only. 3. Test the boundary: Try the token against another client's app and confirm it is refused. Do this before you hand it over. Good to know (scope and maturity): - You get scoped access, audit logs and per-client nodes. Levelrail does not include billing, metering or a customer-facing subscription layer, so it is infrastructure you operate rather than a reselling platform. - Access is enforced through IAM policies and roles on users and tokens. Teams and per-project membership are not built yet, so model each client with policies. - Single-node hosting is the tested path. Multi-node is beta: enrollment, cordon and drain are verified locally, and the WireGuard mesh has not been proven across a real WAN. The multi-node guide lists what has been tested. FAQ: Q: Can a client or contractor see only their own app? A: Yes, give their user or token an IAM policy that allows only that app. Test it with a real token before you hand it over, and see internal tools for how roles and two-factor fit in. Q: Can I bill clients through Levelrail? A: No, there is no billing or metering layer. You can scope what each client reaches, but invoicing happens outside the project. Compare it with other tools on the alternatives page. Docs: - [Identity and access](https://docs.levelrail.com/identity-and-access) - [Managing apps at scale](https://docs.levelrail.com/managing-apps-at-scale) - [Node provisioning](https://docs.levelrail.com/node-provisioning) Source: - [IAM policy engine](https://github.com/glincker/levelrail/tree/main/internal/accesspolicy) - [Platform importer](https://github.com/glincker/levelrail/tree/main/internal/platformimport) - [Node provisioning](https://github.com/glincker/levelrail/tree/main/internal/provision) ### One control plane for your homelab and your VPS https://levelrail.com/use-cases/homelab/ JSON: https://levelrail.com/use-cases/homelab.json Agents dial out to the Levelrail control plane over mutual TLS, so a server behind home NAT joins the same way a cloud VM does. Managed machines accept no inbound connections and store no SSH keys. Before you start, read the [networking overview](/networking/). What you get: - Join token and agent: Add a server with a one-time join token and a small agent. Only the control plane needs to be reachable: the docs examples use port 9443 for agents. - Explicit placement: Placement is explicit. Cordon and drain move apps off a node when you need to take it down. (beta) - Event streaming: Docker events stream up from each agent, so the control plane never polls machines over SSH. - Local metrics and logs: Metrics and logs stay on the node that produced them and are queried on demand, which keeps a small home server light. - Home templates: Templates exist for media, home automation and file tools. Browse the template catalog. Steps: 1. Install control plane: Install the control plane on the machine that has a public address. The install guide covers it. 2. Join each machine: Create a join token and run the agent installer on each other machine. 3. Place your apps: Open the app's settings and choose the node it should run on. Good to know (scope and maturity): - A single node is the tested path. Multi-node is beta: enrollment, cordon and drain are verified across two real Docker daemons on one machine, while NAT traversal and the WireGuard mesh over a real WAN are untested. Follow the multi-node quickstart and keep a fallback. - The WireGuard mesh is optional. If you turn it on across hosts, open inbound UDP 51820 on the control plane. Private networks control which apps can resolve each other by name, and they are not a packet filter. - Load balancing covers HTTP only. FAQ: Q: Can I manage a server behind NAT or CGNAT? A: Yes, because the agent dials out and the server needs no inbound ports. The control plane itself needs a reachable address, and NAT traversal across a real WAN has not been tested yet. Q: Is multi-node ready for production? A: Not yet: it is in beta, and a single node is the well-tested path. Run multi-node next to something you already trust until your own testing says otherwise. Architecture explains how the control plane and agents fit together. Docs: - [Multi-node quickstart](https://docs.levelrail.com/multi-node-quickstart) - [Multi-node](https://docs.levelrail.com/multi-node) - [Network topology](https://docs.levelrail.com/network-topology) - [Private networks](https://docs.levelrail.com/private-networks) Source: - [Agent](https://github.com/glincker/levelrail/tree/main/internal/agent) - [Agent binary](https://github.com/glincker/levelrail/tree/main/cmd/levelrail-agent) - [Placement](https://github.com/glincker/levelrail/tree/main/internal/placement) - [Private networks](https://github.com/glincker/levelrail/tree/main/internal/privnet) ### Let an AI agent read and diagnose your servers over MCP https://levelrail.com/use-cases/ai-agents/ JSON: https://levelrail.com/use-cases/ai-agents.json The Levelrail MCP server lets an AI assistant list apps, read logs and diagnose a crashloop through the same API and permissions as the dashboard and CLI. The assistant sits beside the [deterministic reconciler](/architecture/), never inside it: it reads and suggests, and any write is explicit and confirmed. What you get: - Read tools: Tools for apps, logs, metrics and status, plus read-only diagnostics such as crashloop analysis. (beta) - Token-scoped tool lists: The tool list follows the token. A read-only token never sees a write tool. (beta) - Read-only flag: The --readonly flag checks the token's abilities with the API and refuses to start if it holds write, deploy or root. (beta) - Gated writes: Write tools stay hidden until you pass --allow-write, and each call must repeat the resource name to confirm it. Calls are audited and bound by the token's abilities. (beta) - On-demand toolsets: A small core loads first. Enable a toolset (databases, backups and so on) only when the conversation needs it, which keeps the tool list short. (beta) - In-app AI chat: The chat inside the dashboard is behind a feature flag and off by default. (flag) Steps: 1. Create a narrow token: Create a token with the narrowest ability that works, for example read only. Scoping and transports are covered in the integration guide. 2. Print a client config: Print a config block for your assistant, paste it into the client, add your token, and start the server in read-only mode. 3. Add write mode later: If a token needs to act, enable write mode for that token only and add an explicit IAM Deny on production. Good to know (scope and maturity): - The MCP server covers apps, logs, metrics, diagnostics and the write tools described above, and its tool registry has unit tests. It is beta, though, and the full surface has not been exercised end to end, so start with read-only mode. - The in-app AI chat works when you turn on its feature flag. It is off by default, and the MCP server does not depend on it. - Any agent that reads logs can be fed hostile text, which is prompt injection. Narrow tokens, read-only mode and confirm-gated writes limit the damage; the MCP threat model explains how tool output is marked as untrusted. FAQ: Q: Is AI involved in deciding what gets deployed? A: No. The reconciler is deterministic and level-triggered, with no AI inside it. The MCP server is a read and suggest layer over the API, and writes need an explicit flag and a confirmation. Q: Which AI assistants work with the MCP server? A: Any MCP client. The server prints a ready config block for Claude, Cursor, VS Code and Zed with `levelrail-mcp --print-config `. Tool counts per toolset show what each one costs in context. Q: Can an AI agent change or delete my apps? A: Only if you allow it. A read-only token cannot, and write tools stay off until you pass --allow-write. Even then each call needs a matching confirm value and respects the token's abilities. Q: How do I try it? A: Install the control plane on one server, create a read-only token, then run `levelrail-mcp --print-config claude` and paste the block into your client. Docs: - [MCP tools and write mode](https://docs.levelrail.com/mcp) - [AI assistant integration](https://docs.levelrail.com/ai-assistant) - [MCP tool surface](https://docs.levelrail.com/mcp-tool-surface) Source: - [MCP server binary](https://github.com/glincker/levelrail/tree/main/cmd/levelrail-mcp) - [MCP tool registry](https://github.com/glincker/levelrail/tree/main/internal/mcptools) - [In-app AI](https://github.com/glincker/levelrail/tree/main/internal/ai) ## Frequently asked questions ### 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. ### What is the best self-hosted alternative to Coolify? It depends on what you want. Dokploy and CapRover fit a Docker Swarm model, Dokku and Kamal fit one server with the fewest moving parts, and Levelrail fits teams that want an agent-based control plane with metrics, logs, IAM and audit in one binary. Levelrail is pre-release and Coolify has the larger template catalog and track record, so read the sourced comparison before choosing. ### What is a self-hosted alternative to Vercel, Heroku or Railway? Levelrail gives you webhook-driven git deploys, preview environments, TLS (self-signed until you enable Let's Encrypt), logs, metrics and rollback on servers you own. It does not offer a global edge network, an edge runtime, ISR, image optimization, visitor analytics or a managed cloud. Functions exist but are container cold starts, so if you need the rest, a hosted platform is the better fit. Dokku is the closest minimal option for a single server. ### Can I migrate from Coolify, Dokploy or CapRover to Levelrail? Yes. Levelrail has a read-only importer with a dry-run mode, so you can keep the old platform running while you try the new one, then move DNS when you trust it. The migration guide in the docs walks through it. ### Which self-hosted deployment platform is the lightest? Levelrail is one Go binary for the control plane and one for the agent. On a 2 vCPU, 8 GB Linux test box the control plane idled at about 200 MB of memory and 1.5% CPU with no apps. Smaller figures (68 MB with no apps, 91 MB with 500 suspended apps) come from an Apple M4 Max development build and are not comparable. Both are single runs, and the method and limits are published in the docs. ### Is Levelrail a good alternative to Coolify? Large catalog of one-click services and a polished dashboard, managing existing servers over plain SSH. How Levelrail differs: An agent dials out over mTLS to the Docker Engine API instead of SSH from the control plane. A level-triggered reconciler records a status reason per pass, instead of Docker Compose per resource. Metrics, log search and rollback with pinned images ship in the core. Choose Coolify instead when you want the broadest template list and SSH-only server management. Levelrail is pre-release, so check the comparison for what it does not do yet. ### Is Levelrail a good alternative to Dokploy? A polished project built on Docker Swarm, with a modern dashboard on top. How Levelrail differs: Plain Docker with a reconciler and a small agent per node, with no Swarm or overlay network. Metrics, full-text logs and crashloop detection ship in the core with no extra stack. One Go binary with embedded SQLite and embedded Caddy, instead of Traefik. Choose Dokploy instead when docker Swarm is already your model, and you want multi-node scheduling and rolling updates from a mature mechanism. Levelrail is pre-release, so check the comparison for what it does not do yet. ### Is Levelrail a good alternative to CapRover? A long-running, simple, Swarm-based platform with a one-click app store and a CLI. How Levelrail differs: Plain Docker containers with a level-triggered reconciler instead of Swarm services. An agent per node dials out over mTLS, so managed servers need no inbound port. Caddy embedded for ingress instead of nginx, with metrics and logs in the core. Choose CapRover instead when docker Swarm is already your model, or you want a long-running platform with a large install base and app store. Levelrail is pre-release, so check the comparison for what it does not do yet. ### Is Levelrail a good alternative to Dokku? The classic Heroku on your own box: git push to deploy, buildpacks, a rich plugin ecosystem. How Levelrail differs: A dashboard with deploy history and one-click rollback to a pinned previous image. Metrics and log search in the core, where Dokku suggests adding your own stack. More servers join with a one-time token and an agent that dials out. Choose Dokku instead when you run one server and want the simplest possible thing. Levelrail is pre-release, so check the comparison for what it does not do yet. ### Is Levelrail a good alternative to Kamal? Deliberately minimal: no control plane, database or agent, running over SSH from your machine or CI. How Levelrail differs: Desired state lives in a database, with a reconciler recording a status reason after every pass. Agents dial out, so CI uses a scoped API token instead of holding SSH keys. Adds a dashboard, deploy history, rollback and built-in observability, and is heavier by design. Choose Kamal instead when you want the fewest possible moving parts and do not need a dashboard. Levelrail is pre-release, so check the comparison for what it does not do yet. ### Is Levelrail a good alternative to Vercel? A managed cloud with a global edge network, git integration, previews and instant rollback. How Levelrail differs: Runs on Linux servers you own, so secrets, metrics and logs stay on your nodes. Cost is the servers you rent, not per request or per seat. Container apps built from a Dockerfile. Functions sleep when idle and cold start as containers; there is no edge runtime or edge network. Choose Vercel instead when you need a global edge network, an edge runtime, ISR, image optimization, visitor analytics or Blob and KV storage; Levelrail offers none of them and suggests a CDN in front. Levelrail is pre-release, so check the comparison for what it does not do yet. ### Is Levelrail a good alternative to Heroku? A managed platform: git push, buildpacks and release phase, billed per dyno and per add-on. How Levelrail differs: Runs on Linux boxes you own, with no per-dyno or per-app fee. Eight managed database engines with scheduled, verified backups instead of add-ons. Dockerfile builds with readiness-gated cutover, not buildpacks. Choose Heroku instead when you want the vendor to handle operations, since with Levelrail you are the one on call for the servers. Levelrail is pre-release, so check the comparison for what it does not do yet. ### Is Levelrail a good alternative to Railway? A vendor-managed cloud with usage-based pricing and environments per pull request. How Levelrail differs: Runs on your Linux servers, so pricing is your own server cost. Secrets, metrics and logs stay on your nodes unless you configure an export. Self-hosted software only; there is no managed cloud version. Choose Railway instead when you want a vendor-managed cloud rather than operating your own servers; Levelrail has no managed version. Levelrail is pre-release, so check the comparison for what it does not do yet. ### Is Levelrail a good alternative to Cloud Run? A good fit for bursty traffic, with scale to zero and per-request billing. How Levelrail differs: A fixed-price server you run, so cost does not move with traffic. Replicas are fixed with no autoscaling, and wake from sleep is slower than a cold start. Logs, metrics and data stay on machines you control, with nothing billed by volume. Choose Cloud Run instead when traffic is spiky or rare, you need capacity in seconds, or you depend on Google identity and networking features. Levelrail is pre-release, so check the comparison for what it does not do yet. ## Guides - [Our Health Check Failed and the Deploy Went Live Anyway](https://levelrail.com/blog/health-check-passes-dead-container/): A postmortem from our own dogfood run: a failed readiness probe still received traffic. What broke, why two correct parts added up to a bug, and the fix. (Markdown: https://levelrail.com/blog/health-check-passes-dead-container.md) - [Roll Back a Failed Docker Deploy Without Downtime](https://levelrail.com/blog/rollback-failed-deploy-docker/): Ship a broken release on purpose, watch your users stay on the old version, then roll back with one command. Real commands, real output, self-hosted. (Markdown: https://levelrail.com/blog/rollback-failed-deploy-docker.md) - [Install a Self-Hosted PaaS on Your Own Server in Five Minutes](https://levelrail.com/blog/install-levelrail-five-minutes/): One curl command, one setup token, one sample app. The full Levelrail install on a fresh Linux server, with the checks and the fixes. (Markdown: https://levelrail.com/blog/install-levelrail-five-minutes.md) - [Restart a Docker Container Without Downtime](https://levelrail.com/blog/restart-docker-app-without-downtime/): Restart a Docker app with one command and zero failed requests, then see what a plain stop and start costs. Real output from a self-hosted run. (Markdown: https://levelrail.com/blog/restart-docker-app-without-downtime.md) - [Update the PHP Docker Image Security Patch, No Downtime](https://levelrail.com/blog/ship-php-security-update-docker-zero-downtime/): Move a Dockerized PHP app from 8.4.26 to the 8.4.27 security release with zero failed requests, pin the image by digest, and see a bad update get refused. (Markdown: https://levelrail.com/blog/ship-php-security-update-docker-zero-downtime.md) - [Docker Container Restarting in a Loop: 5 Causes, Fixed](https://levelrail.com/blog/docker-container-restarting-in-a-loop/): Five real reasons a Docker container keeps restarting, each reproduced with its exit code, the command that finds it and the fix. Then the same crash on Levelrail. (Markdown: https://levelrail.com/blog/docker-container-restarting-in-a-loop.md) ## Documentation - [Quickstart](https://docs.levelrail.com/getting-started): Install and deploy a first app. - [Installing](https://docs.levelrail.com/installing): Server install and requirements. - [CLI reference](https://docs.levelrail.com/cli-reference): Every levelrail-cli command. - [API reference](https://docs.levelrail.com/api-reference): REST endpoints and abilities. - [Feature status](https://docs.levelrail.com/feature-status): What is stable, beta or experimental. - [Security](https://docs.levelrail.com/security): Security model and hardening. - [Comparison](https://docs.levelrail.com/comparison): Comparison with other platforms. - [Roadmap](https://docs.levelrail.com/roadmap): What is planned next.