Publishing.

Projects start local. When you publish, that machine's copy becomes the cloud-canonical version — first publisher wins, everyone else syncs down.

Local-first by default

Every project lives in a directory on your machine. Notebooks, dashboards, assets, the bundled venv — all on disk, all yours. Nothing leaves your machine until you decide to publish.

Multiple machines? Same model. Each install holds its own local copy of every project. You can have a project open on your laptop and your desktop with no syncing — they're just separate copies until one of them publishes.

Diagram showing two local machines, with one publishing to the cloud and the other syncing down on next open./docs-images/collaboration/publish-flow.png
One machine publishes. Others sync down on open.

What publishing does

Click Publish (top-right of any notebook or dashboard). Orchid uploads the current state — cell sources, saved outputs, assets, dashboard layouts — to the cloud and assigns it a canonical URL at <slug>.orchidide.com.

That cloud copy is now the source of truth for the project. Specifically:

  • Other collaborators who open the project sync from the cloud, not from their own local copy.
  • Real-time editing flows through the cloud — see Real-time editing.
  • Comments, presence, and the action log all live cloud-side.
  • Public viewers see the published snapshot at the share URL.
# Local-only project
~/Projects/q1-review/      ← lives on disk, no cloud copy

# After publishing
~/Projects/q1-review/      ← still on disk, now synced
                          ←   with q1-review.orchidide.com

First publisher wins

If two collaborators have local-only copies of the same project (say, by both starting from a template), whoever publishes first claims the cloud row. The second person's local copy stays — they can open it, but it's now a separate project from the cloud canonical version.

To merge two pre-publish copies, do it by hand: export one as files, copy the relevant cells into the other, publish the merged version. The export-as-HTML option helps here for one-off contributions.

Note

This rule keeps the publish flow predictable. There's never ambiguity about which cloud row is canonical — it's the one that exists.

Visibility modes

Pick one when you publish, change anytime from the share menu:

  • Public — anyone with the URL can view. Listed on your public profile.
  • Link-only — anyone with the URL can view. The URL contains a random secret.
  • Team — viewers must be signed in and on your team.

Editors are a separate axis from viewers — see Permissions.

The share viewer

At <slug>.orchidide.com, viewers see a read-only render of your notebook or dashboard. Cells run their saved output (not their kernel) and charts stay interactive. The viewer respects filters on dashboards — viewers can change them, and the URL updates with the filter state.

Public viewers don't see comments, the action log, or who's currently editing. Logged-in collaborators see the full collaboration UI.

Unpublishing & archiving

Unpublish stops the cloud copy from serving — the URL 404s, link secrets revoke. Your local copy is untouched, and you can re-publish later. Re-publishing gets a fresh secret for link-only visibility.

Archive goes further: removes the cloud copy from your projects list without deleting it. Restore from Archived in the projects sidebar.

Heads up

Connection credentials never publish. The cloud copy stores connection profile names (e.g. "warehouse") but not hosts, users, or passwords. Each collaborator configures their own; refresh schedules use credentials you supply separately.

Up next: Permissions. Back to the Collaboration overview.