Local-first.

Orchid keeps your data, your credentials, and your code on your machine.

What lives where

Two columns. The left column is yours and never leaves unless you make it leave. The right column is the minimum we need a server for.

Two-column comparison. Left column 'On your machine': project folder, .orchid files, outputs, virtualenv, kernel processes, OS keychain credentials, query results. Right column 'In the cloud': your account, agent prompts (per-call), published snapshots (when you publish)./docs-images/concepts/local-vs-cloud.png
By default, everything sits on the left. The right column only fills in when you sign in, prompt an agent, or hit Publish.

On your machine

  • Project folders. A project is a real folder somewhere on your disk. You pick where. Orchid creates a few files inside; everything else is yours.
  • Notebooks and outputs. Each .orchid file holds your cells. Outputs serialize with the file so re-opening shows yesterday's results without re-running anything.
  • Credentials. Database passwords, SSH keys, and warehouse tokens live in your OS keychain. The kernel reads them when it needs them; nothing else gets to.
  • Query results. When your kernel runs a SQL query, your machine connects to the database and your machine receives the rows. The Orchid backend is not in the path.
  • Python and packages. Each project has its own virtualenv. pip install writes to your disk, not a remote image.

In the cloud (when you opt in)

  • Your account. Email and auth tokens, handled by Supabase Auth.
  • Agent prompts. When you talk to an agent, the prompt and conversation history go to the model provider (Gemini on the free tier; Anthropic or OpenAI if you bring a key). Responses come back. The kernel still runs locally.
  • Published artifacts. When you hit Publish, a snapshot of the notebook or dashboard — source plus rendered outputs — uploads. Credentials are not part of the snapshot.

Why credentials matter

Most cloud notebooks ask you to hand over a connection string in a settings UI, then store it server-side and rotate it through an encrypted vault you have to trust. That model has a security model attached and a compliance story to maintain.

Orchid's model is simpler: your credentials never leave your machine. The OS keychain holds them, your kernel reads them when it opens a connection, and the server doesn't even know the credentials exist. If a regulated team needs warehouse access scoped per-user, Orchid is the easy answer — every user's warehouse session is them, with their permissions, on their workstation.

Read more

The full security model — keychain integration, read-only-by-default connections, agent action logging — lives in the Security page.

Why latency matters

Cloud notebooks pay a tax on every interaction. Your cell source travels to a kernel, the kernel queries your database (which is somewhere else), the result travels back to the kernel, then to the browser, then renders. Four hops, often across regions, with a warm-up cost if the kernel was idle.

Orchid's hot path is two hops: your IDE to a local kernel, the kernel to your warehouse and back. The IDE-to-kernel hop is a local socket, sub-millisecond. The warehouse hop is the only network distance, and you were going to pay that anyway.

In practice this means three things. Interactive Python feels interactive. SQL preview returns first rows as fast as your warehouse can serve them. And the kernel is never "cold" — a session you opened this morning is the same session you're working in this afternoon.

Why offline matters

On a plane, in a hotel with bad wifi, or behind a corporate VPN that's being moody, the things you care about still work. Open a project, run a notebook against a local SQLite or DuckDB file, write Python, build a chart, save. None of that needs the network.

What stops working when you're offline: agents (we can't reach the model provider), publishing (we can't reach our backend), and sign-in (same). Everything else is a normal day at the desk.

How this differs from cloud notebooks

Hex, Deepnote, and Mode all do good work. They're also cloud-first by architecture, and that means the trade-offs are flipped from Orchid's. Worth being explicit about which side of which trade-off you want.

Setup and onboarding

Cloud notebooks are zero-install — you log in and you're running. Orchid asks you to download a desktop app, which is a real friction. We keep the install small and signed, but it's still a step. In return, the kernel doesn't need an "environment" to be provisioned and your connection setup happens against the network your machine is actually on.

Collaboration shape

Cloud notebooks default to a single shared workspace where everyone sees the same notebook on the same server. Orchid defaults to private local work, with explicit publishing for sharing. Real-time editing works when you opt in. Comments work on published links. The shape is "analyst-first, share when ready" rather than "collaborate by default."

Compute and cost

Cloud notebooks bill for kernel uptime — directly, or hidden inside a seat price. Heavy users pay heavy bills. Orchid runs compute on your laptop, so the bill is for what you actually buy from us: model credits if you want them, free tier if you don't.

Data residency

Cloud notebooks pull your data into their tenant. If you're in a regulated environment, this is the source of a long conversation with your security team. Orchid pulls your data into a process running on your machine — which, in most compliance frameworks, is a category the team has already approved.

Where local-first stops

Local-first is not a religion. When you publish a notebook to a shareable link, that's a cloud-canonical artifact and it's on our server. When you turn on real-time collaboration on a published project, the collaboration session is brokered through our backend. The point isn't to keep everything off the cloud forever; it's to make "leaves your machine" an event you noticed.

Where to read next