# Launch readiness and security caveats > What Flax Cloud currently enforces, what is still a launch caveat, and what should be fixed before broader public or enterprise use. Flax Cloud is ready for a controlled developer launch where users sign in, create sandboxes, run code, use browser/CDP sessions, open previews, and pay for plan headroom. It is not yet positioned as an enterprise compliance product or a high-abuse public compute utility. This page states the current security and reliability posture clearly so builders know what to expect. ## Currently enforced - **Authentication.** Dashboard users sign in through WorkOS. Dashboard sessions use httpOnly cookies with server-side session records. - **API keys.** Programmatic access uses `flax_live_...` API keys. Full keys are shown once and stored only as SHA-256 hashes. Revoked keys stop working immediately. - **Per-account ownership.** API requests resolve to one user. Users can only see and modify their own sandboxes, commands, files, sessions, snapshots, templates, preview links, browser sessions, API keys, billing, and usage. - **Sandbox lifecycle controls.** Sandboxes can be created, stopped, resumed, forked, snapshotted, and destroyed. Destroy is permanent. Idle cleanup and retention policies reclaim stale resources. - **Plan quotas.** Plans enforce concurrent sandboxes, active runtime minutes, daily sandbox creation limits, storage, custom templates, Dockerfile builds, and image size limits. - **Memory limits.** Requested sandbox memory is rejected with `402 memory_limit` when it exceeds the plan ceiling: Free `1 GB`, Pro `2 GB`, Builder `4 GB`, Team `8 GB`. - **Capacity admission.** The scheduler checks worker capacity before placement and returns `503 capacity_unavailable` when the fleet is full instead of over-subscribing hosts. - **gVisor sandbox hardening.** Runtime containers run with gVisor, dropped Linux capabilities, `no-new-privileges`, process caps, CPU and memory caps, and an isolated workspace. - **Browser CDP URLs.** Browser connection URLs are short-lived secrets scoped to the sandbox owner. Treat them like temporary credentials. - **Preview link controls.** Shareable preview links use long random tokens, store only token hashes, can be rotated or disabled, and stop serving when the sandbox is not live. - **Operational visibility.** Production has Sentry, an external `/health` check, backups, host monitor timers, and production launch smoke coverage. - **Billing lifecycle safety.** Stripe Checkout and the Customer Portal keep card data out of Flax. Signed webhooks are deduplicated, current subscription state is reconciled from Stripe, duplicate subscriptions are blocked, and failed payments are surfaced without immediately removing access. ## Current launch caveats - **Isolation is strong, not a formal security boundary guarantee.** gVisor improves isolation compared with plain Docker, but this is still a shared-host sandbox product. Do not market it as enterprise-grade confidential compute or formally verified isolation. - **Abuse prevention is early.** There are quotas, signup checks, SMTP/private-network egress blocks, account suspension (a per-user kill switch that also reclaims live containers), and a resource-abuse anomaly monitor that flags rapid sandbox churn or one tenant hogging the fleet. It still needs IP/reputation scoring and richer automated detection before broad self-serve scale. - **Outbound network controls are not yet granular.** Sandboxes can run with `network_mode: "none"` or default outbound internet access. Per-domain allowlists, deny lists, and tenant-level network policies are not shipped yet. - **Secret scoping is coarse.** Sandbox env vars are injected at sandbox or command scope, but there is no dedicated secrets vault with per-sandbox grants, audit history, or automatic redaction. - **Rate limits are basic.** API rate limiting exists, but endpoint-specific and behavior-based limits should be expanded as public traffic grows. - **Audit logs are not detailed enough for enterprise.** Access and preview events are logged, but there is no user-facing immutable audit log for every key, file, command, browser, or billing action. - **Single-region operation.** The current fleet runs in one region. Worker scheduling is multi-host, but region failover and host-level redundancy are not yet launch-grade. - **Capacity is intentionally small.** Recent load tests verified graceful burst handling to 150 concurrent create attempts, but steady-state capacity is still limited by worker RAM. - **Compliance is not claimed.** No SOC 2, HIPAA, PCI, GDPR DPA workflow, enterprise SSO/SAML management, or formal pen-test report is available yet. ## Top launch blockers and fixes | Priority | Blocker | Recommended fix | |----------|---------|-----------------| | Done | Stripe live billing is configured and verified. | Live catalog, portal, signed webhook, lifecycle checks, replay deduplication, and production smoke passed on 2026-07-21. Add the public support email in Stripe before broad launch. | | Done | Operator alerts are wired to Discord. | `ALERT_WEBHOOK_URL` receives host-monitor and abuse-anomaly notifications. | | High | Capacity is enough for a controlled tutorial launch, but not a viral launch. | Add a larger worker or a third worker before broader promotion. Re-run `infra/scripts/loadtest.py` afterward. | | Medium | Legal pages are drafted but not lawyer-reviewed. | Review ToS, Privacy, Acceptable Use, refund wording, and deletion/export language before paid launch. | | Done | Browser/CDP concurrency is validated. | `infra/scripts/browser_loadtest.py` runs concurrent browser lifecycles (create, start, goto, screenshot, mint + connect CDP). Verified to fleet saturation: full lifecycles plus clean capacity 503s, no worker over-subscription. | | Later | Abuse tooling covers the basics; reputation is not automated. | Admin dashboard, per-user kill switch, resource anomaly alerts, and disposable-email signup blocks now ship. Still add IP/reputation scoring and per-user rate anomaly baselines. | | Later | Enterprise assurance is not ready. | Add audit logs, scoped secrets, SSO/team roles, network policies, compliance docs, and a pen-test before enterprise marketing. | ## Recommended launch position Use precise language: - Good: "gVisor-hardened cloud sandboxes for developers and agents." - Good: "Short-lived browser CDP URLs and revocable preview links." - Good: "Plan-limited memory, storage, runtime, and concurrency." - Avoid: "Fully secure against all untrusted code." - Avoid: "Enterprise compliant." - Avoid: "Unlimited free compute." For a tutorial-driven launch, keep the beta gate or invite flow until Stripe is live, alerts are wired, and the first few paying users have completed the full onboarding path successfully.