your cloud. your metal. same boundary.

01

the problem byoc solves

some code, and some of the data it touches, cannot leave your perimeter. data residency rules, a security review, or a customer contract can all make sending a workload to a vendor's cloud a non-starter.

most sandbox products are cloud-only, so that is usually where the conversation ends. byoc is where it keeps going: the same runtime we operate, running inside the environment you control.

02

what byoc actually means here

you run the exact runtime we run, inside your own cloud or on your own metal. your code and the data it handles stay in your perimeter. you operate it, and we help you evaluate, deploy, and stay current.

• the isolation boundary is the same own-kernel microvm the local and cloud paths use.
• your images, your network, your storage, under your control.

03

the same runtime, and you can prove it

it is apache 2.0. there is no separate enterprise-only build and no closed core. what you run is what we run, and you or your auditors can read the code that enforces the boundary.

for a regulated buyer that is the whole point. you are not asked to trust a black box. you inspect the thing that does the containing before you put it in your fleet.

one sdk. one api. local or cloud is a config change, not a rewrite.

04

what an evaluation involves

an evaluation is a real conversation, not a download link. you tell us your constraints, we help you run the open runtime inside your environment, and your security owner reviews it against your own requirements.

contact us to evaluate running microsandbox inside your own environment.

we give your review real inputs. the accreditation and deployment decision stays with your organization.

05

who byoc is for

• regulated industries where code execution has to stay inside audited infrastructure.
• teams with data-residency requirements that pin where a workload may run.
• anyone who simply cannot send customer code to a third party's cloud.