Daytona's Customer-Managed Compute: What 'Bring Your Own Hetzner Account' Actually Costs and Controls

Daytona closed a $24M Series A in February 2026 on a pitch that sounds like ownership: point its sandbox control plane at your own cloud account or your own hardware, and Daytona-owned infrastructure never touches your workloads. It's called customer-managed compute, and on paper it looks like the self-hosting answer to every "who's running my AI agent's code" question a regulated enterprise might ask.

It isn't self-hosting. It's renting the control plane and owning the electricity bill — a distinction that matters the moment you try to price it or explain to a compliance team who actually holds the keys. This piece works through what customer-managed compute concretely costs against Daytona's published cloud rate and a real Hetzner box, what it still hands Daytona regardless of whose hardware the sandbox runs on, and where that trade is a legitimate shortcut versus where it's just trust with extra steps.

The Three Tiers Daytona Actually Sells​

Daytona's docs describe three deployment shapes, not two, and the differences matter more than the marketing copy suggests.

1. Shared Regions (fully managed cloud). Daytona runs everything — control plane and compute — on its own US/EU infrastructure. This is the tier with public pricing: $0.0504 per vCPU-hour, $0.0162 per GiB-hour of RAM, $0.000108 per GiB-hour of storage, with a $200 compute credit to start.
2. Customer Managed Compute (Custom Regions). You connect your own "runner" machines — in your AWS/GCP account, on-prem, wherever — to Daytona's control plane. Daytona still schedules sandboxes, still terminates the API and dashboard, still handles auth and billing; only the actual compute moves to hardware you hold the account for. This tier is explicitly invite-only and experimental, gated behind emailing support@daytona.io.
3. Fully self-hosted, AGPL-3.0. The entire stack — control plane included — deployable via a single Docker Compose on infrastructure you run end to end, no Daytona service in the loop at all. Same codebase as the managed product, no feature gating, but you now own operating the control plane too, and AGPL's network-use clause means any modification you ship to users over a network has to be republished.

The vendor's own differentiation story leans on speed, not sovereignty: Daytona advertises sub-90ms cold starts, with tuned production configs claimed at 27ms, against what it frames as E2B's roughly-sub-second baseline. That's a vendor-stated number, not an independently benchmarked one — Daytona uses Docker containers with a shared host kernel rather than E2B's per-session Firecracker microVM, which is architecturally the reason it can start faster and also the reason its isolation boundary is thinner. Speed and isolation are trading against each other here, not stacking for free.

Tier 2 is the one this piece is actually about, because it's the one marketed as "own your infrastructure" while still being a Daytona product you don't fully control.

The Cost Line You Can See, and the One You Can't​

Here's what's actually priced and what isn't.

Known: Daytona's managed cloud rate. $0.0504/vCPU-hour, $0.0162/GiB-RAM-hour. This is the number Daytona will show you on a pricing page with no sales call required.

Known: a real self-hosted node. Hetzner's CCX33 — 8 dedicated AMD EPYC vCPUs, 31 GiB RAM, 240 GB local SSD, traffic and DDoS protection bundled — costs €138.49/month as of the June 15, 2026 price adjustment (up from €62.49/month, a 122% hike that's its own story). At roughly $1.08/EUR that's about $149.57/month, or $0.205/hour per node regardless of utilization — call it $0.026/vCPU-hour raw, ignoring the RAM Daytona bills separately. That's roughly half of Daytona's published cloud rate for the compute itself, before you've paid anyone a control-plane fee.

Unknown: what customer-managed compute actually costs. Daytona doesn't publish a control-plane fee for Tier 2. There's no self-serve signup, no rate card, no calculator — the entire tier is behind a support email and, per its own docs, "invite-only" and "experimental." Whatever Daytona charges to keep scheduling your sandboxes once the compute is yours is a number you get by asking, not by reading.

That's not a Daytona-specific failure of transparency — it's the pattern. E2B's equivalent, BYOC (bring your own cloud), works the same way: available only on AWS and GCP, "for enterprise customers only," requiring a dedicated AWS account, a hand-off IAM role, and Terraform-provisioned infrastructure before E2B tells you what it costs. Two competing vendors, same shape of deal: the compute-ownership tier is the one that isn't self-serve and isn't priced in public.

So the honest cost comparison looks like this:

The number a buyer actually needs — "what does customer-managed compute cost against just running the box myself" — isn't answerable from anything Daytona or E2B publishes. You can price one side of that equation today. The other side requires a sales conversation whose outcome isn't public, which is itself information: a fee opaque enough to need a quote is a fee that isn't fixed, and isn't guaranteed to stay where it started once you're dependent on the integration.

What "Control" Actually Transfers When Compute Does​

Cost is the part that's easy to notice is missing. Control is the part that's easy to assume you got just because the hardware bill has your name on it.

Even in customer-managed compute, Daytona's control plane keeps:

• The sandbox lifecycle API — create, snapshot, stop, resume all flow through Daytona's service, not a system you operate.
• Scheduling — which runner gets which workload is Daytona's decision, made on infrastructure you don't see.
• Auth and access control — who can spin up a sandbox against your runners is gated by Daytona's account system.
• Telemetry and logs — usage data about workloads running on your hardware passes through Daytona's observability stack before you see it.

What actually moved to your account is the compute bill and the physical (or cloud-account) location of execution — genuinely useful for data-residency and physical-custody requirements, which is exactly why Daytona pitches this tier at HIPAA and SOC 2 buyers. What didn't move is anything that would let you operate independently of Daytona if the relationship ends, the pricing changes, or the invite-only program gets deprioritized. You're still one support ticket away from Daytona changing how your own hardware gets scheduled.

Contrast that with a Cluster-API-native platform running Firecracker-style sandboxes on owned Hetzner machines, where there's no third-party control plane at any layer: the entity provisioning the box, scheduling the workload, terminating the API, and holding the audit log is the same entity that owns the hardware. Nothing about how your sandbox fleet runs depends on a vendor's invite-only program staying open. That's the difference between "my compute, someone else's control plane" and "my compute, my control plane" — and it's a difference that only shows up when you ask who could take something away from you, not who's currently billing you for it.

Where the Hybrid Model Actually Helps — and Where It's Still Renting Trust​

Customer-managed compute is a real, defensible middle ground for one specific situation: a regulated buyer that needs data-residency or physical-custody guarantees now, doesn't have the engineering capacity to stand up and operate a full sandbox control plane, and is willing to trade "no vendor sees my data" for "a vendor still schedules my compute." For that buyer, it's faster than building AGPL self-hosting in-house, and it's a real compliance win over the fully managed cloud tier — the workload genuinely never leaves their account.

It stops being a middle ground and starts being rented trust the moment the reason you wanted "your own compute" was independence rather than data residency. If the goal is "I don't want to depend on this vendor's roadmap, pricing, or continued interest in an invite-only program," customer-managed compute doesn't get you there — Daytona is still the one system of record for how your sandboxes get scheduled and who's allowed to touch them. You've reduced your data-location risk and left your platform-dependency risk exactly where it was.

The decision rule is simple: if what you're solving for is where the bytes physically sit, customer-managed compute is a legitimate shortcut. If what you're solving for is not depending on a vendor's control plane, only full self-hosting — Daytona's AGPL stack, or a Cluster-API-native fleet built for this from the start — actually closes that gap, because it's the only tier where nobody outside your organization is a single point of failure for your own sandboxes.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with no third-party control plane sitting between you and your own hardware. Agent sandboxing is on the roadmap built the same way: your compute, your control plane, not a rented one. Star the repo on GitHub or deploy your first app today.

Sources​

• Customer Managed Compute — Daytona Docs.
• Daytona Pricing.
• Daytona Raises $24M to Replace Cloud Infrastructure Built for Humans With One Built for Agents — AlleyWatch.
• daytonaio/daytona — GitHub.
• E2B BYOC (Bring Your Own Cloud) Docs.
• Daytona vs E2B in 2026 — Northflank.
• Hetzner Price Adjustment 15 June 2026 — Hetzner Docs.
• ccx33 by Hetzner Cloud — Spare Cores.