Daytona vs Koyeb
Daytona starts each sandbox as a container and sells Linux VM, Windows and GPU classes on top, paid from a prepaid wallet. Koyeb runs every sandbox in its own microVM that can sleep when idle and wake on the next request, on monthly plans with GPUs and regions in Asia.
The companies and products
Daytona
Daytona is a cloud for running AI-generated code: you create sandboxes from code through its API and SDKs.
By default a Daytona sandbox is a Linux container with its own namespaces and reserved vCPU, memory and disk. You can also pick a Linux VM class (pause, fork, memory snapshots, /dev/kvm), a Windows VM class, or a GPU class with Nvidia and AMD cards. It is built for teams that run agent code, code interpreters and evals through Python, TypeScript, Ruby, Go or Java SDKs.
- Founded
- 2023
Koyeb
Koyeb is a serverless cloud for apps, inference and sandboxes, and in February 2026 it agreed to join Mistral AI.
A Koyeb sandbox is a Koyeb service: a microVM started from any Docker image and driven from Python or JavaScript SDKs that run commands, read files and expose a port. It can scale to zero when idle and wake on the next request, and it can run on CPU or GPU instance types. It is built for teams that run AI agents or untrusted code next to apps they already host on Koyeb.
Which use cases each one fits
For each use case, Battleships prices every sandbox provider on the same workload and sorts them from the cheapest monthly bill up. “15th cheapest of 367” means 14 of the other 366 providers run that workload, with every feature it needs, for less. “With limits” means the provider runs it but misses something, so it is listed after every full match. Open a use case for its whole ranking and what each provider misses.
| Use case and its workload | Daytona: price rank | Koyeb: price rank | bochka: price rank |
|---|---|---|---|
| Software factory 100 at once · 4 vCPU / 8 GB · 2,200 sessions of 8 h a month Daytona fits once you pick its Linux VM class for /dev/kvm, while Koyeb is a compromise because its local disk is lost on redeploy and it does not document nested virtualization; bochka ranks 3rd with both by default. | 15th cheapest of 367 $4,111 a month | 54th of 367, with limits $366 a month | 3rd cheapest of 367 $634 a month |
| Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB An assistant that lives on its machine needs its files to stay: Daytona keeps a stopped sandbox's disk, while a deep sleep on Koyeb throws the VM away. | 24th cheapest of 366 $6,104 a month | 135th of 366, with limits $923 a month | 5th cheapest of 366 $657 a month |
| Code interpreter bursts 100 at once · 1 vCPU / 2 GB · 200,000 sessions of 1 min a month Both fit short code runs: Koyeb ranks 4th with small instances that sleep after 5 idle minutes, and Daytona creates 300 to 600 sandboxes a minute with no plan fee. | 25th cheapest of 345 $271 a month | 4th cheapest of 345 $66 a month | 186th of 345, with limits $2,000 a month |
| Sandboxes for your users 300 at once · 2 vCPU / 4 GB · 30,000 sessions of 23 min a month 300 sandboxes of 2 vCPU need 600 vCPU, more than Daytona's Tier 4 pool of 500, while Koyeb fits on Scale and wakes a sleeping sandbox on request; bochka ranks first. | 154th of 361, with limits $2,000 a month | 6th cheapest of 361 $495 a month | Cheapest of 361 $209 a month |
| RL rollouts 1,000 at once · 2 vCPU / 4 GB · 1,000,000 sessions of 3 min a month | 130th of 360, with limits $8,261 a month | 237th of 360, with limits $1,631 a month | 34th of 360, with limits $2,000 a month |
| Agent evals 250 at once · 4 vCPU / 8 GB · 15,000 sessions of 20 min a month | 189th of 364, with limits $2,000 a month | 19th cheapest of 364 $429 a month | 10th cheapest of 364 $200 a month |
| CI runners 40 at once · 8 vCPU / 16 GB · 6,000 sessions of 12 min a month Daytona caps one sandbox at 4 vCPU by default and Koyeb does not document /dev/kvm, so Android or VM builds are hard on both; bochka ranks 4th with 8 vCPU from the $20 plan. | 308th of 377, with limits $805 a month | 142nd of 377, with limits $88 a month | 4th cheapest of 377 $86 a month |
| 24/7 dev boxes 1 machine 24/7 · 4 vCPU / 8 GB | 183rd of 368, with limits $245 a month | 217th of 368, with limits $37 a month | 18th cheapest of 368 $26 a month |
| Computer-use agents 50 at once · 4 vCPU / 8 GB · 20,000 sessions of 15 min a month Daytona has a VNC desktop and a computer-use API on Linux and Windows, Koyeb sandboxes have no desktop, and bochka streams a 60fps desktop with Chromium. | 26th cheapest of 369 $1,198 a month | 81st of 369, with limits $123 a month | 6th cheapest of 369 $200 a month |
| Browser-use agents 50 at once · 2 vCPU / 4 GB · 30,000 sessions of 10 min a month Daytona gives the browser a desktop to run on, on Koyeb you install and run a headless browser yourself, and bochka ships Chromium on a desktop in every sandbox. | 93rd of 367, with limits $598 a month | 172nd of 367, with limits $123 a month | 7th cheapest of 367 $200 a month |
| Scraping & bots (startup scale) 50 at once · 1 vCPU / 2 GB · 100,000 sessions of 3 min a month | 38th cheapest of 346 $404 a month | 172nd of 346, with limits $89 a month | 6th cheapest of 346 $90 a month |
| Mass scraping & bots (undetectable) 1,000 at once · 1 vCPU / 2 GB · 3,000,000 sessions of 2 min a month | 202nd of 338, with limits $8,073 a month | 65th of 338, with limits $1,683 a month | 71st of 338, with limits $1,800 a month |
| Parallel red teaming 200 at once · 2 vCPU / 4 GB · 5,000 sessions of 30 min a month | 12th cheapest of 360 $2,000 a month | 233rd of 360, with limits $299 a month | 2nd cheapest of 360 $200 a month |
| GPU eval jobs 10 at once · 8 vCPU / 32 GB · 500 sessions of 30 min a month Both rent GPUs by the hour: Koyeb ranks 3rd and Daytona 20th here, and bochka has no GPUs. | 20th cheapest of 98 $1,190 a month | 3rd cheapest of 98 $628 a month | Can't run it |
| macOS agents 5 at once · 4 vCPU / 8 GB · 1,000 sessions of 20 min a month | Can't run it | Can't run it | Can't run it |
Key features
| Feature | Daytona | Koyeb | bochka |
|---|---|---|---|
| Isolation | Container by default; Linux VM and Windows VM classes have their own kernel | MicroVM per instance; no Windows | Every sandbox is a full VM with its own kernel; no Windows guests, Wine for Windows apps |
| CPU speed (Node.js build-and-test, 4 vCPU / 8 GB) | 21.52 runs/s on the Linux VM class; the default container class reported no result | Not benchmarked; eco instances guarantee half of each vCPU and burst above that | 26.69 runs/s |
| Biggest machine | 4 vCPU / 8 GiB per sandbox by default, raisable per region | Instance types up to 40 vCPU / 128 GB, and larger GPU types | Up to 16 vCPU / 32 GB on the $100 plan and above |
| Docker and nested virtualization | Docker in all classes; /dev/kvm only on Linux VMs, once KVM is turned on for your organization | Starts from any Docker image; nested virtualization not documented | Docker, root, systemd and /dev/kvm on every machine |
| Desktop and computer use | VNC desktop (xfce4) and a computer-use API on Linux and Windows | No desktop or browser in the sandbox SDK | 60fps desktop with Chromium, computer use and browser control, embeddable stream |
| Files after a stop | Disk is kept and billed while stopped; archived containers are free | Local disk is lost on redeploy; volumes (preview, 1 to 10 GB, two regions) persist | Disk kept across stops and saved every minute; a stopped sandbox costs nothing |
| Pause, snapshots and fork | Linux VM and Windows: pause, resume and fork with memory kept; containers: no pause or fork | SDK snapshots of the filesystem or running processes, then new sandboxes from them (experimental) | Fork a running sandbox with its disk; resume reboots from disk |
| Sleep and wake | Auto-stop when idle; you start it again by API | Scales to zero after 5 idle minutes or more and wakes on the next request; Light Sleep wakes in about 200 ms | Stop and start by API; a stopped sandbox costs nothing and keeps its disk |
| Reaching the sandbox | HTTPS preview URLs on any port, token-protected or public; SSH; no raw TCP or public IP | One exposed HTTPS port at a time, plus an optional TCP proxy to one port; no dedicated IP | HTTPS URLs for up to 50 ports, token-protected; raw TCP; dedicated IPv4 or IPv6 |
| Outbound internet | Tier 1 and 2 reach only package registries, git hosts and AI APIs; Tier 3 and up get open internet plus domain or CIDR allowlists | Open internet, or block all outbound traffic, or allow only listed IPs and CIDRs | Open internet on every plan; no provider-side allowlist |
| Keeping API keys out of the sandbox | Secrets proxy swaps placeholders in HTTPS request headers for allowed hosts | Secrets are set as environment variables inside the service | Credentials proxy for model providers and any HTTPS API; switch a credential to another account when credits run out |
| Coding agents | Guides install agents and run them through process exec | Tutorials run agents through the command API | Claude Code, Codex, OpenCode and more preinstalled, with a prompt, steer and events API |
| GPUs | Nvidia RTX 4090 up to B300, and AMD MI355X, on-demand or preemptible | RTX 4000 SFF Ada up to H100, H200 and multi-GPU | None |
| Regions | US and EU, plus dedicated regions or your own machines | EU, US and Asia; edge and on-premise for Enterprise | EU only: Germany, Finland, France |
Every feature Battleships tracks (43)
| Feature | Daytona | Koyeb | bochka |
|---|---|---|---|
| Full VM (own kernel) | No | Yes | Yes |
| Docker inside | Yes | Yes | Yes |
| Nested virtualization | Yes | No | Yes |
| Root | Yes | Not published | Yes |
| Systemd | Not published | Not published | Yes |
| Desktop GUI | Yes | No | Yes |
| Browser | Yes | No | Yes |
| Computer-use API | Yes | No | Yes |
| SSH | Yes | No | Yes |
| Persistent disk | Yes | Yes | Yes |
| Pause/resume | Yes | Yes | Yes |
| Automatic snapshots | Yes | Yes | Yes |
| Fork/clone | Yes | Yes | Yes |
| Live fork (no pause) | No | Not published | Yes |
| Memory fork | Yes | Yes | No |
| Custom image (Docker or snapshot) | Yes | Yes | Yes |
| ≥24 h sessions | Yes | Yes | Yes |
| Idle auto-stop | Yes | Yes | No |
| Wake on request | No | Yes | No |
| HTTPS preview URLs | Yes | Yes | Yes |
| Raw TCP inbound | No | Yes | Yes |
| Public IPv4 | No | No | No |
| Egress allowlist | Yes | Yes | No |
| Secret proxy | Yes | No | Yes |
| Secret proxy for any API | Yes | No | Yes |
| Preinstalled agents | Yes | Yes | Yes |
| Agent harness API | No | No | Yes |
| MCP server | Yes | Yes | No |
| GPU | Yes | Yes | No |
| Windows | Yes | No | No |
| Arm64 | No | No | No |
| Self-hosting | No | Yes | No |
| BYOC | Yes | Yes | No |
| Open source | No | No | No |
| Scoped API keys | Yes | Not published | Yes |
| Spend limits | Not published | No | Yes |
| Usage per sandbox (API) | Yes | No | Yes |
| Audit logs | Yes | Yes | No |
| SSO | Yes | Yes | No |
| SOC 2 | Yes | Yes | No |
| HIPAA | Yes | No | No |
| EU data residency | Yes | Yes | Yes |
| Zero data retention | Not published | Not published | Yes |
Performance
In StarSling's public run of 2026-09-29, at 4 vCPU / 8 GB, bochka did 26.69 Node.js build-and-test runs per second and Daytona's Linux VM class did 21.52; Daytona's default container class reported no result. Koyeb was not part of that run, so there is no comparable number for it. Koyeb publishes a CPU share of at least 0.25 dedicated vCPU per GB of memory, bursting to all cores, so its speed depends on how busy the host is.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. Daytona measured on: Linux VM sandbox (same rates; KVM / nested virt per-org feature). Koyeb has no published run in this suite yet, so there is no like-for-like number to compare.
Pricing in five scenarios
Each bill is priced from the providers' public price lists by the open Battleships engine, with the cheapest plan that runs the scenario.
| Scenario | Daytona, a month | Koyeb, a month | bochka, a month |
|---|---|---|---|
| One coding agent, workdays 4 vCPU / 8 GB, 50 GB disk, 8 hours a day, 22 days a month, files kept between days | $56 · Tier 3 ($500 top-up) | $29 · Pro | $20 · $20/mo |
| One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month | $245 · Tier 3 ($500 top-up) | $57 · Pro | $26 · $20/mo |
| 50 agents in parallel 50 machines of 4 vCPU / 8 GB at once, 8-hour sessions, 1,100 sessions a month, Docker inside | $2,682 · Tier 3 ($500 top-up) | $475 · Pro | $317 · $20/mo × 3 seats |
| Sandboxes for your users 2 vCPU / 4 GB, 30,000 sessions of 10 minutes a month, up to 300 at once | $2,000 · Tier 4 ($2,000 top-up every 30 days) · with limits | $329 · Scale | $200 · $100/mo × 2 seats |
| 1,000 short jobs at once 2 vCPU / 4 GB, 1,000 at once, 3 minutes each, 200,000 jobs a month | $2,000 · Tier 4 ($2,000 top-up every 30 days) · with limits | $485 · Scale · with limits | $2,000 · $2000/mo · with limits |
Daytona: Daytona bills per second for the vCPU, memory and disk you reserve, including while a sandbox starts or stops, and keeps billing the disk while it is stopped. You pay from a prepaid wallet: open internet needs a $500 top-up (Tier 3), and the biggest pool needs $2,000 every 30 days (Tier 4).
Koyeb: Koyeb bills each instance per second at a fixed price per instance type, and Deep Sleep costs nothing. Pro costs $29 a month with $10 of usage included and Scale $299 with $100 included; the rest of the fee is not credit, and bandwidth above 1 TB is extra.
Koyeb: Plans start at $20 a month, and the whole fee is usage credit spent per second on running sandboxes. A stopped sandbox costs nothing and keeps its disk.
Limits in those scenarios
Daytona limits the total vCPU, memory and disk running at once: 500 vCPU on Tier 4, so 300 sandboxes for your users (600 vCPU) and 1,000 short jobs at once (2,000 vCPU) need a custom limit. Tier 1 and 2 also reach only an allowlist of package registries, git and AI APIs. Koyeb's priced shape has a 20 GiB disk with no published price for more, and its eco instances guarantee only half of each vCPU, so the 1,000-job burst gets throttled. bochka queues starts above 90 a minute, so that burst does not fit its $2,000 plan either.
| Scenario | Daytona | Koyeb | bochka |
|---|---|---|---|
| One coding agent, workdays |
|
| None that bite |
| One agent that never stops |
|
| None that bite |
| 50 agents in parallel |
| None that bite | None that bite |
| Sandboxes for your users |
| None that bite | None that bite |
| 1,000 short jobs at once |
|
|
|
Which one should you use?
Use Daytona when
you need Windows sandboxes, a pause that keeps memory, a desktop for computer use, or sandboxes on your own machines.
- Windows and memory pause. Useful if you need Windows desktops, or a sandbox that pauses and comes back with its memory: Daytona's VM classes do both.
- A desktop for computer use. Useful for agents that click through apps: Daytona has a VNC desktop and a computer-use API, and Koyeb sandboxes have no desktop.
- Files stay when it stops. Useful for long agent sessions: Daytona keeps a stopped sandbox's disk, while Koyeb loses its local disk on redeploy.
Use Koyeb when
your sandboxes sleep most of the time and must wake on a request, need big machines or GPUs, or have to run in Asia.
- Sleep when idle, wake on request. Good for sandboxes that sit idle between requests: Koyeb scales to zero and wakes on the next request, in about 200 ms with Light Sleep.
- Open internet from the first plan. Useful if agents fetch from anywhere: Koyeb sandboxes reach the open internet, while Daytona allows it only from Tier 3.
- Bigger machines and Asia regions. Useful for heavy jobs or users in Asia: Koyeb goes up to 40 vCPU / 128 GB and runs in Singapore and Tokyo.
Where bochka fits
If your sandboxes run coding agents for hours, both Daytona and Koyeb make you pick between a full machine and one that keeps its files, and both leave the agent harness to you. bochka gives every sandbox a full VM that keeps its disk, a desktop, 50 HTTPS ports and preinstalled agents you drive from outside. It runs only in the EU and has no GPUs or Windows, so those jobs belong on Daytona or Koyeb.
A full VM with /dev/kvm on every sandbox
Daytona's default container shares the host kernel, and /dev/kvm needs its VM class plus KVM turned on for your organization. Koyeb does not document nested virtualization, so Android emulators and VM builds run elsewhere.
A disk saved every minute, and free stops
Daytona keeps billing a stopped sandbox's disk. On Koyeb the local disk is lost on redeploy and a deep sleep discards the VM, so lasting files need a preview volume of 1 to 10 GB in two regions.
Agents, desktop and ports built in
On both, you install the agent and write the code that starts, prompts and watches it through exec. Koyeb also exposes one port at a time and has no desktop, so a dev server plus a browser agent needs workarounds.
Use bochka when your agents do real work for hours on a faster full VM that keeps its disk: builds, Docker, emulators, a desktop browser and preview servers, with agents and keys handled for you. Compare it one to one: bochka vs Daytona and bochka vs Koyeb.
Questions people ask
Is Daytona cheaper than Koyeb?
Not in the scenarios we priced. One coding agent on workdays comes to $56 a month on Daytona and $29 on Koyeb, one agent running all month to $245 against $57, and 50 agents in parallel to $2,682 against $475. On bochka the same three come to $20, $26 and $317.
Which is faster, Daytona or Koyeb?
Only Daytona was measured: its Linux VM class did 21.52 Node.js build-and-test runs per second at 4 vCPU / 8 GB. Koyeb was not in that benchmark run. bochka did 26.69 runs per second in the same run.
Can Daytona and Koyeb run Docker and Android emulators?
Daytona runs Docker in all classes, and offers /dev/kvm for emulators only on its Linux VM class once KVM is turned on for your organization. Koyeb sandboxes start from Docker images, but Koyeb does not document nested virtualization. bochka has Docker and /dev/kvm on every machine.
Do Daytona and Koyeb sandboxes keep their files?
Daytona keeps a stopped sandbox's disk and bills it until the sandbox is archived. Koyeb loses the local disk on redeploy and a deep sleep discards the VM, so lasting files need a volume (in preview) or an SDK snapshot. bochka keeps the disk across stops and saves it every minute.
Do both have GPUs?
Yes. Daytona rents Nvidia cards from RTX 4090 to B300 and AMD MI355X, on demand or preemptible. Koyeb runs instances from an RTX 4000 SFF Ada up to H100 and H200. bochka has no GPUs.
Can the sandboxes reach the internet?
On Daytona Tier 1 and 2, only package registries, git hosts and AI APIs are reachable; open internet starts at Tier 3 with a $500 top-up. Koyeb sandboxes reach the open internet and can block it or allow only listed IPs. bochka has open internet on every plan.
Try bochka
Install the CLI, then run bochka new.
Product preview