Dora NodaDigitalOcean started billing Droplets by the second on January 1, 2026 — a minimum charge of 60 seconds or $0.01, whichever is higher, replacing the old full-hour rounding. The pitch is finer granularity for bursty workloads, the same story Cloudflare Containers tells with its 10ms billing increments. But run the math for the workload a self-hosted PaaS actually runs — a control-plane node or worker that's on 24/7 and never scales to zero — and the headline change is worth exactly $0.00. The bill is identical to what it was under hourly billing, because DigitalOcean caps monthly usage at 672 hours (24 × 28 days), which is just a full month. Per-second billing has nothing to shave off a node that's already running the whole time. And the number it doesn't change is still $24/month for a 2 vCPU / 4GB Droplet — 5.5x what the same spec costs flat-rate on a Hetzner CX22.
How Per-Second Billing Actually Works
The mechanics are simple: DigitalOcean bills every second a CPU Droplet exists, with a floor of 60 seconds or $0.01 (whichever is higher), and stops the meter when the Droplet is destroyed. Powered-off Droplets still bill, because the compute stays reserved on the hypervisor — this is purely about how running time gets metered, not about avoiding the classic "forgot to shut it down" bill.
The part that matters for an always-on operator is the cap sitting underneath the whole system: usage is bounded at 672 hours per month (24 hours × 28 days), so no Droplet's per-second bill can ever exceed its flat monthly price. That cap is also, not coincidentally, a full month's worth of continuous runtime. A Droplet that never stops running hits the cap every single month — which means per-second billing and the old hourly billing converge to the exact same number for that workload. The granularity only produces savings when a Droplet doesn't run the whole time, which is precisely the case an always-on control-plane node or worker never is.
The Case Per-Second Billing Was Built For
DigitalOcean's own example, from its launch announcement, is a 10-minute CI/CD job run 20 times a day on an $84/month CPU-Optimized Droplet. Under the old hourly rounding, each 10-minute run billed a full hour at $0.125, for $2.50/day. Under per-second billing, that same job bills for the ~10 minutes it actually used, roughly $0.02/run — about $0.42/day, an 83% cut. That's a real, meaningful savings — for a Droplet that spins up, does 10 minutes of work, and gets destroyed. It's the shape of a build runner, a test job, an autoscaled batch worker. It is not the shape of a PaaS's own long-running control-plane node.
The Variable That Actually Decides the Savings: Session Length
DigitalOcean's 10-minute CI example and an always-on control-plane node are two ends of a spectrum, and where a workload sits on it — not whether it's "bursty" in the abstract — is what determines whether per-second billing saves anything. The old hourly model always rounded a running Droplet's partial hour up to the next full hour; the size of that overpay depends entirely on how long each run was relative to an hour:
| Session length | Old hourly billing charges | New per-second billing charges | Overpay eliminated |
|---|---|---|---|
| 10 minutes | 1 hour (rounded up) | ~10 minutes | ~83% |
| 30 minutes | 1 hour (rounded up) | ~30 minutes | ~50% |
| 2 hours 10 minutes | 3 hours (rounded up) | ~2 hours 10 minutes | ~28% |
| 8 hours (a work shift) | 8 hours (already whole) | 8 hours | ~0% |
| 672 hours (always-on, full month) | 672 hours (already whole) | 672 hours | ~0% |
The pattern is the inverse of session length: the shorter and more frequent the start/stop cycle, the more hourly rounding used to cost, and the more per-second billing now saves. Once a session runs long enough that it's already landing close to a whole number of hours — an 8-hour batch shift, let alone a node that never restarts at all — the rounding "waste" per cycle approaches zero, because there's nothing left to round. A control-plane node with a 672-hour, single-session month is the limiting case at the far end of that curve, which is exactly why it sees exactly $0.00 of the benefit DigitalOcean is advertising. This is also where DigitalOcean's per-second granularity and Cloudflare Containers' 10ms granularity end up making the same point from different starting units: both are optimized for the sub-hour, restart-heavy end of the curve, and both go quiet at the always-on end.
What an Always-On Node Actually Bills
Put a control-plane or worker node through the same billing model with realistic utilization — 100% of the month, because that's what "always-on" means — and the per-second number and the old hourly number land in the same place:
| Billing model | Runtime | $24/mo Droplet | $48/mo Droplet |
|---|---|---|---|
| Old hourly (rounded up) | 672 hrs (100%) | $24.00 | $48.00 |
| New per-second | 672 hrs (100%) | $24.00 | $48.00 |
| Difference | — | $0.00 | $0.00 |
There's no partial hour to round down, because there's no partial hour at all — the node is running every second of every hour of the month, so the per-second meter and the monthly cap arrive at the identical figure. The January 2026 change is real, but it's a change to how DigitalOcean bills idle-to-active transitions, and an always-on node has none of those to bill more precisely.
The Number That Didn't Move: DigitalOcean vs. Hetzner, Flat Rate
With the per-second question settled at "no difference," the number that actually decides the bill is the one DigitalOcean's billing overhaul left untouched: the base rate itself, compared against an owned box with no metering line item at all.
| Spec | DigitalOcean Basic Droplet | Hetzner Cloud | DO premium |
|---|---|---|---|
| 2 vCPU / 4GB | $24.00/mo | CX22 — $4.35/mo | 5.5x |
| 4 vCPU / 8GB | $48.00/mo | CX32 — $7.69/mo | 6.2x |
Hetzner's rate includes 20TB of outbound traffic and a static IPv4 on every plan — there's no separate bandwidth or IP line to reconcile against the compute line, because there's no metering system generating one. The gap isn't a rounding artifact of DigitalOcean's old billing quirks either; it holds at both tiers, and it's the gap that was already there before January 2026 and remains after it.
Scale that to the smallest fleet a self-hosted PaaS control plane realistically runs — three nodes, matching the 2 vCPU/4GB tier for a control-plane quorum — and the multiplier turns into a monthly number worth budgeting around:
| Fleet | DigitalOcean (3× 2vCPU/4GB) | Hetzner (3× CX22) | Monthly gap |
|---|---|---|---|
| 3-node control plane | $72.00/mo | $13.05/mo | $58.95/mo |
Nothing about per-second billing touches that $58.95. It was there in December 2025 under hourly billing, and it's there in the first bill DigitalOcean issues under the new system, because the workload generating it never has an idle second to bill more precisely in the first place.
Where the Savings Really Land — And Why a PaaS Fleet Doesn't See Them
None of this makes DigitalOcean's change hollow — it's a genuine improvement for the workload it targets. Ephemeral build workers, CI runners, and autoscaled AI-agent sandboxes that spin up for a task and scale back to zero are exactly the shape Cloudflare Containers' 10ms billing and now DigitalOcean's per-second billing are both chasing: compute that's bursty enough for rounding-up-to-the-hour to have been a real tax, and idle enough between bursts for finer granularity to matter.
A self-hosted PaaS's own worker fleet — the machines running tenant apps, the control-plane nodes reconciling state, the ingress and database boxes — doesn't have that shape. Those nodes are provisioned to be on, not to scale to zero between requests; billing granularity is a rounding error on a workload that has no idle time to round. That's also the reason the flat-rate comparison, not the billing-model comparison, is the one that actually moves a self-hosted PaaS's bill: owning the box at a fixed monthly rate — no per-second meter, no per-hour meter, no metering line item to optimize against at all — already beats DigitalOcean whether the granularity is an hour or a second.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, priced at what the box actually costs rather than what a per-second meter decides to charge for a node that never stops running. Star the repo on GitHub or deploy your first app today.
