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 is provisioned. This page explains what that boundary is, where it stops, and what is available to teams who need it to stop somewhere else.

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. The database and authorization boundaries hold on every request; the host-level network rules are re-checked every fifteen minutes. Neither is wired into the release path yet.
• 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.

What every Wok gets

Your Wok runs its own Postgres, its own services, and its own private network on shared bare-metal. Nothing is co-tenanted at the database or network layer: another team's Wok cannot address your database, reach your services, or see your traffic, and its credentials do not exist in your stack. Teams share the host's operating-system kernel, which is the boundary this tier does not cross.

That is the whole isolation story for the product as it ships. There is no tier to pick when you create a Wok, and no upgrade path you are missing.

If you need more separation

Two stronger arrangements exist for teams whose compliance requires them, and both are set up with us rather than chosen at provisioning time:

• Sandboxed runtime — your containers run inside a runtime that sits between your app and the host kernel, narrowing what a hostile workload could reach. It runs on hosts where that runtime is enabled.
• Confidential compute — hardware that keeps your app's memory encrypted while it runs and can attest which code is running, so TellWang cannot read your running memory. It needs AMD SEV-SNP or Intel TDX hardware, brought online per engagement.

If either is a hard requirement, talk to us before you build — the answer depends on which hardware your workload lands on.