Dora NodaOn July 20, 2026, Deno turns off two things at once: the Deploy Classic dashboard at dash.deno.com, and the v1 API behind Subhosting, its multi-tenant "run your customers' untrusted code under your account" product. Nothing about either migration is automatic. If you have Classic projects or a Subhosting v1 integration, you have ten days from today to move both, by hand, or they stop working.
That double deadline is also a useful accident. Subhosting isn't a new feature Deno bolted onto the rebuilt console.deno.com dashboard — it's a five-year-old, already-proven "platform-on-a-platform" primitive that happens to share a sunset date with Classic. Seeing exactly what it takes to run someone else's code safely inside your own product is the concrete answer to a question every self-hosted PaaS eventually has to face: should you let your tenants resell tenants?
What Actually Breaks on July 20, and What to Do About It
Start with the part that has a hard deadline and no ambiguity. Deploy Classic (dash.deno.com) and the Subhosting v1 API both shut down July 20, 2026. Here's the migration checklist, one row per thing that does not carry over automatically:
| Classic behavior | What changes on the new Deploy (console.deno.com) | What you have to do |
|---|---|---|
| Projects live under your account | Nothing transfers — new org, new app | Recreate every app by hand, reconnect its GitHub repo |
| Environment variables, one set per project | Split into separate production / development / build sets | Re-enter every variable, per environment |
deployctl CLI drives most CI/CD pipelines | deployctl is retired | Swap to the deno deploy subcommand built into the runtime |
serve() from deno.land/std's HTTP module | Unsupported on the new runtime | Rewrite entry points against the current Deno.serve API |
Deno.Kv.enqueue() / listenQueue() (Deno Queues) | Not supported at all | Replace with an external queue or a database-backed job table — no built-in equivalent |
| KV data | Available on new Deploy, but existing data isn't copied | File a migration request with support@deno.com before cutover |
| 6 regions | 2 regions (US, EU) out of the box | Self-host additional regions on your own infrastructure if you need the coverage Classic had |
Two of those are the ones that bite teams who migrate late: KV data requires a support ticket to move (not a self-serve export), and Deno Queues has no replacement at all — if your app depends on it, that's a rewrite, not a migration. Everything else is mechanical but manual, which is the real cost: a Classic project with a dozen env vars and a custom domain is 30–60 minutes of clicking, multiplied by however many projects you're still running there.
What Subhosting Actually Is (It's Not New)
The topic that made this deadline interesting is Subhosting, and it's worth being precise about what it is, because "console.deno.com ships multi-tenant reselling" undersells how long this has existed. Subhosting has been running in production since around 2022 — Netlify's Edge Functions and Deco.cx's customer storefronts both run on it — and Deno made it self-service in 2023, so any developer could deploy and run other people's code programmatically via an API, not just Deno's own enterprise partners. The thing sunsetting on July 20 is its v1 API; v2 is the active version, and existing v1 integrations need to move over before the cutoff.
The architecture is a three-level hierarchy: Organizations contain Projects, and Projects contain Deployments — a bundle of code, config, static files, and an optional Deno KV database, running on an isolated V8 isolate. Deno's own guidance is to give each of your tenants a separate Project, specifically so usage analytics and billing data stay separated per tenant rather than pooled.
Isolation is enforced at the V8-isolate level plus sandboxing underneath it, engineered so one tenant's load or misbehavior can't affect another's. Deno has published dedicated writeups on that isolation work, twice, because it's the hard part of the product, not a footnote to it. Concretely, it's rate-limited: 60 deployments per hour on the free tier, 300 per hour on the builder tier, higher by arrangement on enterprise — numbers that only make sense once you assume the traffic hitting the API is sometimes hostile, not just busy.
So the honest framing is: Subhosting is a mature, hardened API for securely running arbitrary third-party code inside your own product, five years and two isolation-architecture blog posts deep — not a dashboard checkbox Deno just turned on. That distinction matters for the next question, because it changes what "build something like it" actually costs.
Should a git-push PaaS Build This?
Here's the case for treating "let a tenant resell tenants" as a real roadmap item, not a distraction. A platform running on Cluster API and owned machines already has cluster-level tenant isolation via namespaces, network policies, and resource quotas — the scaffolding a lot of multi-tenancy needs is already sitting there. If you leaned on an existing sandboxing layer — gVisor or Firecracker microVMs, both mature and already used by managed platforms to run untrusted code — you wouldn't be inventing isolation from scratch, just wiring an existing sandbox into your existing scheduler. And a narrow version of the feature — a white-label "resell your own branded sub-tenant hosting" add-on for a handful of enterprise customers — is a much smaller surface than a general-purpose public API for arbitrary strangers' code.
That case doesn't survive contact with what Subhosting actually had to get right, though. Namespace isolation and network policies stop a tenant's deployed app from reaching another tenant's resources — they say nothing about whether the build and execution path itself is safe to hand to code you don't trust and didn't review. A git-push PaaS's build step already runs arbitrary shell commands from the pushed repo (installing dependencies, running a build script); today that's fine because the pusher is trusted. Resell that pipeline to a tenant's tenant and the same build step becomes an untrusted-code execution engine you didn't design as one.
Subhosting isn't rate-limited at 60–300 deployments per hour because Deno likes round numbers; that ceiling exists because arbitrary strangers' code is adversarial by default. It will try to exhaust CPU, spike costs, hammer egress, and probe the isolate boundary, not just misbehave by accident the way a well-meaning tenant's app might. Metering and billing per Project isn't a UI nicety either — it's the mechanism that makes each tenant's blast radius visible and chargeable in the first place. Building that properly means becoming, functionally, a hosted-untrusted-code-execution vendor: continuous isolate-security engineering, abuse-pattern detection, and per-tenant cost attribution as an ongoing discipline, competing directly with a company that has spent years hardening exactly that problem and still treats it as worth its own blog series.
That's a different job from what a git-push PaaS on Cluster API is for. The whole model — a developer pushes their own repo, gets their own HTTPS service, on infrastructure they (or their operator) own and trust — assumes the code being deployed is known and trusted by the person deploying it. "Let a tenant resell tenants" quietly swaps that assumption for "safely run code you've never seen, from a customer of your customer, with no way to hold the depth-two operator accountable for what depth-three deployed."
For a general-purpose self-hosted PaaS, that's a scope-creep trap: the narrow white-label case is real, but it's not a feature you bolt onto the existing deploy pipeline. It's a second product, with a second security model, that happens to share a codebase — and it's worth building only if you're willing to fund it like Subhosting, not like a checkbox.
The Practical Takeaway
If you're on Deploy Classic or Subhosting v1, the next ten days are for the checklist above, not for architecture debates: recreate projects, swap deployctl for deno deploy, replace any Queues usage, file the KV migration request now rather than on July 19. If you're building a self-hosted PaaS and someone asks for tenant reselling, Subhosting's own engineering effort is the answer to how big that ask really is — and whether it belongs on your roadmap or on a partner's.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
Sources
- Deploy Classic | Deno Docs
- Migrating from Deploy Classic to Deno Deploy | Deno Docs
- About Deno Deploy | Deno Docs
- Deno Deploy is Generally Available | Deno
- Deno Subhosting | Deno
- About Subhosting | Deno Docs
- Pricing and Limits | Deno Docs
- How security and tenant isolation allows Deno Subhosting to run untrusted code securely | Deno
- How we built a secure, performant, multi-tenant cloud platform to run untrusted code | Deno
- Regions | Deno Docs
