Beta contract

B3OS beta is a working product on a small footprint. These are the terms it runs on.

Availability

• Best effort, one site. The beta runs on one node at one site in Eugene, Oregon, without an availability SLA.
• Invite-only. New organizations are admitted by invite code, against capacity B3OS has measured it can serve.
• Status. A status page shows the node and each product.
• When the node is down, the API answers 503 node_unavailable with Retry-After. Inbound webhooks for routines are stored durably at the edge and replayed in order when the node is back.
• Missed schedules. Every cron and interval trigger declares what to do with occurrences missed while the node was down or the routine paused: skip them, run only the latest, or run them all in order. See triggers.

Durability

Routine runs at standard or strict durability, and the stored responses of idempotent requests with effects, are recorded in a journal on the node's disk. They survive process crashes and restarts; they do not survive the loss of the node itself. Usage records reach the disk at least once a second, so a crash can lose the last second of usage.

Choose a routine's durability per run: ephemeral keeps everything in memory, standard makes each effect durable before the steps after it run, and strict records both the intent and the result of every effect step. See routines.

Changes

The API is version 0.1. Breaking changes are announced 14 days ahead with a dated B3OS-Version header. The changelog records every change.

A few operations are in the published contract but planned for later in the beta, so a node may not serve them yet. Until it does, they answer 501 not_implemented, with the alternative in the detail when there is one. They are: vision extraction (/v1/vision/extracts and the Firecrawl extract endpoints), sandbox fork, embeddings, and the inbound webhook URL for pack triggers.

Retention

Some operations let you choose a shorter or longer period per request where it makes sense; the API reference says where.

Isolation

• Tenancy. Every object belongs to one organization and project, and every request is checked against them. An object outside your project answers 404.
• Sandboxes are Firecracker microVMs, each restored with a fresh identity: new entropy, machine ID and clock, so two sandboxes from one snapshot never share random state.
• Browser sessions get their own browser process and profile directory each, and profiles load only into sessions of their own organization. Until the node's AppArmor profile is installed, Chrome runs without its renderer sandbox and every browser in a pool runs as one OS user, so a browser exploit could reach other sessions on that pool. Browser microVMs are planned. The shared scrape pool runs only scrapes B3OS drives; nobody connects to it over CDP.
• Egress. Every outbound request you can steer goes through the egress guard, which refuses loopback, private networks, the node's own addresses and cloud metadata.
• Your bytes on usercontent.b3os.org. Render artifacts and sandbox previews are served from a separate host with no cookies in either direction, and artifacts always carry Content-Security-Policy: sandbox. In v0.1 every port preview shares that one origin, so a page in one preview can send requests to another preview URL it knows. Keep secrets out of previews; per-port hostnames are planned.

Acceptable use

Use of the beta is subject to B3OS's acceptable-use policy. Vision honors robots.txt and Content Signals by default, and a crawl spaces its requests to any one host.