Skip to content
SBfleet

Local control plane for self-hosted Supabase stacks

One control plane.
Independent Supabase stacks.

SBfleet manages independent official self-hosted Supabase stacks on one machine while preserving the original Supabase Studio, official tooling, explicit ownership boundaries, and recoverable local workflows.

upstream stacks · isolated · recoverable

View on GitHubExplore how it works

No daemon · No control database · No custom Studio

sbfleet — illustrative

S B F L E E T

local control plane

upstream stacks · isolated · recoverable

fleet
ready
docker
connected
projects
3
sandbox
available

sbfleet / myapp❯

01 · Why SBfleet

Self-hosted Supabase is simple.
Multiple independent stacks are not.

The official self-hosted stack is naturally project-oriented. Running several long-lived projects on one machine introduces isolation, lifecycle, port, ownership, backup and operator-safety concerns.

SBfleet adds a thin local control plane around official tooling instead of replacing it.

Official stacks

Each long-lived project uses the pinned official self-hosted Supabase stack.

  • No Supabase fork.
  • No custom database platform.

Real isolation

Each project has collision-checked ports and independent resources:

  • Postgres
  • Auth
  • Storage
  • secrets
  • Docker identity
  • ports
  • Studio
  • lifecycle state

Original Studio

SBfleet does not replace Supabase Studio.

Each project keeps the original self-hosted Studio as its visual interface.

02 · Architecture

A thin layer around official tooling.

  • Python CLI
  • filesystem registry
  • advisory locks
  • official self-hosted stacks
  • original Supabase Studio
  • optional nginx integration
  • local-only disposable CLI sandbox

No daemon. No Redis. No Kubernetes. No control-plane database.

03 · Safety model

Designed to refuse uncertainty.

01

Explicit ownership

Destructive operations require positively proven project ownership.

02

Guarded lifecycle

Start, stop, restart, remove, restore and update operate against explicit project authority.

03

Recovery-verified backups

Encrypted cold backups include disposable recovery verification and same-pin restore for the same project and compatible architecture/image set.

04

Local-only sandbox

A separate disposable Supabase CLI sandbox supports local development and automation. It trusts the local operator; same-user filesystem or Docker access can bypass its guards.

04 · Typical workflow

A few explicit commands.

Create, inspect, open Studio and back up a project from the CLI — or work inside the interactive shell with a project in scope.

$ sbfleet create myapp --start --yes 
 
$ sbfleet status myapp 
 
$ sbfleet studio myapp 
 
$ sbfleet backup myapp --identity ~/.config/sbfleet/backup.agekey

05 · Two modes

Long-lived and disposable, kept apart.

mode · project

Long-lived projects

For persistent local/self-hosted Supabase projects.

  • Official Docker stack
  • persistent database
  • secrets
  • Studio
  • backup / restore
  • explicit updates

mode · sandbox

Disposable sandbox

For local app development and agents.

  • Official Supabase CLI
  • local-only target
  • safe reset/destroy boundary
  • automation-friendly
  • no Supabase Cloud account required for normal local workflow

06 · Screenshots

In the terminal and in Studio.

SBfleet screenshot: Terminal home

Terminal home

Interactive shell with fleet summary and short product lockup.

SBfleet screenshot: Multi-project status

Multi-project status

Two independent stacks, one active project prompt.

SBfleet screenshot: Original upstream Studio

Original upstream Studio

SBfleet launches the upstream Studio for each managed project.

Studio is an upstream third-party interface and is not developed by SBfleet.

SBfleet screenshot: Disposable sandbox

Disposable sandbox

Official CLI sandbox for a local app directory, separate from fleet projects.

07 · V1 status

current status

SBfleet v1.1.1 · Current public release

SBfleet v1.1.1 refines the read-only fleet dashboard with focused project navigation, clearer recovery attention and responsive layouts. The v1.1 JSON, local MCP, verified cloning and schema planning capabilities remain shipped. Fleet and recovery semantics are unchanged; migration planning does not execute SQL.

Recovery is bounded to supported same-pin restores. Keep off-host backups and recovery identities, and validate your recovery procedure before entrusting important data.

Read v1.1.1 release notes

Fleet control

Fleet control, without hiding the official stack.

Navigate your projects in one read-only fleet overview. A focused workspace brings project health, recovery attention, connections and service inspection into view.

  • Read-only by design
  • Live project/service health
  • Works alongside JSON and local MCP
SBfleet dashboard with healthy and stopped projects, a persistent project rail, focused workspace, recovery attention, connections and keyboard controls.
v1.1.1 · Sanitized fixture using the production dashboard renderer, 120 × 40.Example observations. Open the image for full-size detail.

Get started

Install on your Linux host.

Requirements: Linux, Docker Engine and Python 3.10+.

User installation
git clone https://github.com/Pepinko81/sbfleet.git
cd sbfleet
export PATH="$HOME/.local/bin:$PATH"
bash scripts/install-user.sh

Read the installation guide

Product roadmap

Built locally. Expanding carefully.

v1.1.1 is the current release. Foundation and v1.1 are shipped. Next and Later describe future direction.

  1. Shipped · v1.0.x

    Foundation

    • Isolated stacks
    • Studio per project
    • Encrypted backup and verified recovery
    • Disposable agent sandbox

  2. Shipped · Current v1.1.1

    v1.1

    • Fleet dashboard
    • Machine-readable JSON
    • Local read-only MCP
    • Verified same-pin cloning
    • Schema diff
    • Migration planning (read-only)

  3. Future direction

    Next

    • Scheduled backups
    • Retention policies
    • Fleet-wide operations
    • Health and backup notifications

  4. Longer-term direction

    Later

    • Richer local control-plane UI
    • Guarded migration execution
    • Project/environment templates
    • Staging workflows

Roadmap reflects current direction and may change; it is not a delivery commitment.

08 · Open source

Built in the open.

SBfleet is designed as a small, inspectable control plane around official Supabase tooling.

Its architecture, safety boundaries, command reference and verification evidence live alongside the source.

View source on GitHub

Python 3.10+ · Linux · Docker Compose

09 · FAQ

Questions.

Is SBfleet an official Supabase product?

No. SBfleet is an independent open-source project and is not affiliated with, sponsored by, or endorsed by Supabase.

Does SBfleet replace Supabase Studio?

No. Each long-lived project keeps the original self-hosted Supabase Studio.

Does SBfleet use Supabase Cloud?

Normal long-lived local stacks and disposable sandbox workflows are designed around local self-hosted tooling. SBfleet is not a Supabase Cloud management product.

Is SBfleet production-ready?

SBfleet v1.1.1 is the current public release, with installation and upgrade validation complete. It supports one Linux host with local Docker Engine. Recovery uses a bounded same-pin restore contract; validate your recovery procedure before relying on it for important data.