Cloud and sync

ORG-2 is a local-first desktop app: it runs, stores, and replays agent sessions on your machine with no account and no backend. Sync exists so a team can see each other's work, so it is opt-in, per-workspace, and layered on top of the local store rather than replacing it. This page covers the three backends, how signing in works, what each plan unlocks, and what happens when you switch.

The three backends

The desktop app is open source under AGPL-3.0-or-later, and the local-only and self-hosted paths are part of that tree. Neither expires nor phones home for a licence check.

Local-only

This is what you get on first launch. Sessions, replay events, projects, work items, and your provider API keys live under ~/.orgii/ — sessions.db for session history, projects/projects.db for projects and work items, credentials.json for keys. No sign-in, no org, no outbound sync, and everything in Sessions and Replay works without a backend.

Self-hosted Supabase

To let teammates see each other's sessions while keeping data on infrastructure you own, point ORG-2 at your own Supabase project. You need its Supabase Project URL and anon key, both under Project Settings → API in the Supabase dashboard.

1. In the collaboration panel choose Add ORG.
2. Set Org source to Supabase Sync (the alternative, Local, creates an org that never syncs).
3. Paste the Supabase Project URL and Supabase anon key, and name the org.
4. Open Setup mode → How to set up Supabase Sync. Use Copy setup SQL, then Open Supabase SQL Editor, paste, and run it.
5. Press Verify setup. You want Supabase setup verified; Supabase setup is missing means the SQL has not been applied yet.

The setup SQL is generated by the app, so it always matches your version. It creates the org, member, invite, project, work-item, session-metadata, chat and snapshot tables, enables row-level security on every one, creates a storage bucket for snapshots, and grants only the stored procedures the client needs. It touches nothing else in your project.

To add teammates, create an invite and send the link. It goes into their Invite link or code field, which accepts a pasted orgii:// link or the bare code; they pick a name under Join as and whether their identity is Human or Agent.

Note: Access here is gated by the invite and an org secret held by members, not by a per-user identity provider. Treat the project as shared team infrastructure and give the anon key only to people you would give the org to.

ORG-2 Cloud

ORG-2 Cloud is the managed option — we run the database, storage, invites, and plan limits, and you run no SQL.

Signing in from the desktop app

Sign-in is a magic-link round trip through your browser, so no password is typed into the desktop app:

1. Start the ORG-2 Cloud sign-in from the app. It opens the hosted login page in your default browser and tells it which desktop callback to return to.
2. Enter your email; the page emails you a magic link.
3. Click the link. The browser completes the exchange in that same tab, so the code verifier never leaves your machine.
4. The page hands the session to the desktop app over the orgii:// deep link, with tokens in the URL fragment only — they never reach a web server or its logs.
5. The app stores the session and loads your cloud profile.

Only a fixed set of desktop callbacks is accepted, so an arbitrary redirect target is rejected. New accounts get a personal workspace org automatically.

What syncs, and what never leaves your machine

Sharing is off until you turn it on. Session access offers three modes per org:

On top of the mode there is an Allowed workspaces list — nothing is shared until you select at least one path, so enabling a mode alone publishes nothing. Full replay is request-and-approve: a teammate asks, you approve or deny. The app warns first, because a replay can include prompts, model outputs, tool calls, and file paths.

What goes up when sharing is on: session cards (title, owner, identity kind, status, repo path, branch, last activity, access mode), projects, work items, group chat, membership and invites, and — only for approved requests — the session event snapshot.

What never syncs, in any mode, on any backend: your provider API keys, which stay in ~/.orgii/credentials.json; your repository contents, since ORG-2 syncs the record of what an agent did rather than your source tree; and your local settings, caches, and session database.

Plans and what each unlocks

Plans are an entitlement catalog rather than a feature checklist. The only resource-count caps today are maxOrgMembers (on paid plans, your purchased seat count) and maxRepoScopes. Session count, monthly replay-upload bytes, and stored replay bytes are unmetered by default; the service still records usage for operations. Other entitlement dimensions include repoScopeCooldownDays (how long a removed repo slot stays occupied, so scopes cannot be rotated to dodge the cap), replayRetentionDays (a read-time visibility window), realtimePresenceEnabled, auditLogRetentionDays, and graceDays after a subscription lapses.

Session sync, metadata sync, replay sync, share links, directed sharing, and forking a shared session are on every tier including free.

Enterprise is assigned manually rather than through self-serve checkout.

Quotas and what happens when you hit one

Member and repository-scope quotas are enforced at write time in the database, not by the client. Crossing one rejects that write with a specific reason — a member cap when accepting an invite or a repo-scope cap when saving scoped repositories. Session count, monthly replay uploads, and stored replay bytes have no default product cap. Nothing already stored is deleted, and the desktop app keeps working locally.

Retention is a window, not a delete: replayRetentionDays filters what reads return, so data outlives the window, upgrading instantly restores visibility of older sessions, and downgrading only narrows what you can read. Repo scopes have a cooldown: a removed repo keeps its slot for the cooldown period and both active and cooling scopes count against the cap, though you can always shrink your list or re-save it unchanged even while over the cap.

Switching backends and moving data

Because the local store is always the source of truth, switching is additive rather than destructive.

• Local → synced. Create or join an org, set Session access, pick Allowed workspaces. Those sessions appear to teammates on the next sync pass.
• Synced → local. Set Session access to Off, or remove the org. Local sessions and replay are untouched; sharing simply stops.
• Self-hosted ↔ ORG-2 Cloud. Separate orgs, not a migration path. Add the new one alongside the old and re-point your workspaces. History already pushed stays where it was; your local copy is unaffected.

Offline behaviour

Everything that matters works offline: agents run, sessions record, replay plays back, projects and work items update, all against the local databases.

When a backend is unreachable, that org's connection is marked errored and shown as Offline in the collaboration panel. It retries on the next pass — roughly every ten seconds — and reconciles when the backend returns. To guarantee no non-essential outbound traffic at all, including diagnostics, set privacy.offlineMode to true in ~/.orgii/settings.jsonc; see Security and privacy.

Enterprise and self-managed deployments

The enterprise path covers self-deploying against your own Supabase and object storage inside your own VPC, or a managed deployment priced to your seat count. It is the usual route for teams running a security or compliance review, or consolidating several agent tools into one record. Because the app is open source, your security team can read it first. Reach us through the form on org2.ai or at enterprise@org2.ai.

Next steps

• Security and privacy — where credentials live and what is transmitted.
• Collaboration — invites, roles, and reviewing a teammate's session.
• Orgs — how orgs, members, and repo scopes fit together.
• Replay — what a snapshot contains before you share one.