01
the boundary should match the tenant
one microvm per customer task means a hostile tenant lands inside their own kernel, with nothing of their neighbors to find.
back to microsandbox
use case / multi-tenant
your customers' code, on separate kernels.
if your product runs plugins, notebook cells, or user-submitted jobs, one shared kernel is one bad day away from a headline. give every tenant their own machine.
02
networks are per-tenant too
by default, sandboxes can reach the public internet. private, host-local, link-local, and metadata destinations are blocked. egress can be reduced to an allowlist or disabled entirely. in the cloud, the non-public block cannot be lifted, even by you.
each sandbox gets its own policy, so tenant a's job can't discover tenant b's services.
credentials are destination-bound. the sandbox works with a placeholder; the real value is substituted host-side into supported intercepted outbound requests, only for destinations on your allow-list. an approved destination still receives the real credential and could reflect or misuse it, so scope your allow-lists accordingly.
03
know whose sandbox did what
name and label each sandbox with its tenant and job. metering, logs, and invoices line up with the same labels.
the execution boundary and the attribution boundary describe the same unit: one tenant task in one machine.
04
choose who operates byoc capacity
one sdk. one api. local or cloud is a config change, not a rewrite.
byoc brings the same runtime to your own cloud or metal.
contact us to evaluate running microsandbox inside your own environment.
how it works
one machine per tenant task
01
create for the task
start a separate microvm with the tenant's image and resource limits.
02
set its network
give that task only the public destinations it needs while non-public destinations stay blocked.
03
label the work
attach the tenant and job identifiers to the same sandbox that runs the code.
04
measure the same unit
metering, logs, and invoices line up with the sandbox labels you chose.
see it work
label one bounded tenant job
bash
msb run alpine \
--name tenant-8123-job-441 \
--label tenant=8123 \
--memory 512M \
--no-net \
-- sh -lc 'id && uname -a'
msb rm --force tenant-8123-job-441know the limits
- there is no kubernetes operator or helm chart in the local runtime.
- managed cloud capacity is invite-only.
- byoc is evaluated case by case; no broader offer is promised here.
evaluate the alternatives