Running Supabase Locally Without Docker in 2026: 3 Options Compared

Running Supabase Locally Without Docker in 2026: 3 Options Compared

# supabase# postgres# webdev# javascript
Running Supabase Locally Without Docker in 2026: 3 Options ComparedMark F A

supabase start needs Docker. Here's what that costs, and the alternatives: a hand-wired native stack, or a single-process Supabase-compatible backend.

TL;DR

  • supabase start runs the local stack in Docker containers. It's the most complete option, and the heaviest.
  • You can wire Postgres, PostgREST and auth together natively, but then you own the orchestration.
  • Single-process, Supabase-compatible backends now exist. They keep supabase-js unchanged but cover a subset of features.
  • Pick based on which Supabase features your app actually uses.

Option 1: The Supabase CLI (Docker)

This is the official path. supabase start boots Postgres, auth, the REST API, realtime, storage, Studio and supporting services as containers.

It's the closest match to hosted Supabase, which is its biggest strength. The cost is resources. In a benchmark published on Apple Silicon (macOS 15), the Docker stack is described as 12 containers, about 2.3 GB installed, and around 1.6 GB of memory. On a 32 GB workstation you won't notice. On a 16 GB laptop running an editor, a browser and a simulator, you will.

Choose it when: you use storage image transforms, MFA, SSO, phone auth, or anything recently shipped on hosted Supabase.

Option 2: Wire it up natively

Every core piece is open source and runs outside Docker: Postgres from Homebrew or your package manager, PostgREST for the REST API, and the auth server.

brew install postgresql@17
brew services start postgresql@17
# then run PostgREST and the auth server as separate processes,
# each with its own config pointing at your database
Enter fullscreen mode Exit fullscreen mode

It's light on resources, but you now own the setup: configs, versions, process management and keeping them in sync with what supabase-js expects.

Choose it when: you only need one or two pieces (often just Postgres + PostgREST) and like owning the stack.

Option 3: A single-process, Supabase-compatible backend

The newer option bundles the API surface into one process. I work on Tinbase, which is one of these, so take this section with that in mind.

npx tinbase start
Enter fullscreen mode Exit fullscreen mode

It prints the API URL (http://127.0.0.1:54321) and the anon and service_role keys, then you point the normal client at it:

import { createClient } from '@supabase/supabase-js';

const supabase = createClient('http://127.0.0.1:54321', ANON_KEY);
Enter fullscreen mode Exit fullscreen mode

What carries over:

  • supabase/migrations/*.sql and supabase/seed.sql are applied on start
  • RLS policies run with JWT claims, so auth.uid() behaves as on hosted Supabase
  • REST, auth (email/password, anonymous, magic links, OAuth), storage, realtime, edge functions, cron
  • A Studio dashboard at /_/ and tinbase gen types typescript for typed clients

What it doesn't do (from its README): MFA, SSO/SAML or phone auth; image transformations or resumable uploads; aggregates in select. It handles one connection at a time and is labelled alpha, not production-ready. It's a local-dev and prototyping tool, not a hosting replacement.

Its benchmark lists about a 2-second start and a memory footprint in the tens of MB with the default embedded Postgres 17 engine.

Choose it when: you use the core Supabase APIs, want a fast cold start, and deploy to hosted Supabase anyway.

Quick comparison

Supabase CLI (Docker) Native, hand-wired Single-process (e.g. Tinbase)
Setup One command Several services One command
Footprint Heaviest Light Light
Feature coverage Full What you wire up Core APIs, documented gaps
Maintenance Low High Low
Production use Local only Your call Not production-ready

How to decide

  1. List the Supabase features your app calls. Check them against the gaps above.
  2. If everything is covered, try the lighter option on a branch and run your test suite against it.
  3. Keep the Docker stack around for the features that need it. Both can read the same supabase/ folder.

Which Supabase feature is the one keeping you on Docker locally?