Temps Wants to Fix Coolify and Dokploy: Why a 99.9% Reliable One-Box PaaS Still Isn't a Fleet

On January 12, 2026, a new name appeared on AlternativeTo: Temps, an open-source self-hosted PaaS that lets you deploy on cheap Hetzner, DigitalOcean, and OVHcloud VPSs instead of paying Vercel, Railway, or Render. Its headline promise was blunt: 99.9% deployment reliability, built specifically to fix the bugs and random failures that plague Coolify and Dokploy.

It was not the first project to make that pitch. Dokploy (now ~35,000 GitHub stars, still pre-1.0 at v0.29.4) rose by promising a cleaner, lighter Coolify. Coolify itself (now ~57,000 stars, v4.0 stable April 27, 2026, with an MCP server for AI-agent deploys) rose by promising a self-hosted Heroku. Mooring and Deckrun are already filing in behind them. Temps is the latest fork in the same idea: if single-box deploys were just more reliable, you'd have the PaaS you actually wanted.

You wouldn't. You'd have a more reliable single box that still falls over at exactly the same place the last three did — the day you need server number two.

That is the core category error this post is about, and the next table states it before any narrative smoothing. If you run one app on one VPS and never outgrow it, a polished one-box tool is the right choice and this post will say so. If you need a second machine for any reason — scale, tenancy, blast-radius, compliance — no amount of single-box reliability collapses the gap below. The operational model is different, not just the bug count.

The CX22 price anchor — why the hardware number doesn't move the decision. A Hetzner CX22 — 2 vCPU, 4 GB RAM, 40 GB NVMe, 20 TB traffic — is €3.79/month. Two are €7.58/month whether they run Temps, Coolify, Dokploy, or a CAPH fleet. The hardware delta is zero; the operational delta is who rebuilds box two when it dies. That is the whole table in one number: deploy reliability (99.9% vs not) changes the left column, not the price of the right.

The rest of this post makes that table concrete: what Temps actually fixes, what "fixes the bugs" as a differentiator signals about fragmentation, what specifically breaks when you outgrow one box — priced against that same CX22 — and why owning machine lifecycle is a different bet from polishing deploy reliability, no matter how good the polish gets.

Temps in Context: What "Fixes the Bugs" Actually Means​

Temps is worth taking seriously as a one-box tool. The AlternativeTo listing added January 12, 2026 describes a self-hosted PaaS for affordable VPS providers with two explicit claims: flat pricing anchored to the provider's own bandwidth (Hetzner's 20 TB included per server versus per-GB metering on hosted platforms) and 99.9% deployment reliability achieved by fixing the category of random, hard-to-reproduce deploy failures users report against Coolify and Dokploy. Both claims are grounded.

Coolify and Dokploy do have a reliability tail that users hit in production. The concrete complaints are not mysterious:

• Intermittent deploy failures that succeed on retry with no code change — build-cache invalidation, stuck containers, and dashboard queue stalls reported across Coolify's issue tracker and Dokploy's GitHub Discussions through 2025-2026.
• Compose vs Dockerfile asymmetry — Coolify cannot do zero-downtime deploys via Docker Compose today, only via Dockerfile, Nixpacks, or single-image deploys; Dokploy's Compose support is better but still coupled to its Swarm-mode assumption, which users have to opt into understanding.
• Proxy and resource conflicts — both tools front apps with their own Traefik (Dokploy) or Traefik/NGINX instance (Coolify); coexisting with an existing proxy, custom Traefik labels, or a pre-existing Docker network creates a class of "works on my machine, fails on the PaaS box" bugs that Temps explicitly names as fixed.
• Version-churn surface — Dokploy's latest stable as of May 11, 2026 is still v0.29.4 (pre-1.0, API can shift); Coolify burned a long beta tail to reach v4.0.0 stable on April 27, 2026, including a January 2026 disclosure of 11 critical CVEs patched in the v4.0 line. A fleet that self-updates its control plane on the same box as its apps inherits that churn as operational risk.

Temps' promise is to sweep that tail clean — same shape of tool (dashboard on your VPS, git-push to deploy, one-click databases, automatic HTTPS), fewer of the failures that make users retry deploys or pin to an older version. If that is what you need, it is a legitimate improvement. The honest framing is that it is a within-category improvement. It makes the best one-box PaaS measurably better at being a one-box PaaS.

What it does not do — and does not claim to — is answer what happens when one box is not enough. That is the ceiling Temps shares with every tool that optimizes at the single-server layer.

The One-Box Ceiling: Five Things That Break at Server Number Two​

Every team that benchmarks single-box PaaS tools against each other is asking the wrong comparison once they grow. The relevant comparison is not Temps vs Coolify vs Dokploy (a better dashboard, a lighter idle footprint, a cleaner Compose path). It is any single-box tool vs a fleet that owns machine lifecycle. Five concrete things break at server two, none of them fixed by more reliable deploys:

1. You provision machines by hand. A one-box PaaS assumes servers already exist. You open the Hetzner console, create a CX22 (2 vCPU, 4 GB RAM, 40 GB NVMe, 20 TB traffic for €3.79/month), install Docker, open the firewall, then paste an SSH key into a dashboard to enroll the box. The enroll step is polished; the provision step is still you, every time, and every box drifts from the last one by however much you mis-clicked or forgot to apply.

2. There is no declarative machine lifecycle. A Cluster-API fleet declares machines the way Kubernetes declares pods: a HetznerMachineTemplate, a KubeadmControlPlane, a MachineDeployment that says "I want three workers of type CX22 in nbg1." Controllers reconcile continuously toward that declared state. A dashboard's server list is a record of what you enrolled; a Machine resource is a promise a controller keeps.

3. There is no fleet-wide scheduler. Coolify's multi-server model is a per-resource server picker over SSH; Dokploy's is genuinely cluster-aware but hands clustering to Docker Swarm, not to a workload scheduler that understands tenancy, bin-packing, anti-affinity, or priority. Neither re-schedules tenants off a degraded host automatically the way the Kubernetes scheduler does, because neither owns the host lifecycle to make that decision against.

4. A dead box is a manual incident. When a bare-metal or cloud VM dies under a one-box tool, its apps die with it until a human replaces the machine and re-enrolls it. Under Cluster API Provider Hetzner (CAPH), a MachineHealthCheck plus a HetznerBareMetalRemediation policy can define what "unhealthy" means and what to do — cordon, drain, delete the Machine, let the controller provision a replacement — without paging anyone. The difference is not tooling preference; it is MTTR measured in automatic minutes versus human hours.

5. There is no independent control plane. In a small setup, the PaaS control plane lives on the same box as the apps it manages. One host failure takes both. A CAPH fleet runs a separate management cluster (or at least separate control-plane nodes) whose job is only to reconcile the fleet; workload-cluster failure and management-cluster failure are different blast radii.

Each of these is invisible on day one and load-bearing on day two hundred. The self-hosted PaaS comparison posts that tabulate stars (~57k Coolify, ~35k Dokploy, ~15k CapRover as of June 2026) and one-click service counts (Coolify advertises 280+) are not wrong about the data — they are just scoring the wrong event. The event that matters is not "how nice is the dashboard on box one" but "who rebuilds box two when box one dies at 3am."

Hetzner CX22 Case Study: The Price of the Second Box​

The case-study variable that moves this comparison is not the hardware price. It is the operational cost of the second machine.

Start with the easy math. A Hetzner Cloud CX22 — the reference box a lot of self-hosted teams actually buy — is €3.79/month: 2 vCPU, 4 GB RAM, 40 GB local NVMe, 20 TB of traffic included, in nbg1, hel1, fsn1, or the newer sin region. Two of them are €7.58/month. Whether they are enrolled in Temps, Coolify, Dokploy, or a CAPH fleet, the hardware line is identical. The bandwidth line is where Hetzner's included-traffic model already wins against hosted platforms that meter egress per GB — Temps' own listing leads with "Hetzner charges €1/TB" for that reason — but that win is shared across every self-hosted option, not a Temps advantage.

So anchor on the second box and ask two questions:

Q1: What does a human pay to stand up box two? Under a one-box tool, the steps are roughly: create VM (2 min), install Docker/firmware updates (5-10 min), enroll via dashboard + test deploy (5-10 min), re-issue TLS via Let's Encrypt for any app that moves (automatic but observed to flake under Traefik label conflicts — one of the bugs Temps claims to fix), then redeploy or re-point apps manually. Real elapsed time the first time is 20-45 minutes; repeated drift from hand steps is the tax you pay every subsequent time.

Q2: What does the platform pay to replace a dead box? Under CAPH, the declarative answer is: nothing interactive. A MachineDeployment already says how many machines of what type should exist; the new Machine is created by the controller, bootstrapped via kubeadm, joined to the cluster, and becomes schedulable. Application pods are rescheduled by the scheduler, not by a human re-assigning them in a UI. The wall-clock time is cloud-provisioning plus bootstrap (single-digit minutes on Hetzner Cloud; longer on Robot bare metal where imaging dominates), but the human time is zero — the same zero as every other reconciliation loop in the fleet.

The sensitivity that matters is frequency. If you never add a second box, never lose a box, and never need to move an app off a noisy neighbor, the operational delta between "human enrolls box two" and "controller reconciles box two" is zero and the lighter one-box tool is strictly cheaper to run (no Kubernetes control plane to feed). If you add or replace a box even once a quarter — scaling, region move, hardware failure, kernel upgrade that wants a fresh node — the manual tax compounds and the fleet's fixed control-plane overhead (a few GB of RAM, a few controllers to operate) amortizes.

That is why the honest cost comparison is not a single-row price table. It is two curves crossing at the frequency with which you touch machines. Temps, even at a true 99.9% deploy success, does not move that crossing point — because deploy success is not the axis the curves are plotted on.

The Fragmentation Tax: What "Fixes the Bugs" Signals​

Temps is the fourth credible name in a field that already has a clean ladder: CapRover (since 2017, stable, conservative, ~15k stars), Coolify (since 2021, feature-rich, ~57k stars), Dokploy (since 2024, Swarm-native, ~35k stars, pre-1.0), plus Mooring and Deckrun now rounding out the "lightweight Docker PaaS" slot. Each entrant differentiates by cleaning up the rough edges of the last one:

• Coolify differentiated by being a fully self-hosted Heroku with a marketplace of 280+ one-click services where CapRover was conservative.
• Dokploy differentiated by being lighter and Swarm-native where Coolify was heavier and per-host.
• Temps differentiates by being more deployment-reliable where both predecessors have a tail of intermittent failures.

That ladder is real product iteration. It is also, viewed from the fleet layer, fragmentation at the same altitude. Every new project reimplements: a dashboard, a job queue, SSH multiplexing to managed hosts, a Traefik or NGINX proxy, buildpack/Nixpacks/Dockerfile build paths, per-app secret handling, and backup hooks for its internal Postgres/Redis. Each adds its own maintenance story (self-updating the control plane on the box that also runs apps), its own CVE surface (Coolify's January 2026 disclosure of 11 critical CVEs is the sharpest recent example — bypass auth, run RCE, own the box), and its own upgrade cadence that users pin or defer.

The tell is the tagline shape. When the differentiator is "fixes the bugs" rather than "owns the next layer down," you are watching a category optimize within its ceiling. A 99.9% reliable one-box PaaS is strictly better than a 95% reliable one-box PaaS — and still not a fleet, the way a 99.9% reliable single-node database is still not a replicated one. Reliability within one failure domain does not become availability across two.

What a Fleet Owns — and What It Costs to Own It​

A Cluster-API fleet is not "a better one-box PaaS." It is a PaaS that starts one layer lower: the machines are API objects, not prerequisites.

Concretely, a minimal CAPH fleet declares:

• Cluster + HetznerCluster — the desired control plane topology (how many control-plane nodes, which regions).
• HetznerMachineTemplates — which Hetzner server types back the workers (CX22 cloud VMs, or cpx31-class dedicated boxes, or mixed).
• KubeadmControlPlane + MachineDeployments — how many nodes of each shape, and the rolling-update strategy that replaces them.
• MachineHealthCheck + remediation — when a machine is unhealthy and whether to replace it automatically.
• Workload routing — Gateway/HTTPRoute or ingress objects that tenants' bex.yml git-pushes ultimately reconcile into, rather than a single Traefik container configured per-host.

Operators who want the reference point: SNCF, France's national railway, rebuilt its Kubernetes estate with Cluster API as the declarative lifecycle heart, defining desired state and letting controllers reconcile — including monthly fleet-wide updates with no manual patch nights. A two-person team on a handful of Hetzner boxes is not SNCF, but the core loop is the same; the fleet converges because a controller is watching, not because someone remembered to SSH in.

The honest costs of that bet are also not hidden:

• Control-plane overhead. A Kubernetes control plane plus CAPH controllers consumes more RAM and attention than a single Rails dashboard or a Swarm manager. On a single CX22, that overhead is material; it amortizes only once you actually have a fleet to manage.
• Learning curve. The vocabulary is larger (Cluster, Machine, MachineDeployment, remediation) and the failure modes are distributed (etcd snapshots, CNI bring-up time, CSI driver behavior for stateful tenants). Teams that have never operated a cluster pay that learning curve before they collect the lifecycle dividend.
• No free lunch on stateful workloads. A per-tenant Postgres that runs as a StatefulSet still needs a backup and restore story, CSI snapshots, and a sane PodDisruptionBudget; the platform not being single-box does not make data magically durable.

The reason to pay those costs is not deploy aesthetics. It is that machine lifecycle, scheduling, and self-healing are non-optional once the platform serves more than one tenant or more than one app whose uptime matters independently. Temps optimizes the deploy arrow; Cluster API owns the fleet the arrow lands on.

Picking Honestly​

If the section you needed was at the top — the table — pick from there. If you want the same answer as a decision tree:

• One app, one VPS, never planning to add a second machine. Use Temps, Dokploy, or Coolify — whichever deploy UX you prefer. Temps' reliability pitch is most valuable here, because the only failure domain is that one box and deploys are the only uptime you can control. Kamal's zero-daemon model is also defensible if you live in the terminal.
• Several apps, one box, small team, want a dashboard. Dokploy's lighter idle footprint and cleaner Compose path are built for this; Coolify's broader marketplace and built-in monitoring win when you want more one-click services and can budget ~500 MB - 1.2 GB for the control plane. Temps slots into this same tier — pick it for reported deploy reliability, not for multi-machine assumptions it does not make.
• You already know you'll need a second machine — scale, second region, or blast-radius. That is the event this post measures. Evaluate a Cluster-API fleet (CAPH on Hetzner, with bex as the git-push surface) explicitly as fleet tooling, not as "another dashboard." The cost comparison is hardware+CAPH control-plane overhead versus repeated human machine-ops.

The market has not failed by producing Temps, Dokploy, and Mooring. Those projects meet the demand that exists at the single-server layer, and each makes that layer measurably nicer. What has not changed — and what no single-box polish can change — is that a team that outgrows one box inherited a machine lifecycle problem, not a deploy-reliability problem. "Fixes the bugs" is the right promise for the layer Temps owns. The fleet layer is a different promise to keep: that the machines underneath the deploys are themselves declared, reconciled, and replaceable without a hero SSH session.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. A bex.yml in your repo declares the app; Cluster API declares the fleet underneath. Star the repo on GitHub or deploy your first app today.