Roadmap.From set up to looked after.

No dates. The repo is developed by an autonomous agent with human review, so pace is set by proof, not by the calendar. Each item has one line on what you gain and one on how we will know it is done. Proposals and pull requests are welcome on GitHub.

Who this is for

One person running a few apps for themselves and for clients, who wants to get a server and a deploy pipeline without learning Coolify, Docker or Hetzner first, put any reasonable app on it, see at a glance whether their apps are up, backed up and up to date, survive the bad day, and hand a project over without handing over their own credentials.

Rules for every item

  1. Nothing ships without a run on a fresh, throwaway server. "Should work" is not a result.
  2. Runbooks plus a thin, tested shell layer. Where Coolify has the feature, we drive it; we never rebuild it.
  3. Secrets stay on your machine or your server. Never in the chat, never in the repo.
  4. One way to do each thing. A second option is added only for a user with a concrete case.

NowIn work.

  1. R01 End-to-end harness on a throwaway server

    A script creates a small Hetzner server, runs every phase unattended, submits the starter form and deletes the server. Cents per run, on every change and nightly against the newest Coolify.

    Done when: A green run from server creation to ALL DONE, server gone, Coolify version logged.

  2. R02 The recorded run, then public

    The whole flow on a fresh server, on video. Every unproven note in the repo settled. A guide for the agents that contribute.

    Done when: No [verify] marks left, the repo is public, this page links the recording.

  3. R03 status.sh: one screen

    Server reachable, disk and memory, pending reboot, Coolify version, every app with its last deploy, days to certificate expiry, last backup and whether it worked.

    Done when: Every line is backed by a real check, on the test server and on a production one.

  4. R04 Off-site backups and a restore drill

    Database backups to any S3-compatible storage, set up during handover. A runbook that restores one database from a chosen backup.

    Done when: The harness backs up, destroys the database, restores it, and the data is back.

  5. R05 DOCTOR.md: my app is down

    From a symptom (site down, deploy failed, 502, certificate error, server unreachable) to a fix, or to an honest "this needs a human because".

    Done when: Five symptoms broken on purpose in the harness; the runbook reaches the right fix for each.

  6. R06 Alerts that reach a phone

    Coolify's own notifications wired to email, Telegram or Discord, plus an external uptime check per app with a public status page.

    Done when: The harness stops an app and an alert arrives within five minutes.

NextRight after the above.

  1. R07 Safe deploys

    Database dump before every deploy, the rollback point printed, a runbook that reverts to the previous image and restores the dump if needed.

    Done when: A broken commit is deployed, rolled back, and the app is healthy with its data.

  2. R08 More stacks, by fixture

    Static sites, Docker Compose stacks, Python, Go. Each stack has a sample app the harness deploys; without one it stays "not supported yet".

    Done when: Three stacks beyond Node are green.

  3. R09 Projects and clients

    One Coolify project per client or product, names and domains derived from it, a file listing what runs where, status grouped by project.

    Done when: Two projects run side by side in the harness.

  4. R10 SERVICES.md: self-host the tools

    n8n, Plausible or Umami, Uptime Kuma, Forgejo, Minio and the other one-click services, each with a domain, HTTPS, backups and a line in status.

    Done when: Three services deploy in the harness with backups verified.

  5. R11 Staging without a second server

    A staging branch deploys to staging.<your-domain> with its own database. Promotion is a merge to main.

    Done when: Push to staging changes staging; the merge changes production.

  6. R12 Handover pack

    Everything a client or colleague needs to take over a project or a server: a team invite with the right role, the server summary, DNS and repo ownership, and the checklist that removes your own access.

    Done when: A second user, with only the pack, deploys a change.

  7. R13 Move in from Vercel, Railway or Render

    The agent reads the existing project, reproduces it on your server, and walks the domain cut-over with a window to switch back.

    Done when: A sample app moves with its environment and the old deployment is still there.

LaterPlanned, in no order.

  1. R14 Upgrades

    Coolify, Ubuntu and Postgres major versions, each with a dump first and a check after. Status says when each is due.

    Done when: Coolify upgrades to the newest release and Postgres 17 to 18 with data intact.

  2. R15 Rebuild from nothing

    New server, every database restored from off-site backups, DNS repointed, apps redeployed from git. Run on purpose every quarter.

    Done when: The rebuilt server passes every check with all data present.

  3. R16 Monthly checkup

    Open ports, SSH config, Docker exposure, Coolify advisories, certificate renewals, backup success rate, disk growth and this month's cost. Ends with actions, each with a runbook.

    Done when: No false positives on a clean setup.

  4. R17 Second server and moving an app

    Add a bigger box or a client's own server to the same Coolify and move an app with its database.

    Done when: The starter moves between two servers and the form data survives.

  5. R18 DNS through the API

    Cloudflare first, then the providers people ask for. The agent creates the records; the DNS click disappears.

    Done when: A harness run on a Cloudflare-managed domain needs no DNS click.

  6. R19 Agent packaging

    A Claude Code plugin with /vps-setup, /vps-status and /vps-doctor, and the same guide working in Codex and Cursor.

    Done when: The harness passes through the plugin and through plain markdown.

  7. R20 Providers beyond Hetzner

    Any Ubuntu box with your key becomes a first-class path, tested on one more provider.

    Done when: Green on Hetzner and on one other provider.

IdeasNo commitment.

  1. R21 Preview deployment per pull request

    If Coolify's GitHub App source becomes drivable without the UI.

  2. R22 A status page per client

    From the uptime monitor, on the client's domain.

  3. R23 Secrets vault on your machine

    age or sops, with a rotation runbook.

  4. R24 Starter variants

    The same plumbing with auth and transactional mail; a worker example as a second app from the same repo.

  5. R25 Windows through WSL

    Tested in the harness driver.

  6. R26 Cost forecast before anything is created

    What this setup will cost per month, from the provider's current price list.

Shipped

11 October 2026
Existing Hetzner server variant: pick a server you already have, attach the cloud firewall, continue as usual.
11 October 2026
Landing in English and Polish, optional double opt-in mail updates, consent, rate limit.
9 October 2026
Phase 05 proven on Coolify 4.3.23: private repo, Postgres 17, deploy key, webhook, push-to-deploy. This page runs on the setup it describes.

The same list lives in ROADMAP.md in the repo. ROADMAP.md