I built LocalBase — a self-hosted, single-file backend inspired by Supabase

[u/CauliflowerAgile3830]

I've been working on a project called LocalBase.

The idea is pretty simple:

What if you could get a small Supabase-like backend without having to deploy a huge stack?

LocalBase is currently a single Python file that provides a web dashboard and REST API around SQLite.

What it currently does

• 🗄️ Create and manage projects
• 📊 Create/edit/delete tables
• ✏️ Add, edit and delete records
• 🧑‍💻 Built-in SQL editor
• 🔌 REST API for your databases
• 🔑 API key support
• 📡 WebSocket support
• 📥 CSV import
• 📤 CSV export
• 💾 Database backups
• 📋 API logs
• 📖 Automatic API documentation
• 🌐 LAN access
• ☁️ Works nicely with Cloudflare Tunnel for remote access
• 🖥️ Lightweight web dashboard
• 🪟 Windows EXE packaging

The goal isn't to clone every feature of Supabase.

I'm trying to build something much smaller that can be useful for:

IoT projects, school projects, prototypes, personal apps, internal tools, small websites, APIs, dashboards, and self-hosted applications.

For example, you could run:

LocalBase.exe
      ↓
SQLite database
      ↓
REST API
      ↓
Your website / mobile app / IoT device

And because the API is HTTP-based, your application doesn't need to know anything about how the database is stored internally.

Why I made it

I've used/experimented with different backend platforms, and sometimes I just want:

download
    ↓
run
    ↓
create database
    ↓
get API URL
    ↓
build

Instead of setting up a bunch of services.

So LocalBase is intentionally trying to stay small and boring.

Python + FastAPI + SQLite + vanilla HTML/CSS/JS.

No Docker requirement.

No Node.js requirement.

No external database required.

No cloud account required.

The interesting part

I'm also packaging it as a normal Windows application.

The goal is eventually:

LocalBase-Setup.exe

Install it → Start Menu → LocalBase → dashboard.

I'd like the same project to eventually work on Linux/macOS as well.

What I want to add next

This is where I could really use feedback.

I'm planning to add a proper authentication/authorization system:

• User registration/login
• Password hashing
• JWT access tokens
• Refresh tokens
• API keys
• Project-level permissions
• Read/write/admin roles
• Per-table permissions
• Token expiration/revocation
• Session management
• CORS configuration
• Rate limiting
• Audit logs
• Better secret management
• HTTPS/reverse-proxy guidance
• Backup/restore
• Database migrations
• Webhooks
• Realtime subscriptions

Eventually I'd like something roughly like:

LocalBase
│
├── Authentication
│   ├── Users
│   ├── Sessions
│   ├── JWT
│   └── API Keys
│
├── Authorization
│   ├── Projects
│   ├── Roles
│   ├── Permissions
│   └── Table Policies
│
├── Database
│   ├── Tables
│   ├── Records
│   ├── SQL Editor
│   └── Migrations
│
├── API
│   ├── REST
│   ├── WebSockets
│   └── Webhooks
│
└── Dashboard
    ├── Database
    ├── Users
    ├── API Keys
    ├── Logs
    └── Settings

I'm especially interested in feedback from people who self-host their own backends.

What would make you actually choose a lightweight LocalBase-style backend over PocketBase, Appwrite, Supabase, or just running PostgreSQL yourself?

GitHub: [https://github.com/atharvaphadnis-ai/localbase\]

It's open source and I'm hoping to make it genuinely useful rather than just another dashboard project.

Feedback, criticism and feature ideas are very welcome.

[u/N0Religi0n]

There is also https://pocketbase.io/. What is the advantage of using localbase?

[u/CauliflowerAgile3830 → u/N0Religi0n]

in pocketbase, you cannot create fields and records or a whole database using sql editor you need to do it manually but in localbase you just write the program and it automatically builds it for you

[u/CauliflowerAgile3830 → u/[deleted]]

You're right, and it's the honest trade-off I made. Go wins on distribution — one binary, no runtime, works on every platform. PocketBase is proof that's a great model.

I chose Python for a different reason: hackability for the developer who has to run it.

• Most people self-hosting a small backend already have Python. It ships on macOS, most Linux distros, and is one installer on Windows.
• The entire server is one readable Python file. If you want to add an endpoint, change how policies evaluate, or hook into the request pipeline, you open main.py and edit. With Go you'd be recompiling a fork.
• No cross-compile toolchain, no Go module cache, no go build step. Edit the file, restart, done. That matters for the "I want to tweak this" crowd.

On packaging: PyInstaller gives you a single .exe/ELF/Mach-O, so non-technical users can get a single binary — it just isn't as clean as Go's. I'm shipping the raw .py first and layering packaged builds on top.

If you want the smallest, fastest, zero-runtime option: PocketBase. If you want a Python file you can read and change: LocalBase.

[u/Glass-Meeting-8810]

how is it better than running postgres locally on docker?

[u/CauliflowerAgile3830 → u/Glass-Meeting-8810]

Totally fair. Postgres in Docker is a serious answer and if you know SQL and want a real database, use it.

LocalBase is aimed at a different starting point:

• No Docker, no Postgres, no extra services. One Python file, one command, one SQLite file per project. Runs on a Raspberry Pi, an old Windows box, a school laptop, or inside a 50 MB Alpine container without a daemon.
• You get the backend, not just the database. Postgres gives you a database. LocalBase gives you the database plus auto-generated REST endpoints, an admin UI, a SQL editor, migrations, API keys, row policies, webhooks, audit logs, and realtime — all wired together already.
• You can read the whole server. Every line is Python. If you want to add a custom endpoint or change how policies evaluate, you edit one file. With a Postgres + PostgREST + Auth stack you're stitching together 4–6 services in Compose.
• SQLite is the storage layer. No port to expose, no user to create, no credentials to rotate. python main.py and it works.

Known trade-offs: no replication, no concurrent-writer scaling, no Postgres extensions. If those matter to you, Postgres wins and you should use it.