Sign in Sign up

Solutions

For Teams & Organizations

brintOS turns a Linux machine into a versioned, browsable artifact your whole team can build, share, and launch from a URL. Organizations get a real home: shared ownership of machines, role-based access, audit trails, and a place to collaborate that isn't another Slack channel full of zip files.

An org is a first-class object

Create an organization once and every machine, every snapshot, every secret, and every billing line item lives inside it. Members are added by email or SSO domain; ownership transfers atomically; departing teammates can be off-boarded with a single revoke that propagates to every active session. The org is the unit of accounting, the unit of access control, and the unit you point auditors at.

Repositories that boot

Every brintOS repository is a machine. Clone it the way you'd clone a Git repo, branch off, experiment, push back. The diff your teammate reviews isn't just source — it's the rootfs, the kernel config, the attached devices, the boot scripts. When they want to see what your change does, they don't run docker build for ten minutes; they click Launch and boot the exact filesystem your CI tested.

  • Forks & pull requests work the way GitHub trained you to expect. Branches are cheap, merges are reviewable, and machine state at any revision is reproducible byte-for-byte.
  • Snapshots are content-addressable. Two teammates pushing the same rootfs share storage automatically; cold-start storage cost is "what's actually different."
  • Code review on a running machine. Open a PR, your reviewer clicks Launch from the diff page, and they're typing inside the proposed machine in seconds. The comment they leave on a kernel-config line is anchored to that exact line of the spec.

Role-based access, finally simple

Three default roles cover what most teams need; custom roles let you split further when the org grows.

  • Owners control billing, membership, and org-level policy. Owners are the only ones who can delete the org or change its plan.
  • Maintainers create, fork, and configure machines, manage repo permissions, and set per-machine resource caps.
  • Members launch and contribute to machines they have access to. Per-repo read/write/admin grants let you give a contractor a narrow slice without seeing the rest of the org.

Permission grants are evaluated server-side at session start and re-checked on every privileged operation. Revocations take effect immediately — there is no in-tab cache of "you were allowed five minutes ago" because there is no in-tab privileged operation we'd have to cache.

Collaboration that doesn't leak

The whole point of running machines in the browser is that the code stays where it started. Your team can collaborate on a kernel, a vendor toolchain, or a regulated workflow without any of it ever existing on a server we operate. brintOS's control plane stores rootfs snapshots (encrypted at rest), repository metadata, and access decisions — it never executes your code. That's not a feature flag; it's the architecture.

  • Live sessions are local. When a teammate launches a machine, their CPU runs it. We don't have a shared compute cluster that "schedules" your workloads; there isn't one.
  • Shared overlays for pairing. Two engineers can attach to the same running machine over a peer connection — brintOS negotiates the handshake, the bytes flow between their tabs. The pairing session never touches our servers.
  • Forks are private by default. A teammate exploring a sensitive rootfs gets their own fork, scoped to their identity, that auto-expires unless they pin it.

Hosting for your users, on your terms

Organizations on Pro and above can publish machines to Hosting / Self-Hosting — a stable URL your customers or students open in a browser tab. You decide who's allowed in (email allowlist, OIDC SSO, magic link, signed token), what they can do (read-only, per-visitor overlay, full read-write), and how much they're allowed to use (concurrent sessions, bandwidth, compute time).

Common org-shaped uses we built this for:

  • Internal tools that need a Linux. Ship the calibration rig, the board-bring-up suite, the customer-on-site debugger as a URL. Your support engineers click a link and they're in the machine you maintain.
  • Customer demos and trials. Curate a rootfs per prospect, gate it by their work email domain, hand them a link with a 30-minute session timeout. No "trial environment" to keep alive between sales calls.
  • Classrooms and bootcamps. Per-student persistent overlays on a single shared base image; instructor read-only access to any session; per-cohort resource caps.

Single sign-on and identity

  • OIDC SSO via your identity provider (Okta, Microsoft Entra, Google Workspace). User provisioning happens just-in-time on first sign-in; SCIM is on the roadmap.
  • Email-domain allowlists give every employee of @yourco.com a Member seat the moment they sign up, with no admin click required.
  • Audit trail records every membership change, permission flip, and machine-access decision with timestamp and identity. Pipe the stream to your SIEM via webhook.

Billing that respects how teams actually work

Per-seat pricing covers your members; storage and outbound bandwidth meter on top, with the org as the billing entity. Owners see one Stripe-backed invoice per month, an itemized usage view, and a self-serve plan-change flow that doesn't require a sales call. Pay annually for a discount, or month-to-month if you'd rather not commit. See pricing for the current tiers.

Ready to set one up?

Create an organization — it takes a minute and your first five seats are free on the Team plan. Need to move a private repo into the org, migrate a fleet of machines, or talk through SSO before you commit? Drop us a note and we'll help. Teams that need an on-prem control plane should see Enterprise & on-prem for the deployment model designed around your VPC.