Isolation tiers
Every Wok is its own private setup, isolated from every other team at the database, network, and authorization layers from the moment it's provisioned. That's the default, and for almost every team it's the right level. The tiers below let you trade density for stronger isolation when a workload or a contract demands it.
What "isolation" actually means here
There are two separate questions, and they're easy to confuse:
- Can another team reach your data or your app? This is the one that matters for nearly everyone, and it's answered the same way on every tier: your own database, your own private network, and a server-side authorization check that returns a blank 404 to anyone outside your team. We re-test it on every release.
- Can we — the people running the hardware — read your app's memory while it runs? By default you trust your provider not to, the same as with any managed cloud. Some regulated teams need a guarantee that we can't, not just that we don't. That's what the Confidential tier adds, and it's the only thing that needs special hardware.
Worth being precise about one thing: hardware memory encryption protects everyone on a machine from whoever runs that machine. It does nothing to separate one team from another — that separation comes from the database, kernel, and authorization controls below, which apply on every tier.
The tiers
Standard
ShippedYour own Postgres, your own services, your own private network — bin-packed efficiently onto shared bare-metal. Strong database-level, network-level, and authorization-level isolation. Teams share the host's operating-system kernel. This is what every Wok runs on today, and it's the default.
Dedicated host
RoadmapThe same stack, but your Wok runs on hardware no other team shares — no shared kernel with a neighbor. For teams that want physical separation without changing how anything works.
Needs: our multi-machine rollout, in progress.
Confidential
RoadmapYour containers run inside a sandboxed runtime that sits between your app and the host's kernel, shrinking what a hostile workload could ever reach. The strongest separation between teams short of separate machines, while staying dense enough to be affordable.
Needs: a sandboxed runtime enabled on the host. The engineering is in place; we turn it on per machine.
Confidential + hardware attestation
RoadmapEverything in Confidential, plus hardware that keeps your app's memory encrypted while it runs and can prove to you which code is running. This is the guarantee that we can't read your running memory — for teams whose compliance requires it in writing. Available on confidential-compute hardware, brought online for the deals that need it.
Needs: confidential-compute hardware (AMD SEV-SNP / Intel TDX). Procured per engagement.
A lighter option for small workloads
Micro
RoadmapFor hobby projects and tiny workloads, a lighter tier shares one database across teams using separate schemas, roles, and row-level rules, with a small per-team API in front. It's cheaper because the heavy part is shared — and its isolation is correspondingly lighter, since teams share one database engine. We'll offer it for small, non-sensitive workloads; sensitive data belongs on Standard or higher.
Choosing a tier
Start on Standard — it's the default and it's enough for nearly everyone. Move up when a specific need appears: physical separation (Dedicated), a harder kernel boundary between teams (Confidential), or a written guarantee that we can't read your memory (Confidential + attestation). Pricing for the higher tiers is set per engagement; talk to us about what your workload requires.