Roadmap

Roadmap

Four stages. Each stage has a purpose, a scope, done criteria and the main risks. Checkboxes track progress.

Alpha — the core works

Purpose. Prove that panel → agent → Quadlet → rootless Podman works on a real server and can already replace manual config copying. The UI is simple but honest: containers, logs and network are visible. No AI, no proxy, no backups.

Scope

• Create / delete a workspace with the full system-user lifecycle (see Architecture, Isolation and users).
• Service from a ready image and service from a Dockerfile in a git repo (clone by key, podman build, tag by SHA).
• Quadlet generation (.container, .network, .volume) applied through the agent; the resulting unit is viewable in the UI.
• Operations: deploy, restart, stop, delete; systemd status and health view.
• journald logs in the UI filtered by service; journald limits configured.
• Workspace network with DNS by name; internal ports closed by default; explicit publish on 127.0.0.1 or a chosen IP.
• Secrets: entered in the UI, stored encrypted in the DB, delivered via podman secret; env vars with {{service.field}} references.
• Deterministic validator: env syntax, unresolved references, port conflicts, unknown hostnames, Quadlet generator dry-run.
• Minimal UI: workspaces → projects → services, service card, logs, action buttons; podman stats in the service card.

Done criteria

• Any current project comes up through the panel from scratch without SSH.
• Server reboot: every service comes back on its own (linger + systemd).
• Deleting a workspace leaves no users, files or subuid entries on the host.
• No port is reachable from outside without the explicit published flag.

Main risks

• Rootless pitfalls: subuid for system users, XDG_RUNTIME_DIR, socket permissions. Time is budgeted for debugging.
• Agent as root: minimise the surface — only the listed operations, no arbitrary shell.
• Temptation to build a pretty UI right away. Alpha UI is functional, nothing more.

MVP — fit for production

Purpose. The critical layer is solid: domains, TLS, zero-downtime deploy, notifications, backups. The panel fully replaces Coolify for current projects and becomes the main operations tool.

Scope

• Edge proxy: Caddy driven by the panel via admin API; domain → service in two clicks; wildcard via DNS-01 for own domains; domain bound to a public IP.
• Blue-green deploy for stateless services (see Architecture, Zero-downtime deploy); restart mode with an explicit warning for stateful; rollback to the previous digest.
• Local registry; images stored and promoted by digest.
• Auto-deploy via webhook from GitHub/GitLab/Gitea; manual deploy button; deployment history.
• Service catalogue: Postgres, ClickHouse, Dragonfly, RabbitMQ, MinIO templates with parameters, generated passwords and secrets.
• Health checks in Quadlet (HealthCmd, HealthOnFailure, Notify=healthy).
• Telegram notifications: crashes, failed deploys, backup results, restarts.
• Backups to S3: schedule, retention, restic/rclone; pg_dump and clickhouse-backup; a restore button.
• Database users: admin / app / readonly roles for Postgres, ClickHouse, Dragonfly, RabbitMQ; password rotation with dependent restarts.
• Cross-workspace access links (see Architecture, Network and ports).
• Resource limits: cpuset for prod, slices for the rest; memory limits per service.
• Telemetry: VictoriaMetrics with exporters, CPU/memory/network/disk charts per workspace and service, deploy markers on charts (see Telemetry).
• Panel authentication, panel roles (admin / operator / viewer), audit log.

Done criteria

• All production projects migrated from Coolify; Coolify switched off.
• Redeploying a stateless service under load produces no client-side errors given correct graceful shutdown.
• Postgres restore from an S3 backup verified on a test workspace.
• No application uses an admin database connection string.
• A service crash reaches Telegram within one minute.

Main risks

• Panel state vs. real systemd drifting apart (someone edited a unit by hand). Needs reconcile and a drift warning.
• DNS alias switching vs. connection caches in clients. Must be tested on real services with connection pools.
• Caddy admin API has no config persistence: the panel must be able to rebuild the whole config after a Caddy restart.

Beta — the full feature set

Purpose. On top of a stable core: MCP, the built-in agent, remote development and integrations. Features are integrated, exercised and adjusted; some may be cut based on real use.

Scope

MCP server and external API

• MCP server over the panel API: read tools (workspaces, services, units, networks, ports, logs, deployments) and planning tools (plan_deploy, plan_env_change, plan_publish_port).
• Tokens with scopes read / plan / apply bound to workspaces. apply for prod is issued to humans only.
• Claude Code and other MCP clients connect directly to the server.

Built-in agent

• Chat in the panel; any provider key; model selection.
• Tools only through MCP; secret values are unreachable; repositories are cloned into a sandbox.
• Scenario "study the repository and draw a deployment map": parse compose / Dockerfile / .env.example / monorepo graph → plan of services, links and ports → validator ↔ agent loop → plan for approval.
• Protection against prompt injection from repositories and logs: plan-only mode, explicit apply confirmation.

Remote development

• Dev workspace: same user mechanism, env=dev, own cpu slice, direct SSH into the user.
• Dev image (headless Ubuntu: Neovim, tmux/zellij, Claude Code, language toolchains, code-server, Entire) via toolbx/distrobox with a shared home (see Remote Development).
• Agent tool "link to file/line" opening code-server in the browser or VS Code over SSH.
• Agent session history via Entire; checkpoint linked to a deployment (see Agent Memory).
• The agent may apply changes itself in dev; in prod — plan only.
• Cloudflare tunnels as a panel tool: cloudflared per workspace, routes via API; the Cloudflare token is never given to the agent.
• dev → prod promotion: one button, same image digest, prod bindings substituted, plan and confirmation.

Observability and Telegram

• Log triage: code-level filter (level, patterns, dedup) → a cheap model answers "is there a critical error" → alert.
• Telegram bot with voice input (STT), read-only tools via MCP, log sent as a file; ID allowlist; mutating actions only via a confirmation button.
• VictoriaLogs with a collector: search by workspace/service/env/version labels; unified workspace feed with Plane tasks (see Telemetry).

Task tracker

• Plane as a platform service created together with Maurice; creating a workspace auto-creates and links a Plane project. Tracker abstraction with drivers (Plane default, Jira and Linear optional).
• Agent as task author: creates, links to epics, moves statuses, creates sprints; the human confirms and edits.
• Workspace card widget: in progress, opened/closed this week, backlog growth.

Done criteria

• A new project from a repository is deployed by the agent into a dev workspace without manual config edits; the prod plan passes without fixes.
• A developer works for a week only in a dev workspace on the server (SSH + Claude Code); the laptop reboots with no consequences.
• One Telegram message yields a server status answer and the log file of the requested service.
• The Release feature list is frozen after Beta; the excess is cut.

Main risks

• An agent with apply rights in dev can still damage dev data; backups are needed in dev too.
• LLM cost on logs of chatty services — mandatory prefilter and limits.
• Scope creep: integrations and dashboards eat time without adding value to the core.

Release — stabilisation

Purpose. Everything that survived Beta works predictably. Further work is bugs, Podman and template updates, new features on request.

Scope

• Documentation: installation, security model, Quadlet generation format, API/MCP, disaster recovery.
• Panel and agent upgrade procedure without downtime of managed services (the panel is not a runtime dependency).
• Podman version compatibility matrix; tests for Podman upgrades (auto-update, Quadlet syntax).
• Regular catalogue template updates (Postgres, ClickHouse versions, ...) and dev-environment image updates.
• Core regression tests: workspace creation, deploy, blue-green, backup/restore, deletion.
• Release process: changelog, versioning, panel rollback plan.

Done criteria

• One month of operation without panel-caused incidents.
• Any host incident is recoverable from the documentation without knowing panel internals.
• A minor Podman upgrade passes the checklist without manual unit edits.