Shared SaaS mode

Required production baseline

Set the following values in App/config.ts. Use independently generated secrets; do not copy the examples into production.

security: {
  multiTenant: true,
  encryptionSecret: "<independent 32+ character random secret>",
  previousEncryptionSecrets: [],
  secureCookies: "auto",
  sessionMaxAgeDays: 7,
  trustedProxyHops: 1,
  outboundPrivateHostAllowlist: [],
  outboundRequestTimeoutMs: 15_000,
  outboundMaxResponseBytes: 25 * 1024 * 1024,
  authRateLimit: { windowMinutes: 15, maxAttempts: 10, blockMinutes: 15 },
  bootstrapMasterAdminEmail: "operator@example.com",
},
agent: {
  codingTools: {
    enabled: true,
    executionMode: "bubblewrap",
    bubblewrapPath: "/usr/bin/bwrap",
    allowNetwork: false,
  },
  browserEnabledInMultiTenant: false,
  maxConcurrentRunsPerCompany: 4,
},
db: {
  driver: "postgres",
  sqlitePath: "",
  postgresUrl: "postgresql://…",
},
sessionSecret: "<different 32+ character random secret>",

A working global SMTP transport is also mandatory because new Members must verify their email and account recovery must reach a mailbox. Configure Admin → Email transport or the smtp block before enabling shared SaaS mode.

On the first operator sign-in, Genosyn detects the same-origin browser URL. Review and save the canonical HTTPS origin at Admin → General before configuring SSO, WebAuthn, or OAuth integrations. It is stored in Postgres and propagated across replicas.

What startup checks

• Postgres is selected and has a connection URL.
• Session cookies are Secure.
• The session-signing and encryption secrets are strong and different.
• The Bubblewrap binary exists, shell networking is off, and the shared browser is off.
• No private outbound hostname exception is configured.
• A bootstrap operator email and system SMTP transport are configured.

If any check fails, Genosyn exits with the exact unsafe setting instead of silently starting in a partial posture.

Tenant and identity boundaries

Company scope

Every customer resource is selected through a verified Membership and company id. API keys are bound to one company.

Roles

Members can collaborate; owner/admin roles control sensitive configuration. Owners promote, demote, and remove Members in Settings. Removal revokes company API keys and clears private Channel and Project membership.

Email ownership

Hosted Members verify a single-use, hashed email token before creating a company or accepting an invitation. The signed-in email must match the invitation.

Two factor

A company owner or admin can require 2FA for every Member. Genosyn prevents a Member from removing their final method while any company requires it.

Sessions

Password changes and resets increment a server-side session version, invalidating every older signed cookie across replicas.

AI execution isolation

Each AI employee's shell runs inside a Bubblewrap user, mount, PID, IPC, UTS, cgroup, and network namespace. Only that employee's workspace is writable; the API process environment is not inherited. File tools resolve real paths and reject symlink escapes. The hosted runtime also serializes work per AI employee and caps concurrent AI work per company.

• Company secrets are not injected into hosted coding shells.
• Arbitrary stdio MCP servers are not started in shared SaaS mode.
• The app-owned Chromium browser is unavailable until it moves to a separately isolated browser worker. See Browser for self-hosted mode.

Outbound network policy

URL ingestion, Pipeline HTTP nodes, AI Model endpoints, MCP endpoints, and configurable Connection hosts reject loopback, private, link-local, carrier-grade NAT, documentation, multicast, and reserved addresses. Every redirect is rechecked, responses are bounded, and DNS is checked again at socket connection time to stop rebinding attacks. Keep a cloud egress firewall that blocks metadata and private ranges as defense in depth.

Raw-TCP Postgres, MySQL, and Redis Connections and arbitrary Code Repository remotes are disabled in shared SaaS mode until they can run in a dedicated egress worker. Fixed-host GitHub checkouts remain available through a granted GitHub Connection.

Running more than one replica

Postgres stores OAuth/OIDC/WebSocket handshake state, scheduler leases, workload leases, and short-lived realtime fan-out records. Recurring work elects one replica, pending mail handovers are claimed atomically, Telegram listeners fail over, and PostgresLISTEN/NOTIFY carries authorized WebSocket events between replicas.

• Mount the same dataDir on every replica with ReadWriteMany storage. Uploaded files and employee working trees still live there.
• Use one migration job or allow the first replica to apply migrations before rollout.
• Forward WebSocket upgrades and preserve the original HTTPS origin at the ingress.
• Use a managed Postgres backup and back up the shared data volume separately. Genosyn's built-in SQLite archive and restore surface is disabled in shared SaaS mode.

Launch checklist

1. Start with an empty Postgres database and let the Postgres migration stream apply.
2. Configure HTTPS, trusted proxy hops, strong secrets, SMTP, and the bootstrap email.
3. Run the container with Bubblewrap/user namespaces available and shell network disabled.
4. Create the operator account using the exact bootstrap email, then verify it.
5. Test signup, verification, password reset, invitation matching, role denial, and 2FA.
6. Test two concurrent companies and at least two replicas against shared storage.
7. Keep database, volume, ingress, SMTP, and model-provider monitoring outside the app.