Comparison · checked
Ephemeral vs Daytona
Daytona is infrastructure for running AI-generated code: sandboxes, containers or full virtual machines, that your application or agent creates and controls through Daytona's SDKs, API and CLI. Ephemeral runs a complete background agent task instead: your prompt, files and allowed connections go in, a fresh microVM does the work with a budget reserved up front, and the machine is destroyed when it finishes.
As of October 22, 2026, Daytona lists no plan fee and bills per second at $0.0504 per vCPU-hour, $0.0162 per GiB-hour of memory and $0.000108 per GiB-hour of storage beyond the first 5 GiB, with $200 of free compute included[1]. Ephemeral charges $0.005 per run plus $0.0002 per second of run time, with model calls at the provider's price plus 15%, from prepaid credits with no subscription.
Side by side
| Feature | Ephemeral | Daytona |
|---|---|---|
| Isolation unit | A fresh microVM for every run, destroyed when the run ends. No machine, file or process is shared between runs. | A sandbox per workload: an isolated container with its own namespaces and hard resource limits, or, for Linux VM and Windows sandboxes, a full virtual machine with its own kernel.[2] |
| Who runs the agent loop | Ephemeral. You send a prompt, input, files and the connections it may use; the agent runs inside the microVM with the model you choose and returns the output. | You do, in your application or in an agent you install in the sandbox. Daytona runs the sandboxes, which your code drives through its SDKs, API and CLI.[3] |
| Credentials | Never enter the machine. Ephemeral holds HTTP API and MCP server credentials, adds them outside the machine, allows only the HTTP methods or MCP tools you list, and removes credential values from responses. | Organization secrets: the sandbox holds a placeholder, an outbound proxy swaps in the real value in HTTPS request headers to the hosts on the secret's allowlist, and the value is scrubbed from responses.[4] |
| Spending control | A hard budget per run, reserved from prepaid credits before it starts. A model call or web request that would go past it is refused. | A prepaid wallet with one-time or automatic top-ups, and a spending summary for the organization.[5] |
| Scheduling | Built in: cron schedules in any IANA time zone start saved workflows. | No scheduler in the documentation; start sandboxes from your own scheduler.[6] |
| Callbacks | A signed POST (HMAC-SHA256) with the run to your server when the run finishes. | Webhooks for sandbox, snapshot and volume events.[7] |
| Zero data retention | A per-run setting: only model endpoints that neither keep nor train on requests, events deleted minutes after the run, output returned once. 10% more on the hosted service. | Not applicable: Daytona does not make the model calls. Your model provider's terms apply.[3] |
| Self-hosting | A licensed edition in your own AWS account, from $490 a month or $4,900 a year (Team plan, 14-day free trial). | Bring Your Own Compute: your own runner nodes in custom regions, managed by Daytona's control plane. It must be enabled for your organization; the pricing page lists BYOC under Enterprise.[8] |
| Where it runs | Hosted in Japan, where run data is stored. The self-hosted edition runs in your own AWS account. | Shared regions in the United States and Europe, or custom regions on your own compute.[9] |
| Pricing model | Prepaid credits from $5, no subscription and no free credit: $0.005 per run plus $0.0002 per second of run time, model calls at the provider's price plus 15%, $0.001 per web fetch and $0.015 per web search. | Pay as you go, billed per second: $0.0504 per vCPU-hour, $0.0162 per GiB-hour of memory, $0.000108 per GiB-hour of storage after the first 5 GiB, GPUs from $0.57 an hour. $200 of free compute included.[1] |
| Longest session or run | 1 hour: the timeout is 1 to 3,600 seconds, 300 by default. | No fixed maximum: a sandbox stops after 15 minutes of inactivity by default, can be set never to stop, and can be given a wall-clock time-to-live.[10] |
| State between sessions | None by design: every run starts clean. Its output and events are kept for 30 days; uploaded files stay until you delete them. | Persistent by default: stopping keeps the filesystem; VM sandboxes can pause with their memory; archives, snapshots, forks and volumes are available.[11] |
| GPUs | None in the machine. Models run at AI model providers; the microVM runs the agent and its tools. | Yes: preemptible GPUs from $0.57 an hour (RTX 4090) to $4.08 an hour (B300); on-demand prices are not published.[1] |
| Languages and SDKs | An HTTP API with an OpenAPI description, a CLI for macOS, Linux and Windows, and an MCP server. No language-specific SDK. | Python, TypeScript, Go, Java and Ruby SDKs, an API and a CLI.[3] |
The prices are not like for like. Daytona's rates pay for the sandbox only: you run the agent loop, and its model calls are billed by your model provider. Ephemeral's run fee and per-second rate pay for the machine and the agent loop together, and model calls are billed through Ephemeral at the provider's price plus 15%. See the pricing page for an estimator and measured runs.
Which to choose
Choose Daytona when…
- Your own agent needs sandboxes it can control from Python, TypeScript, Go, Java or Ruby.
- You need GPUs, Windows machines, or sandboxes that keep running or keep their state between sessions.
- You want sandboxes on your own runner nodes, with Daytona's control plane managing them.
- Your data must stay in the United States or Europe.
Choose Ephemeral when…
- You want a finished background task, not a machine to orchestrate: Ephemeral runs the agent loop, records every step and settles the exact cost.
- Connections should allow only certain HTTP methods or MCP tools, not only certain hosts.
- Each run needs a hard budget reserved before it starts, rather than a wallet balance shared by everything.
- Work should run on a cron schedule in any time zone, with a signed callback when it ends.
- Each task should start clean and leave nothing behind, or run data should be stored in Japan.
What this comparison does not cover
This page compares published features, limits and list prices as Daytona and Ephemeral state them on October 22, 2026. It does not measure speed, start-up time or reliability, and it leaves out enterprise and negotiated pricing as well as Daytona's warm pools, linked sandboxes, macOS and Windows sandboxes in depth, its startup credit programme and its volume discounts. Prices and plans change, so check the sources before you decide. If something here is wrong or out of date, tell us through the support page and we will correct it.
Sources
- https://www.daytona.io/pricing, checked
- https://www.daytona.io/docs/en/isolation, checked
- https://www.daytona.io/docs/en/, checked
- https://www.daytona.io/docs/en/secrets, checked
- https://www.daytona.io/docs/en/billing, checked
- https://www.daytona.io/docs/llms.txt, checked
- https://www.daytona.io/docs/en/webhooks, checked
- https://www.daytona.io/docs/en/bring-your-own-compute, checked
- https://www.daytona.io/docs/en/regions, checked
- https://www.daytona.io/docs/en/sandboxes, checked
- https://www.daytona.io/docs/en/persistence, checked
Ephemeral's side comes from its pricing page, whose prices it shows as they are today, and from its documentation on security and data, runs, connections, budgets and billing, schedules, callbacks, self-hosting, files and the CLI.
More comparisons
- Ephemeral vs E2BE2B fits an agent loop you already run that needs a VM to execute code in, with sessions you can pause and resume.
- Ephemeral vs Modal SandboxesModal Sandboxes fit teams already building on Modal in Python who want sandboxes beside their functions and GPUs.
- Ephemeral vs your own serversYour own servers fit when you need full control of the runtime, GPUs, long-lived processes or a network with no outside access.