A Daytona alternative with three sizes instead of a rate card
Daytona meters vCPU, memory and storage separately and offers GPU and Windows instances. This service offers three fixed CPU sizes at one flat hourly rate each. Which is better depends entirely on your workload — below is what we could verify from their published pricing on 22 August 2026, including where they are ahead.
Side by side
| Sandbox as a Service | Daytona (published) | |
|---|---|---|
| Pricing model | Three fixed sizes at a flat hourly rate, billed for the time it runs from prepaid credit. | Metered: $0.0504/vCPU/h, $0.0162/GiB/h RAM, $0.000108/GiB/h disk after 5 GiB free. |
| Billing granularity | Per second. | Per second. |
| Equivalent of our small (2 vCPU / 4 GiB / 40 GiB) | $0.09/hour. | ≈ $0.17/hour from the published rates. |
| Equivalent of our large (8 vCPU / 16 GiB / 160 GiB) | $0.55/hour. | ≈ $0.68/hour from the published rates. |
| Free to start | $5 of runtime credit (≈ 56 small-sandbox hours), no card required. | $200 in free compute, stated as no credit card required. |
| Exposed ports / preview URLs | None. A server inside a sandbox is reachable only on its own localhost. | Preview links to services running in a sandbox. |
| GPUs | None. | RTX 4090, RTX 5090, RTX PRO 6000, H100, H200 at published hourly rates. |
| Windows | Linux only. | Windows offered at $0.0858/vCPU/hour. |
| Max sandbox lifetime | 24 hours on any account. | Not stated on the pricing page — check their docs. |
| Interfaces | REST API and hosted MCP server; no SDK packages published yet. | See their documentation. |
| Enterprise features | None. No certifications, no SSO, no audit logs. | Enterprise tier lists SSO and audit logs. |
Daytona column transcribed from daytona.io/pricing on 22 August 2026. The equivalent hourly figures are our arithmetic on their published component rates, not numbers they publish. Rate cards change — verify before committing.
Reading the comparison properly
The headline arithmetic favours flat sizes for the shapes we sell, but that is partly a consequence of selling fewer shapes. A metered card is strictly more flexible: if your workload genuinely needs 1 vCPU and 1 GiB, Daytona can price that and we will still sell you a two-core machine. The flat model wins when your workload happens to match a bundle, and loses when it does not.
The GPU line is not a footnote either. If any part of your pipeline needs accelerated compute — running a local model inside the sandbox, CUDA-dependent tests, image generation — this service cannot do it at any price, and a provider whose rate card includes H100s can. Splitting the workload across two vendors is usually worse than picking the one that covers all of it.
Where the flat model earns its place
Cost predictability for repeatable unit work. If you run one sandbox per user submission, per agent run or per evaluation, the flat model means the cost of that unit is one multiplication, quotable in advance and stable as your volume grows. There is no plan fee to amortise, no per-seat charge, and no floor: an account with nothing running costs nothing. For a product that meters its own customers per job, that maps cleanly onto a margin calculation.
And where per-second billing earns its place
Sub-minute fan-out. A batch of ten thousand 15-second executions is 2,500 billed minutes here and roughly a third of that on per-second billing. If that is your shape, the rounding is the whole comparison and you should choose accordingly. If your sandboxes install dependencies first — which most real ones do — the difference disappears into the install time.
Our rate card
| Size | vCPU | Memory | Disk | Price |
|---|---|---|---|---|
small | 2 | 4 GB | 40 GB | $0.09/hour |
medium | 4 | 8 GB | 80 GB | $0.28/hour |
large | 8 | 16 GB | 160 GB | $0.55/hour |
Prepaid credit, no subscription, no seats. Credit does not expire. Details on the pricing page.
Questions
What does Daytona have that this service does not?
Several things worth being clear about. Their published rate card includes GPU instances — RTX 4090, RTX 5090, RTX PRO 6000, H100 and H200 — and a Windows option at $0.0858/vCPU/hour; we offer neither. Their free trial is $200 of compute against our $5. And they list enterprise features such as SSO and audit logs, which we do not have. (Read from daytona.io/pricing on 22 August 2026.)
How do the prices compare for a plain CPU sandbox?
Daytona publishes $0.0504/vCPU/hour, $0.0162/GiB/hour of memory and $0.000108/GiB/hour of storage after the first 5 GiB free. Applied to a machine matching our small size (2 vCPU, 4 GiB, 40 GiB disk) that arithmetic gives about $0.17/hour; ours is $0.09/hour. At our large size (8 vCPU, 16 GiB, 160 GiB) the same calculation gives about $0.68/hour against our $0.55/hour. Check the current rate card yourself before deciding.
How fine-grained is the billing?
Continuous. We charge the elapsed time between the moment a sandbox becomes ready and the moment it is destroyed, pro-rata against the hourly rate — there is no minimum billing period, no rounding up to the next minute, and no charge for provisioning time. A sandbox that lives 20 seconds is billed 20 seconds, which at the small size is about $0.00050. If you fan out thousands of sub-minute executions, that is the number to compare.
Why would I pick fixed sizes over a metered rate card?
Predictability. With three sizes and one hourly number each, the cost of a job is the size times the minutes and you can do it in your head or put it in a quote. A metered card is more precise and lets you tune a machine to the workload, at the price of an invoice you have to reconstruct from three separate rates. Neither is objectively better; pick the one that matches how you make decisions.
Do both isolate with virtual machines?
We can only speak to ours: one dedicated VM per sandbox with its own kernel, single-tenant, never reused across accounts, destroyed on expiry, code running unprivileged with the metadata endpoint and outbound SMTP blocked. For Daytona's current isolation architecture, read their documentation rather than our characterisation of it.
When should I not use this service?
The clearest case is a public URL for something running inside the sandbox. There are no exposed ports today: a dev server your agent starts is reachable only on its own localhost, so "the agent builds an app and the user clicks a preview link" is a workflow this service cannot do at all. Beyond that: GPUs, Windows, sandboxes living longer than 24 hours, more than 20 concurrent sandboxes without asking, audited compliance attestations, or an official SDK package. Those are real requirements and we do not meet them today. What is left is a narrower case we do meet well: CPU sandboxes, short-lived, driven by an API or an agent, priced flatly.
Price it against your own workload
Sign up, run the job you actually run, and read the ledger. $${SIGNUP_BONUS} of credit, no card.