Aven: a self-hosted, Railway-style PaaS

English | 한국어

Use it like Railway, but on your own server, with no usage-based pricing.

Quick start · Comparison · Feature stability · Highlights · How it works · Docs · FAQ

Railway, Coolify, and Dokploy are trademarks of their owners. Aven is not affiliated with them. Those names appear here only to describe what Aven is like and how it compares.

Important

Aven is an independent project and this repository contains no Railway source code. The canvas and service workflow follow Railway's, and Aven reads railway.json / railway.toml and answers Railway-shaped GraphQL queries so a project can move over. See Relationship to Railway.

• Run it on your own servers. One aven-server process sits next to Docker; more machines join with aven-agent. There is no Kubernetes cluster to operate.
• The software in this repository has no usage fees and no paid feature tier. You pay for the machines you run.
• The license is AGPL-3.0-only. SAML SSO and passkeys ship in that same core.
• The canvas, railway.json, and a Railway-shaped GraphQL API follow a Railway-style workflow.
• GitHub push deploys, pull-request preview environments, and one-click Postgres, MySQL, Redis, and MongoDB are included.

Note

Aven is young and moves quickly. Interfaces and settings can change between releases, so read the release notes and back up the data directory before upgrading. The stability labels below say what the tests in this tree cover. They are not a support commitment.

Quick start

The Linux installer is install-server.sh. One command starts the install. It still needs a machine you operate, Docker, and, for automatic TLS, a domain whose DNS you control. You pay for the server and for the domain. This repository does not charge a usage fee.

A native Windows service on Windows 10/11 is a different path: Windows host guide. Windows Server editions are not supported by Docker Desktop. The steps below are the Linux path.

What you need

The installer checks the first list. It does not measure memory, disk, or a Docker version.

• Machine. Linux, amd64 (x86_64) or arm64 (aarch64), with systemd (systemctl, and /run/systemd/system). curl, tar, and sha256sum or openssl.

• Docker. The docker command, and a daemon that answers docker info for root. The unit file does not set User=, so aven-server runs as root. If Docker is missing, the script can install it from get.docker.com when you confirm or pass --install-docker. The proxy image it starts is caddy:2-alpine.

• Memory and disk. Not checked. aven-server is one process. The proxy is one container. Each app and database is another container and, for databases, a volume. The control-plane files (aven.db, master.key) live under /var/lib/aven. Leave disk for the images and volumes you are going to run.

• Ports on this host. 80/tcp, 443/tcp, and 443/udp free. The proxy publishes all three (443/udp is HTTP/3). The dashboard API listens on 127.0.0.1:7070 and is not published. With more than one server, the mesh listens only on that node's private address, port 7443, when the address is a private IP.

• A name and DNS, for automatic TLS. An https:// name for the dashboard, for example aven.example.com. For generated service hostnames, a base domain such as apps.example.com. Point them at this server before the first request that needs a certificate:

  Name	Type	Value
  aven.example.com	A and/or AAAA	this server's public address
  *.apps.example.com	A and/or AAAA	the same address

  Each concrete hostname gets its own certificate on the first TLS handshake (HTTP-01 or TLS-ALPN). Aven does not request one certificate for the wildcard name itself. Ports 80 and 443 have to be reachable from the public internet. The base domain you type becomes AVEN_BASE_DOMAIN.

  With no domain, the installer can serve the dashboard only at http://localhost:7070 on that machine.

More than one server is optional. Extra machines need Docker and must reach the main server over HTTPS. A private network such as Tailscale or WireGuard is how services on different machines reach each other.

Read the script, then run it

curl -fsSL https://raw.githubusercontent.com/turin-dev/aven/main/install-server.sh -o install-server.sh
less install-server.sh          # or: sh install-server.sh --help
sh install-server.sh

Run that as a normal user. The script starts itself again with sudo. Piped into sudo sh, sudo-rs (the default sudo since Ubuntu 25.10) keeps the script in the background of the terminal, where it cannot ask questions, and it stops unless --yes is set.

On a terminal the first question is the role: main server (dashboard and API) or region server (joins an existing main server). A main server then asks for the dashboard URL, the base domain, an optional Let's Encrypt email, and the admin@local password. It shows a summary and changes nothing until you confirm. It checks the release checksum, installs the files below, writes /etc/aven/aven.env, starts the service, and prints the sign-in details and the DNS names.

Unattended, after you have read the script:

sudo sh install-server.sh --yes \
  --public-url https://aven.example.com \
  --base-domain apps.example.com \
  --acme-email you@example.com

What a main-server install changes

• /usr/local/bin/aven-server and /usr/local/bin/aven
• Railpack at /usr/local/bin/railpack, unless you pass --no-railpack or railpack is already on PATH (the script's default Railpack release is v0.42.0)
• agent and CLI downloads in /usr/local/lib/aven/
• /etc/systemd/system/aven-server.service
• /etc/aven/aven.env (mode 0600) and /etc/aven/aven.env.example
• on first start, /var/lib/aven (aven.db, master.key, session.key, logs/), a Docker network named aven, and the aven-proxy container with volumes aven-caddy-data, aven-caddy-config, and aven-proxy-wake

A region server does not install aven-server. It installs /usr/local/bin/aven-agent, writes /etc/keel-agent/agent.env, stores the node credential in /var/lib/keel-agent/credentials.json, and enables keel-agent.service. Those are the paths and the unit name the agent installer still creates, including on a machine that never ran Keel, so an existing agent is replaced in place. Settings inside that env file use the AVEN_* names. KEEL_* is still read.

An install that already has /etc/keel/aven.env or /var/lib/keel keeps those paths. See the self-hosting guide.

Check that it started

systemctl is-active aven-server
curl -fsS -o /dev/null http://127.0.0.1:7070/api/cli/downloads
docker ps --filter name=aven-proxy --format '{{.Names}} {{.Status}}'

The installer waits until that URL answers, then prints the dashboard URL and the password if it generated one. Sign in as admin@local. The English UI label is Admin → Owner · Setup (/admin/?section=setup). The Korean UI label is 어드민 → Owner · 초기 설정.

Open a project, press Add on the canvas, and deploy a service. The self-hosting guide is the long version: every installer option, a manual install, backups and restore (including PITR), upgrades, uninstall, and the failure modes below.

If it does not come up

• Port 80 or 443 is taken. The installer warns and continues. aven-server then exits. journalctl -u aven-server contains start the proxy: and ports AVEN_HTTP_PORT/AVEN_HTTPS_PORT, default 80/443, must be free. ss -Htlpn 'sport = :80' shows the listener.
• DNS has not propagated, or TLS is not issued. The install does not wait for a certificate. If the dashboard name does not resolve, the installer warns. Certificates are requested on the first HTTPS request. docker logs aven-proxy shows ACME errors. On an install that still runs keel-proxy, read that container instead.
• Docker. docker info has to succeed as root. "not running" and "cannot use its socket" are different errors. The second one is a permissions failure.
• Firewall or IPv6. Docker-published ports are not filtered by ufw's INPUT chain. A cloud firewall in front of the host still is. An AAAA record for an address this host does not answer on makes clients that prefer IPv6 fail while IPv4 works.
• The agent does not join. journalctl -u keel-agent. The join token is single-use. The default lifetime is 1 hour (the API accepts 60 seconds to 24 hours). AVEN_PUBLIC_URL on the main server has to be an https:// URL.

Commands and what to change are in Troubleshooting.

Install by hand, or remove it

Hand install is steps 3–6 of the self-hosting guide. There is no uninstall script. Uninstall and roll back lists the units, containers, and files to stop and delete, and how an upgrade copy under /var/lib/aven/backups/ plus /usr/local/bin/aven-server.prev is put back.

Screenshots

Canvas	Deployments
Variables	Networking

Comparison

Aven cells come from this repository. Competitor cells come from the official pages linked under the table, checked on 2026-10-27. “Not documented” means those pages did not describe the feature. It is not a claim that the feature is missing.

	Aven	Railway	Coolify	Dokploy
Self-hosted	Yes. aven-server on your Linux host; more hosts run aven-agent. 1	Hosted plans from Free through Enterprise. Enterprise adds Railway-managed dedicated hosts. An installer for your own servers is not documented. 2 3	Yes. Self-hosted is the free edition. 4	Yes. Self-Hosted (OSS). 5
Pricing model	No usage fees and no paid-feature gate in this repository. You pay for your own machines. 1	Per-second CPU, memory, and volume usage, plus a plan fee. The Free plan is $0 with $1 of usage credit per month. 2	Self-hosted is free and includes all current and upcoming features. Cloud is $5/month for two servers, then $3/month per extra server. 4	Self-Hosted (OSS) is free. Cloud starts at $4.50/month per server. Enterprise is a license (contact). 5
License	AGPL-3.0-only. 6	The platform source is not published. The CLI is open source. 7	Apache-2.0. 8	Apache-2.0, except a /proprietary directory if present, which LICENSE.MD places under a separate proprietary license. 9
SSO in the free tier	Yes. SAML SSO is in the core. 10	No on the Free plan. SSO is listed for Enterprise and for committed spend. 2	Yes on self-hosted (the free edition), from v4.3.0. Coolify Cloud manages its own sign-in. 11	No. SSO is Enterprise only. The OSS and non-Enterprise Cloud editions do not include it. 5
Passkeys	Yes. WebAuthn passkeys for dashboard sign-in. 12	Yes, as account MFA. The MFA page names no plan restriction. 13	Not documented for Coolify's own sign-in (2FA and SSO are). 14	Yes, for panel sign-in. The Cloud plan table does not list them for Hobby. 15
Multi-node	Yes. Additional servers join with aven-agent. 16	Horizontal replicas (plan limits) and geographic regions, on Railway's platform. Attaching your own servers is not documented. 17	Yes. Self-hosted can connect unlimited servers. 4	Yes. Multi-server / remote servers on the OSS edition. 5
Preview environments	Yes. Pull-request environments. 18	Yes. PR environments, created when a pull request opens and removed when it merges or closes. 19	Yes. Pull-request and merge-request previews. 20	Yes. GitHub pull-request previews, off by default. 21
Managed databases	One-click Postgres, MySQL, Redis, MongoDB, and an S3-compatible bucket, on your servers. 22	Postgres, MySQL, Redis, and MongoDB templates. Railway provisions each one. HA is a conversion you turn on. 23	One-click Postgres, MySQL, MariaDB, MongoDB, Redis, Dragonfly, KeyDB, and ClickHouse, plus SQLite marked experimental, on your servers. 24	MySQL, PostgreSQL, MongoDB, Redis, and MariaDB, on your servers. 25
PITR / backups	Postgres WAL and MySQL binlog PITR to backup storage, logical database backups, and a copy of Aven's own SQLite database. 26	Volume backups, and PITR for Postgres and MySQL, which you turn on. 27	Scheduled dumps (Postgres uses pg_dump / pg_dumpall) with optional S3. The Postgres guide says PITR is continuous WAL archiving you set up separately. 28	Manual and scheduled database backups. PITR is not documented. 25
Git push deploy	GitHub push webhooks. This tree has no git receive-pack server. 29	GitHub autodeploy when the connected branch is pushed. 30	Deploy on push through a GitHub App, GitLab, or a repository webhook. 31	GitHub autodeploy on push. Webhooks for GitHub, GitLab, Bitbucket, and Gitea. 32
Dockerfile / buildpack / Nixpacks	Dockerfile and Railpack. Unknown railway.json keys such as nixpacksPlan are ignored. A Dokploy nixpacks build is imported as Railpack. 33	Railpack and Dockerfile. Heroku and Paketo buildpacks were retired in 2025, and the build docs no longer mention Nixpacks. 34 35	Nixpacks, Dockerfile, Docker Compose, and static. Buildpacks are not among the documented build packs. 36	Nixpacks (the default), Railpack, Dockerfile, Heroku buildpacks, Paketo buildpacks, and static. 37
Web UI	Yes. Embedded dashboard, English and Korean. 1	Yes. Project canvas and service settings. 38	Yes. Dashboard. 4	Yes. Dashboard. 5
CLI	Yes. aven. 39	Yes. Railway CLI, documented as open source. 7	Yes. coolify. 40	Yes. @dokploy/cli. 41

Feature stability

Stable means the feature is described for operators in this repository and has dedicated tests here. Experimental means that bar was not met. The reason is in the last column. Either label can change, and a Stable feature can still move between releases.

Feature	Label	Why
Single-server install (aven-server, Docker, Caddy proxy)	Stable	install-server.sh, docs/self-hosting.md, internal/selfhost/*_test.go
Extra servers (aven-agent) and the private mesh	Stable	Self-hosting guide, “Adding servers”; internal/agent/*_test.go, internal/deploy/mesh_test.go
GitHub push-to-deploy and pull-request previews	Stable	internal/api/github_preview_test.go, internal/watch/watch_test.go
Dockerfile and Railpack builds	Stable	internal/node/railpack_test.go, internal/config/config_test.go
Image services, Compose, templates, functions, aven up	Stable	internal/compose/compose_test.go, internal/api/templates_test.go, internal/api/functions_test.go, internal/agent/extra_test.go (TestSourceUploadExtractsSafely)
Environments, variable references, sealed variables, config as code	Stable	internal/vars/vars_test.go, internal/api/sealed_test.go, internal/config/config_test.go
One-click Postgres, MySQL, Redis, MongoDB, and S3-compatible buckets	Stable	internal/catalog/catalog.go and its tests, internal/api/bucket_test.go
Data browser	Stable	internal/api/dbdata_test.go, internal/api/dbdata_edit_test.go
Logical backups and PITR (Postgres WAL, MySQL binlog)	Stable	docs/cli.md aven pitr; internal/agent/dbbackup_test.go, internal/api/dbpitr_test.go
PgBouncer, Postgres major upgrades, database HA	Stable	internal/api/postgres_test.go, internal/catalog/ha_test.go, cmd/aven/ha_test.go
Domains, automatic TLS, path rules, redirects, basic auth, wildcards	Stable	internal/proxy/caddy_test.go (TestPathRulesOrdering, TestRedirectAndAuthAndTrust, TestBuildWildcardAutoTLS)
Per-domain IPv6 and TCP proxies	Stable	internal/deploy/ipv6addr_test.go, internal/deploy/ports_test.go
Private DNS between services	Stable	internal/deploy/privatedns_test.go
Edge cache and WAF rules	Stable	internal/api/edge_test.go, internal/proxy/edge_test.go
Cloudflare Tunnel ingress	Experimental	The ingress mode is stored and validated in internal/api/domainstate_test.go. No test starts a tunnel.
Replicas, autoscaling, rollbacks, deploy overlap	Stable	internal/deploy/scale_test.go, overlap settings in internal/api/batch2_test.go
Moving a volume onto another node	Stable	internal/deploy/remote_test.go (TestCopyVolumesCopiesDataAndReportsOldLocation)
App sleeping (wake on the next request)	Experimental	Implemented in internal/deploy/sleep.go. Config parsing is tested. No test covers the idle-sleep and wake path.
Cron schedules	Experimental	Expressions are parsed and stored (internal/cronx/cron_test.go, API tests). No test was found that fires a scheduled run.
Image auto-updates	Stable	internal/deploy/imageupdates_test.go
Logs, metrics, tracing, alerts	Stable	internal/tracing/tracing_test.go, internal/alerts/alerts_test.go, internal/metrics/
Workspaces, roles, access groups, audit log	Stable	docs/permissions.md, internal/store/permissions_test.go, internal/api/access_controls_test.go
Passkeys, TOTP, enforced 2FA	Stable	internal/api/mfa_test.go, internal/store/mfa_test.go
SAML SSO	Stable	internal/api/saml_test.go
OAuth 2.0 / OpenID Connect provider	Stable	docs/api-v1.md, internal/store/oauth_test.go, internal/api/oauth_test.go
CLI, HTTP API, GraphQL, MCP	Stable	docs/cli.md, docs/api-v1.md, internal/api/graphql_test.go, cmd/aven/mcp_test.go
Infrastructure as code	Stable	internal/deploy/configapply_test.go, internal/iac/
Feature flags	Stable	internal/api/featureflags_test.go, sdk/index.test.ts
Sandboxes	Stable	internal/api/sandboxes_test.go
Dokploy import	Stable	cmd/aven/importdokploy_test.go
Aven on Aven (self-upgrade)	Stable	docs/selfhost.md, internal/deploy/selfhost_test.go, internal/api/selfservice_test.go
AI assistant (bring your own model)	Experimental	Settings and tool calls are documented in docs/api-v1.md. That page lists limits, including logs sent to the model without redaction, and no service creation.
Web dashboard	Experimental	English and Korean UI sources and the screenshots above are in the tree. web/ has no automated component or end-to-end tests.

How this was built

Aven continues an earlier project named Keel. This public repository starts at the first Aven release (755a737, 2026-10-25) and does not include Keel's history.

New installs use Aven names (AVEN_* settings, /var/lib/aven, aven-proxy, aven.* labels). An install that started as Keel keeps working without changes: the old KEEL_* names, paths and containers are still read, and private addresses stay on <service>.<env>.keel.internal. See the self-hosting guide.

AI coding agents were used substantially in development. Changes went through human review and testing.

Highlights

Deploy

• Services from GitHub repositories (Dockerfile or Railpack, no Dockerfile needed), Docker images, Docker Compose files, templates, single-file functions or a local directory (aven up).
• Push-to-deploy with watch paths, wait-for-CI, commit statuses and pull request preview environments.
• Environments with variable references (${{ db.DATABASE_URL }}), shared and sealed variables, a raw editor and config as code (railway.json, aven.json).
• Pre-deploy commands, health checks, zero-downtime overlap, rollbacks, and image auto-updates. Cron schedules and app sleeping are implemented and marked experimental in the table above.

Data

• One-click PostgreSQL, MySQL, Redis, MongoDB and S3-compatible buckets, with volumes, a data browser and logical backups to S3.
• Point-in-time recovery, PgBouncer pooling, major version upgrades and high-availability clusters for PostgreSQL.

Networking

• Generated and custom domains with automatic TLS through a managed Caddy proxy, path rules, redirects, basic auth and wildcard domains.
• IPv6 first: optional per-domain public IPv6 addresses, outbound IPv6 control and TCP proxies for databases and other raw TCP services.
• Private DNS names between services, also across servers over an encrypted mesh (Tailscale or WireGuard addresses).
• Edge caching, WAF rules and Cloudflare Tunnel ingress.

Multiple servers

• Add servers with a one-line agent install. Place services on a node, spread replicas across nodes, autoscale on CPU, memory or requests per second, and move services with their volumes.

Observability

• Build, deploy and runtime logs, HTTP and network flow logs, metrics, OpenTelemetry tracing, dashboards, metric alerts and notifications (webhooks, Slack, Discord, email).

Teams and security

• Workspaces, projects and environments with roles, access groups, restricted environments and guardrails for allowed sources.
• Passkeys, TOTP, enforced 2FA, SAML SSO, an OAuth 2.0 / OpenID Connect provider ("Login with Aven"), API tokens, audit logs, usage and resource limits.

Automation

• aven CLI, REST and GraphQL APIs, an MCP server for AI tools, an optional AI assistant (bring your own model), infrastructure as code for whole projects, sandboxes and a feature flags SDK.
• aven import dokploy moves an existing Dokploy installation.

Aven on Aven

• The server manages itself: aven-server appears on the server owner's canvas, checks its repository for updates and upgrades itself from a deployment, with an automatic rollback if the new version is not healthy. Server settings are edited from the same panel. See Aven on Aven.

How it works

• aven-server is a single Go binary with the dashboard embedded. It keeps its state in SQLite (/var/lib/aven), builds images with Docker and Railpack, and runs containers through the Docker API.
• aven-proxy is a Caddy container that Aven configures (keel-proxy on installs that started as Keel). It terminates TLS, routes domains to replicas on its own node and serves the edge features.
• aven-agent runs on additional servers, connects back to the server with a certificate and runs the same Docker operations there. Services on different nodes reach each other through an mTLS mesh on the private addresses you provide.

Build from source

Requirements: Go 1.26+, Node.js 20.9+ with npm, and Docker for running the server.

make all        # web UI, aven-server, agents and CLI binaries in ./bin

Run a local instance for evaluation:

mkdir -p ./data
AVEN_ADMIN_PASSWORD='replace-with-a-long-password' \
AVEN_HTTP_PORT=18080 AVEN_HTTPS_PORT=18443 AVEN_PROXY_BIND=127.0.0.1 \
./bin/aven-server -listen 127.0.0.1:7070 -data ./data

Sign in at http://127.0.0.1:7070 as admin@local. The server starts its proxy container through Docker; change the ports and bind address before running it on a network. For production, use deploy/aven.env.example and deploy/aven-server.service, or docker build -t aven-server . for the container image.

Relationship to Railway

Aven is an independent implementation. This repository contains none of Railway's source code: the server, agents, CLI, proxy configuration and dashboard were written for Aven.

What Aven shares with Railway is on the surface:

• Look and workflow. The canvas, service panel and settings follow Railway's dashboard, because many people already know that workflow.
• Compatibility. Aven accepts railway.json / railway.toml config files and offers a GraphQL endpoint shaped like Railway's public API, so existing configuration and scripts keep working when you move.
• Railpack. Builds without a Dockerfile use Railpack, an open-source builder published by Railway (MIT, license), run as a separate program.

Railway is a trademark of its owner and is used here only to describe compatibility. The comparison records what the Railway docs say, and notes that Railway has not published the platform's source.

Documentation

• Self-hosting guide: install, DNS, what the installer changes, backups and restore, upgrades, uninstall, troubleshooting
• Aven on Aven: let Aven manage and upgrade its own server
• CLI reference
• HTTP API and GraphQL API
• Permissions and workspaces
• Feature flags SDK
• Website: the source of aven.turin.my and the installer host

FAQ

Does it need Kubernetes? No. Aven runs containers with plain Docker on each server and keeps its own state in SQLite. There is no cluster to install or operate.

Is it production-ready? It runs real workloads for its authors, but it is young: expect rough edges and read the release notes before upgrading. Back up the data directory (/var/lib/aven, or /var/lib/keel on installs that started as Keel), which holds the database and the key that encrypts secrets. See Feature stability for what the tests in this tree cover.

Do I need GitHub? No. You can deploy Docker images, Compose files, templates and local directories (aven up). GitHub is needed for push-to-deploy and preview environments.

How do I upgrade? Run the install script again, or let Aven upgrade itself from its own canvas (Aven on Aven). The script keeps /etc/aven/aven.env, copies aven.db (and keel.db if that file is still the database) to /var/lib/aven/backups/ after stopping the server, and keeps the old binary as /usr/local/bin/aven-server.prev. Migrations run on start. Copy master.key somewhere else yourself: the script does not. Putting the previous binary back without the database copy can fail if a migration already ran. The steps are in the self-hosting guide.

Can I move from Railway or Dokploy? Aven reads railway.json / railway.toml and answers Railway-shaped GraphQL queries, and aven import dokploy recreates a Dokploy installation's services, variables, domains and volumes. Data is not copied: move database contents with your usual dump and restore tools.

Why AGPL? So that improvements to a hosted Aven stay open. Running Aven for your own apps, at any scale, has no extra obligations; offering a modified Aven to others over a network means sharing those modifications.

Contributing

Bug reports, documentation fixes and pull requests are welcome. Read CONTRIBUTING.md and the code of conduct first. Report security vulnerabilities privately as described in SECURITY.md.

License

Aven is licensed under the GNU Affero General Public License v3.0 only (AGPL-3.0-only). If you run a modified version for others over a network, you must offer them its source. Bundled third-party software and fonts are listed in THIRD_PARTY_NOTICES.md.

Footnotes

1. This repository: README.md, docs/self-hosting.md, install-server.sh. A search of the Go sources and docs found no billing, price, or license-key gate. ↩ ↩² ↩³

2. railway.com/pricing and railway.com/enterprise, fetched 2026-10-27. The pricing page lists Free through Enterprise, per-second usage rates, and SSO under Enterprise and committed spend. ↩ ↩² ↩³

3. docs.railway.com/maturity/enterprise, fetched 2026-10-27 (“Your workloads run on dedicated Railway hosts for complete resource isolation”). ↩

4. coolify.io/pricing, fetched 2026-10-27. Self-hosted is “Free forever” with “Full access to all features” and unlimited connected servers. Cloud is “$5 /month base price (connect 2 servers)” plus “$3 /month per additional server”. ↩ ↩² ↩³ ↩⁴

5. docs.dokploy.com/docs/core/differences, fetched 2026-10-27. Self-Hosted (OSS) is free and includes multi-server. SSO is marked off for OSS and for non-Enterprise Cloud, and on for Enterprise. ↩ ↩² ↩³ ↩⁴ ↩⁵

6. LICENSE and THIRD_PARTY_NOTICES.md (AGPL-3.0-only). ↩

7. docs.railway.com/cli (“The Railway CLI is open source”), fetched 2026-10-27. ↩ ↩²

8. github.com/coollabsio/coolify LICENSE (Apache License 2.0), fetched 2026-10-27. ↩

9. github.com/Dokploy/dokploy LICENSE.MD on the default branch (canary), fetched 2026-10-27. ↩

10. SAML routes in internal/api/api.go, docs/permissions.md, docs/cli.md, tests in internal/api/saml_test.go. ↩

11. coolify.io/docs/core/security/authentication/sso/overview, fetched 2026-10-27. SSO is for self-hosted Coolify (v4.3.0+). The page says Coolify Cloud manages its own authentication. ↩

12. internal/api/auth.go, internal/api/mfa_test.go, internal/store/mfa_test.go. ↩

13. docs.railway.com/access/multi-factor-authentication, fetched 2026-10-27. The page documents passkeys and does not name a plan. ↩

14. Searched Coolify’s docs on 2026-10-27. Dashboard docs describe two-factor authentication (disable 2FA manually) and SSO. Pocket ID is a separate app you can deploy. No page was found that adds passkeys to Coolify’s own sign-in. ↩

15. docs.dokploy.com/docs/core/account-security, fetched 2026-10-27. The Cloud plan table on the differences page lists 2FA as unavailable on Hobby and does not mention passkeys. ↩

16. docs/self-hosting.md (“Adding servers”), internal/store/nodes_test.go, internal/deploy/mesh_test.go. ↩

17. Replica limits on railway.com/pricing. Regions are listed on docs.railway.com/deployments (“Deploy to specific geographic regions”). Neither page describes attaching your own server. ↩

18. internal/api/github_preview_test.go, internal/store/preview_test.go. ↩

19. docs.railway.com/guides/preview-deployments-with-pr-environments, fetched 2026-10-27. ↩

20. coolify.io/docs/applications/deployments/preview-deployments, fetched 2026-10-27. ↩

21. docs.dokploy.com/docs/core/applications/preview-deployments, fetched 2026-10-27. ↩

22. internal/catalog/catalog.go (Postgres, MySQL, Redis, MongoDB) and the bucket service in docs/cli.md. ↩

23. Postgres, MySQL, Redis, and MongoDB, fetched 2026-10-27. ↩

24. coolify.io/docs/databases, fetched 2026-10-27. The page lists the engines above and marks SQLite experimental. ↩

25. docs.dokploy.com/docs/core/features (MySQL, PostgreSQL, MongoDB, Redis, MariaDB; manual and scheduled backups), fetched 2026-10-27. A search of the published docs corpus found no Dokploy PITR page. A template such as Databasus that mentions PITR is a separate app, not Dokploy’s database backups. ↩ ↩²

26. aven pitr in docs/cli.md (Postgres WAL, MySQL binlog), internal/api/dbpitr_test.go, internal/agent/dbbackup_test.go, and the server database backup in docs/self-hosting.md. ↩

27. docs.railway.com/volumes/point-in-time-recovery (Postgres and MySQL) and the backup sections of the Postgres and MySQL pages above, fetched 2026-10-27. ↩

28. coolify.io/self-host-postgres-with-backups, fetched 2026-10-27. Scheduled backups are pg_dump / pg_dumpall. The page’s PITR question says that is a separate WAL-archiving setup. ↩

29. GitHub webhook setup in docs/self-hosting.md. No git receive-pack server showed up in the Go tree. ↩

30. docs.railway.com/deployments/github-autodeploys, fetched 2026-10-27. ↩

31. Automatic deployments, fetched 2026-10-27. Deploy on push is documented for a GitHub App, GitLab, and a repository webhook. ↩

32. docs.dokploy.com/docs/core/auto-deploy, fetched 2026-10-27. ↩

33. docs/self-hosting.md, internal/config/config.go (unknown keys including nixpacksPlan are ignored), internal/dokploy/translate.go (a nixpacks build is replaced by Railpack). ↩

34. docs.railway.com/builds, fetched 2026-10-27. The page documents Railpack and Dockerfiles. It does not mention Nixpacks or buildpacks. ↩

35. Heroku Buildpacks & Paketo deprecation notice, posted by Railway staff on 2025-01-13, fetched 2026-10-27. Railway retired both builders on 2025-02-21. ↩

36. Deploy with Nixpacks and the coolify CLI --build-pack values nixpacks, static, dockerfile, dockercompose on create deploy key, fetched 2026-10-27. Those pages do not list a buildpack builder. ↩

37. docs.dokploy.com/docs/core/applications/build-type, fetched 2026-10-27. ↩

38. Project canvas on the Postgres page and service settings on the autodeploy page, same fetches as above. ↩

39. docs/cli.md, cmd/aven. ↩

40. coolify app create deploy-key, fetched 2026-10-27. ↩

41. docs.dokploy.com/docs/cli (npm install -g @dokploy/cli), fetched 2026-10-27. ↩