Choosing a work mode: browser-local, Gesso account, or self-hosted

Three modes, one document

Gesso is local-first in every mode. The document, its history, and its recovery path never depend on an account or a network. What the three modes differ on is where a second copy lives, and who is responsible for it.

Pick the smallest mode that fits the job. Moving up later is a decision you can make with the same document in front of you. Moving back down is harder, because by then other people are depending on the thing you'd be switching off.

Mode 1 — Browser-local

Open Gesso and work in the browser without an account. Documents and imported assets stay in that browser until you export them or clear its site data.

This is the right mode for a one-off asset, a pitch that may never happen, a client whose files you'd rather not be holding, or your first hour with the app. It's also the only mode that sends nothing anywhere, which is a genuinely useful thing to be able to tell a nervous client.

The trade is durability. "In this browser" means one browser profile on one device, and browsers reclaim storage when they feel like it. Two habits cover you:

1. Export finished work rather than leaving it as the only copy.
2. Watch the save indicator. Gesso builds it from storage facts, not from your account status. A document reads as session-only until durable storage is actually proven, and saved locally only after a durable write succeeds. failed locally and storage full are separate states, and both mean stop and deal with it now.

Mode 2 — A Gesso account

Account mode is a configuration, not something you can go buy. It exists in builds that have been set up for it, like an installation your organization or a partner runs. There's no public Gesso service to sign up for, so if nobody has handed you an installation, this mode isn't available to you today.

In a build that has it, signing in means the app saves locally first, then syncs signed document changes, recovers private Asset Library files, and enables comments, invitations, and people management.

Read that order carefully, because it's the whole design. Local first, then sync. The account isn't where the document lives. It's a second home for signed changes, plus the identity layer that makes "invite Kai to comment" mean something.

Reach for this mode when more than one person touches the file, when the Asset Library needs to survive a device, or when review has to happen somewhere other than an email thread.

One caveat, stated plainly. A deployed host still needs its own two-account, email, Realtime, and Storage acceptance run, and that run has not been completed. A feature being available in a build is not proof that a particular deployment is ready for your team.

Mode 3 — Self-hosted platform

Deploy the configurable platform with your own Supabase project and web host. You control the data plane, storage, authentication, email, and collaboration operations, and you take on the work and cost of running them.

Choose this when the boundary is written down somewhere: a client contract that names where data rests, a sector rule that won't accept a third-party host, an internal policy about identity. Don't choose it for privacy in the abstract. Browser-local is already the mode that sends nothing. Self-hosting is about administering data you've already decided to share.

Budget for the operations, not the setup. Your team owns hosting and updates, two private storage buckets with their backups and restore rehearsals, Resend email with SPF/DKIM/DMARC, and membership, revocation, reconnects, and incident response. Every one of those grows with the number of people and workspaces you add.

The operator guide has the migrations, Edge Function deploys, environment boundaries, and the acceptance run to complete before inviting a team. It's written for whoever runs your servers.

How to move up without a bad week

1. Start browser-local and stay there until a second person needs to see the file.
2. When you invite someone, move to an account-backed build rather than straight to self-hosting. Find out what collaboration costs you in review time before you also own the database.
3. If a contract or policy later requires your own infrastructure, do the self-host setup on a staging project and run the acceptance checks with two real accounts.
4. Only after that run passes, invite the team onto the host you operate.
5. Keep exporting. In every mode, an exported deliverable is the copy that doesn't depend on anyone's uptime.

The part that doesn't change

In all three modes the local project stays editable and recoverable without an account or a network. Hosting never becomes a requirement of editing. So the choice in front of you is really about operations and who answers for them, and you can make it once the work is already underway rather than before you've started.