Sign in Sign up

Enterprise

Enterprise & on-prem

Run a brintOS control plane and a Network-as-a-service endpoint inside your own VPC, with end-to-end encryption keyed to your KMS. Your team's machines execute in their tabs on their CPUs; their network egress rides your perimeter; their bytes never leave keys you don't hold. Your data integrity boundary stays exactly where it was, while your team gets to work from any browser, on any continent.

The architecture, in one paragraph

On Enterprise, the parts of brintOS that touch your data move inside your perimeter. The Network-as-a-service terminator runs as a hardened appliance in your VPC; egress and DNS resolve against your existing allowlists and proxies. The Cloud Storage blob store lives in a bucket inside your AWS account, with bytes encrypted by keys held in your KMS. The control plane — the part that mints sessions, gates access, and serves the SvelteKit app — runs either as a brintOS-managed tenant scoped to your org, or as a fully self-hosted control plane inside your environment. Your team uses the same brintOS runtime everyone else does; the difference is who owns the perimeter it operates inside.

Network-as-a-service on-prem

The on-prem NaaS endpoint is the heart of the Enterprise deployment. It's a single appliance — delivered as an OCI image, a CloudFormation template, or a Terraform module — that you run on your own infrastructure. Every brintOS session opened by a member of your organization terminates here, not at our public POP.

  • Your perimeter, your rules. Egress rides your existing NAT, your existing firewall, your existing data-loss-prevention stack. Inbound NIC subscriptions resolve via your DNS. There is no "brintOS network" between your users' tabs and the destinations they reach — only your network.
  • Your packet metadata never leaves. The terminator logs locally to a destination you specify (S3, GCS, Splunk, an in-VPC SIEM). brintOS's SaaS-side operations never see the contents, source IPs, destinations, or volumes of your team's traffic — we can't, because we're not on the path.
  • Bring-your-own egress policy. Allowlists, deny rules, per-tenant bandwidth caps, time-of-day controls, geo restrictions — everything is configured against the terminator's policy file, which can be checked in alongside the rest of your network IaC.
  • Air-gap-compatible. The appliance ships every artifact it needs to boot and run. Customers in regulated environments can run the entire stack — control plane, blob store, NaaS endpoint — without an outbound link to brintos.io at all. Updates are pulled on your schedule from a brintOS-signed registry mirror you stage internally.

End-to-end encryption keyed to your KMS

Enterprise machines are encrypted under keys your organization owns, not keys brintOS holds. We don't have a master key that can decrypt your snapshots; the math doesn't allow it.

  • Rootfs snapshots are sealed with customer-managed keys. Blob objects are wrapped with AES-256-GCM data keys, and each data key is in turn wrapped by a customer master key in your KMS (AWS KMS, GCP KMS, HashiCorp Vault Transit). brintOS's storage service stores ciphertext and wrapped data keys; the unwrap call goes to your KMS and is gated by your IAM.
  • Sessions decrypt in-browser. A launching tab fetches the wrapped data key, calls your KMS to unwrap (or receives a short-lived unwrapped key via a policy you control), and the wasm runtime decrypts the rootfs locally as the machine boots. The plaintext bytes only ever exist inside a tab that already passed your access policy.
  • Secrets attached to machines are sealed with libsodium sealed boxes whose recipient public key is configurable per-org. Even brintOS support, with full database access, would see only ciphertext.
  • Key rotation is your call. Rotate the master key on your KMS schedule. Existing wrapped data keys are rewrapped on next access; the rotation is invisible to your users but auditable in your KMS audit log.
  • BYOK / HYOK supported. If your compliance team requires the master key never leave a hardware module, point brintOS at the HSM-backed key handle. We never see the key material, only the unwrap result for the wrapped data key, and only inside the user's authenticated session.

Why these two together are the point

The combination of an in-perimeter NaaS endpoint and customer-managed encryption is what makes Enterprise brintOS a genuinely different deployment model from any cloud dev environment you might compare us to. Each layer on its own is useful; the two together change the threat model.

  • Your bytes never traverse a network you don't own. The rootfs decrypts in the user's tab; their tab's network traffic terminates inside your VPC. From the moment the kernel boots to the moment it shuts down, the data path is bounded by your perimeter.
  • Your keys never leave KMS. brintOS's own services have no privileged access to your snapshots. The "brintOS employee with database read" attack — the one that keeps your security team up at night about every SaaS — collapses into "an attacker who can read encrypted blobs they have no way to decrypt."
  • Your team gets to work from anywhere. Because the runtime is the browser, your engineers can pick up their personal MacBook on a Sunday, sign in through your IdP, and resume the same machine they were debugging on the office Thinkpad — and none of the bytes touch the personal MacBook's disk. The machine boots in the browser tab; closing it leaves nothing behind.
  • You retain data integrity across BYOD. The two pieces interlock to give you the property regulated industries actually need: a fleet of distributed contributors working on highly-sensitive workloads, from devices you don't necessarily own, without ever extending your trust boundary to those devices. The trust boundary is the perimeter plus the browser sandbox — not the laptop.

What the deployment looks like

A typical Enterprise rollout has three phases. We'll do as much of it side-by-side with your team as you want.

  • Week 1 — Tenancy. Stand up the brintOS control plane as a dedicated tenant (SaaS) or inside your VPC (fully self-hosted). Federate your IdP. Decide on storage region(s) and key topology with your security team.
  • Week 2 — Network. Deploy the NaaS terminator inside your VPC. Wire it to your existing egress / DLP / SIEM. Pilot with a handful of users; confirm that the audit and metering data flows where you want it.
  • Week 3 — Roll-out. Migrate or import existing machines, configure organization-level RBAC, and onboard the broader team. We supply a runbook and a Slack Connect channel; most enterprise customers do not need ongoing professional services after this point.

Compliance & certification

  • SOC 2 Type I is in progress for brintOS's SaaS; Type II audit window begins at the end of FY2026. On-prem deployments inherit the controls relevant to brintOS-provided components, plus whatever framework you already operate under.
  • HIPAA, FedRAMP Moderate, FINRA, and EU AI Act conversations are welcome. Because the control plane and storage can both run in your environment, the boundary of what brintOS-as-a-vendor needs to be assessed against is dramatically smaller than for typical SaaS.
  • Data residency is a function of where you deploy. EU customers can run the entire stack in eu-west or eu-central regions; defense customers can deploy into AWS GovCloud or Azure Government with no code changes.
  • Detailed architectural review, threat modelling docs, and shared responsibility matrices are available under NDA — see contact to start the conversation.

Pricing & getting started

Enterprise is priced per seat with usage-based add-ons for storage and bandwidth. There's an annual commitment minimum that scales with the deployment footprint; smaller teams evaluating on-prem are welcome to start on the Team plan and migrate when the requirements harden. To begin the engagement — architecture review, proof-of-value scope, paperwork — write to sales@brintos.io or use the form on the contact page. We'll come back within one business day.