Isolation
Every service that runs code gets its own microVM, on a network only your own services share.
MicroVMs
Every web service, worker, Postgres database, build and pre-deploy command runs in its own Kata Containers microVM on Cloud Hypervisor. Each microVM has its own kernel: code inside sees the VM's kernel, never the host's. Privileges granted inside, such as those a Dockerfile build uses, stay inside that VM.
Databases get a microVM like everything else, since a Postgres superuser can run commands through SQL. Database backups and restores run in microVMs too.
Static sites run no code at all. Their files are served as files, each with the type its extension names. An uploaded archive is unpacked with absolute paths, .., symlinks, hard links and devices refused.
Your private network
All your services, across all your projects, share one private network, and nothing else is on it. It starts from deny-all and opens only this:
| Direction | Allowed |
|---|---|
| In | wabi's router to your web services; the internet to a Postgres database you open to public access |
| Between your services | everything |
| Out | DNS and the internet |
Your services never reach other customers' services, the node's own addresses, or the internal ranges 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 and 100.64.0.0/10. An app can still call its own public URL, or another of your services by its URL.
Outbound mail ports 25, 465 and 587 are closed. To send email, use an email provider's API.
Builds run on a network of their own: out to DNS, the registry and the internet, and nothing in. A build reaches no customer's services. Built images live in your account's own registry space, where no other account's build can read or overwrite them, and every deployment runs its image by digest.
The control plane
The dashboard and the API run on their own server, apart from the machine that runs your services, and never run customer code. The node opens no port to the control plane: it dials out over HTTPS. The cluster's API isn't exposed. wabi.is serves no customer content; customer sites live on projectwabi.app.
Resources and disk
Each account has quotas for CPU, memory and disk, checked by the API on every change and enforced again in the cluster. Each service's memory is reserved at its full size. Volumes are LVM volumes with hard size caps, and each container's scratch space has a cap of its own, so every account stays within its own share of disk.
Free sites and uploads
Free static sites go through Cloudflare, which takes their traffic in front of the node. The node accepts requests for free hosts from Cloudflare only.
Every static upload is scanned for phishing and wallet drainers before it goes public, and a match holds it for review. The bytes that go live are the bytes the scan read. Published sites and web services are checked daily against Google Web Risk lists.
What wabi can't read
Your variables are sealed in your browser and open only inside your service's microVM (Sealed variables). A keyless backend signs with no private key in its environment (Keyless backends).
| Data | What wabi holds | Opened by |
|---|---|---|
| Variables | sealed copies and the manifests your wallet signed | your service's microVM, and your wallet in the dashboard |
| Postgres backups | dumps encrypted to your account's sealing key | your account's space in the cluster |
| Keyless accounts | whether keyless is on for a service, and no link to its account | keys derived in your browser |
What wabi holds
| Data | Why | Kept |
|---|---|---|
| Your wallet address | it is your account | until you ask for the account to be deleted |
| Your email, if you add one | expiry and service notices | until you remove it |
| Projects, services, domains, plan and deployment history | running your services | while the account exists |
| Payment records: amounts, plans, transaction signatures | billing and accounting | as long as accounting law requires |
| Logs your services produce | the logs view in your dashboard | 7 days |
| Metrics of your services | the metrics view in your dashboard | 30 days |
| GitHub installation and repository names, if you connect GitHub | building your repositories | until you disconnect |
Keys that move funds
No wabi server holds a key that can move your funds. The treasury's key is on no server; wabi's servers only watch for payments arriving.
Staked tokens sit in the staking program's vault, which returns them only to the wallet that staked them. No instruction lets wabi or anyone else take them out, and pausing the program never stops an unstake or a withdrawal. See Staking.