Competitive roadmap: 2026-11

Competitive roadmap: 2026-11

Drawn up on 2026-11-09 against main at e85dbf45 (0.18.25). The tree had 12 modified files from another session; they are not part of this plan.

Sources:

• three read-only reviews run on the same day: code health and structural debt, competitor state, and product and adoption;
• the competitive gap report in .temp_files/competitive-gap-20261109/REPORT.md, which pins 12 competitor sources;
• spot checks of the claims these rely on, against the source.

The working notes are git-ignored:

• .temp_files/compet_20261109/ holds the competitor issue rankings, advisory counts and raw release notes;
• .temp_files/competitive-gap-20261109/ holds the pinned competitor sources.

This plan follows on from ROADMAP.md and GAP_ROADMAP.md, whose items are all done except R2. It does not re-plan R2 (node ordered lifecycle, autoscaling and sleep acceptance, 0.19.0), because another session owns it; see COMPETITIVE_DELIVERY.md.

Every item follows the rule every release follows: installed servers upgrade in place; migrations are additive only; new behaviour is opt-in or keeps the old default; and smoke:upgrade exercises the item after an upgrade.

1. What changed: features are no longer the bottleneck

Six weeks of roadmap work closed almost every feature gap found in October. What decides whether NineDeploy beats its rivals now lies elsewhere.

Adoption is near zero.

The repository also has:

• no importer from another platform;
• no screenshots in the README;
• no CONTRIBUTING, SECURITY or CODE_OF_CONDUCT file.

The rivals are closing in on our differentiators.

• Coolify 4.5.1 to 4.7.0 (2026-10-20 to 11-09) shipped workspace-enforced 2FA, compose build skip, per-resource RBAC for members and tokens, update channels (stable, preview, nightly), and image scanning with API and MCP tools.
• Dokploy 0.31.0 shipped moving services between servers and audit-log export.
• GAP_ROADMAP's G5 heading, "None of the Docker-based rivals has these", is no longer true as a group claim.

Structural debt now causes silent data loss in ordinary operations.

• About 25 per-entity settings key prefixes hold feature state.
• They are untyped.
• They are orphaned when their entity is deleted.
• They are dropped on export, import and clone (§3).

The capability story is inconsistent.

• The server has 45 distinct *_unsupported, *_unavailable or *_refused codes.
• Several docs contradict each other or the code (§2).

Security is a selling point we don't use.

NineDeploy already has:

• argv-only command execution;
• a setup token on first boot;
• signed releases;
• real restore verification.

These are told nowhere a buyer would look.

Hence the order of this plan:

1. Truth: one contract for what works where.
2. Structural debt.
3. Adoption.
4. Parity across runtimes.
5. Reliability and data.
6. New modules, last.

Priority: P0 means fix now, because it is wrong or loses data today. P1 is the next releases. P2 comes after P1. P3 is a strategic choice for the owner.

Size: S means at most a patch. M is one or two patches. L is a multi-patch package. XL is architectural.

Status: ⬜ not started · 🟨 in progress · ✅ done (with the release that shipped it)

2. T0: One capability contract

3. T1: Structural debt

4. T2: Adoption, the biggest gap

5. T3: Parity across runtimes

C1's matrix decides each cell: close it, or keep the refusal as a stated design limit. Never remove a guard just to fill a cell.

• The node serves them from ninedeploy-pages (agent image, read-only, nobody, no port), with the panel-rendered pages in .agent-proxy/pages/<id>.json mounted read-only.
• syncNodeProxy writes the pages, prunes, ensures the server, and only then renders pages: true. A save counts only when its own sync put the service's pages on the node. Otherwise the previous value is restored and re-rendered, and the save answers 502 node_pages_unapplied (nothing re-syncs a node on a timer, so a kept setting would never apply).
• Same Host rule as the panel. Maintenance wins over node sleep, and a bypass address still wakes the service.
• Moves to a page-serving node are allowed; fan-out stays refused. C1 shows limited with the agent requirement.
• Checked live on a node DinD (503 + Retry-After, bypass, custom 502, foreign Host 404, re-ensure, switch refusal).

Restart limit built (no new agent capability):

• The sweep samples a node docker service through docker.identity (ownership by service and deployment, never the name alone) and docker.readiness in running mode, which reports RestartCount even while a container restarts. docker.metrics refuses such a container.
• A trip requests the Stop button's own ordered node Stop (acceptNodeLifecycleIntent). The reconciler audits service.stop when it settles, and service.restart_limit carries stopRequested.
• It never cancels a deploy (including awaiting_ci and awaiting_approval), a pending lifecycle command, or a sleep or wake. A failed sample keeps the history. Panel-host services are sampled first.
• C1 shows limited on a node and unavailable for a node fan-out. Turning it on, or moving with it on, checks the target agent live with assertNodeLifecycleAvailable.

Forward auth waits on an owner decision: the node must reach the panel's verify endpoint, which docs/NODE_SLEEP_WAKE.md rules out. Either a node-side verifier of signed sessions (keeps working while the panel is down) or a route to the panel through the agent.

Volume files were already at parity (a22f936d): volume.fileTool (capability volume.files, switch NINEDEPLOY_AGENT_VOLUME_FILES) behind /v1/servers/:serverId/volumes/:name/files, and the service's Volumes tab passes the node. Instance operators only, the same rule as on the panel host, where requireAdmin also means operator.

Deploy hooks built (capability docker.hooks, agent v0.18.27, switch NINEDEPLOY_AGENT_DEPLOY_HOOKS):

• Pre-deploy and post-deploy run in a one-off container from the release's own image on the node, with the service's env, network, limits and node database bridges (the release-phase model), not in a shell on the host.
• Pre-deploy runs in the builder (beforeRun) once the image is on the node and before any replica or capacity exists. Post-deploy runs from the image the new container runs.
• The agent pins the image id, execs argv[0] as the entrypoint, and adds no port, mount or socket, plus no-new-privileges. It labels the container managed=hook, which inventory and the creation fence never match, and removes it after a timeout or cancel.
• Pre-stop stays refused on nodes, because it acts on the running instance. Hooks are not replayed on fan-out targets. | | P3 | Preview database copies for more engines and for nodes (REPORT G05). | PostgreSQL and the Redis family only, on the panel host only (lib/previewDatabases.ts:71-73). | MySQL, MariaDB and Mongo dumps carry users, so restore the data, then reset to the preview's own credentials and verify that the production credentials fail. Node databases go through the agent. Masking becomes a separate opt-in. | P2 | L | ⬜ | | P4 | Compose release fidelity (REPORT G10). | Recorded restore covers self-contained inline stacks on the original panel host. Includes, env_file, extends, profiles and bind mounts are refused (lib/composeRelease.ts). | Show before deploy whether a stack can be recorded. Capture the eligible external inputs, encrypted. Pull images by digest on a clean target. | P2 | L | ⬜ | | P5 | Swarm with state (REPORT G03). | Volumes, managed databases, host ports, fan-out, the restart limit and tunnels are refused. Canary, autoscaling and scale to zero are unavailable. | Owner decision: keep Swarm a stateless deployer (and say so in C1), or define a placement-local or shared-storage contract first. | — | — | ✅ decided 2026-11-09: stateless deployer, stated in C1 |

6. T4: Reliability and data

7. T5: New modules, after T0–T2

Not planned:

• a Kubernetes runtime (a different market: Kubero, Canine, Tsuru);
• Caddy;
• our own analytics, replay or RUM suite (link to Umami, PostHog or GlitchTip instead, REPORT G07);
• integrated mail.

8. Order of work

Each phase ships as patch releases. R2 continues independently in the other session.

9. Owner decisions (2026-11-09)

1. Release channels (A6): approved; details left to us.
   • Two channels. current is today's patch stream and stays the default, so upgrades behave as before. stable is opt-in.
   • Stable moves to the newest release that is at least 7 days old and has no later release that fixes a regression it introduced.
   • Sooner when a release fixes a security issue: stable takes that fix, and the security bullet in the release notes says so.
   • The self-updater and install.sh --channel stable follow the chosen channel.
2. Public launch (A7): approved.
   • It happens once phase 2's exit evidence exists: screenshots, a measured first-run flow and a generated support matrix.
   • The community files ship in phase 1 regardless.
3. Template slugs (A8): approved. Rename coolify-* with redirects and credit upstream.
4. Signing (A9): over time.
   • No certificates yet.
   • The desktop app stays out of the README headline until signed builds exist.
5. Swarm's scope (P5): left to us; decided as a stateless deployer.
   • Stateful workloads belong on Docker nodes, where volumes, managed databases, backups, PITR and tunnels already work.
   • A shared-storage contract would be an XL project with new data-loss modes. The current refusals are safe.
   • C1 states the limit, and the UI offers "run on a node" when a stateful option is refused on Swarm.
   • Revisit only if users ask for it.
6. Target market (X6, X7): both agencies and AI-agent workflows.
   • X6 (agent sandboxes) and X7 (workspace quotas and a billing export) move from P3 to P2.
   • Both still come after phases 1–3.
7. Sustainability: sponsorship only.
   • Add .github/FUNDING.yml for GitHub Sponsors in A7.
   • No paid tier, no paid support and no hosted control plane.
8. Cloud accounts (O6): later. Arranged when the item comes up.

10. Claims to retire or qualify

• "Only we have MCP": Coolify and Easypanel have MCP.
• "No Docker rival scans images": Coolify 4.7.0 does.
• "None of the Docker-based rivals has these" (the GAP_ROADMAP G5 heading).
• "GitOps manages the whole instance": the schema is narrower (X3).
• "Swarm support" stated as multi-node parity (P1, P5).
• "Error ingest replaces Sentry": there are no source maps or traces yet (X1).
• Any "fastest", "most secure" or "largest catalogue" claim without a measurement.