Overview
AnvilBase is a self-hostable Backend-as-a-Service (BaaS) platform. You run it on your own infrastructure and it gives your applications everything a modern backend needs, without you having to assemble and operate a dozen separate services:
- A PostgreSQL 15 database per project, with extensions enabled.
- An auto-generated REST API over your tables (PostgREST-compatible).
- Authentication — email/password, magic links, OAuth (GitHub, Google, Apple, Discord, Microsoft), sessions, and bans.
- Realtime subscriptions — stream database changes, broadcast messages, and track presence over WebSockets.
- Object storage — S3-compatible, per-project buckets, signed URLs.
- Edge Functions — Deno/TypeScript serverless functions, one isolated process per project.
- Queues (PGMQ), cache (Valkey), cron (pg_cron), webhooks, and an encrypted secrets vault (pgcrypto).
- A unified web console to manage all of your projects from one dashboard.
- A CLI and an MCP server for automation and AI-assisted workflows.
It is, deliberately, Supabase-compatible on the data plane: the REST query
syntax, the anon / service_role key model, and the realtime wire protocol all
match, so @supabase/supabase-js (and the Python/Dart clients) work against it.
What makes it different
AnvilBase is not “another Supabase.” It targets three things that self-hosted backends historically do badly:
1. True multi-project management from one console
A single AnvilBase deployment hosts many fully-isolated projects. Each project
gets its own database (platform_<id>), its own storage bucket, its own
JWT secret, and its own API keys. You manage them all from one console and
one CLI — you don’t stand up a fresh stack per project the way self-hosted
Supabase requires.
The enabling trick is the built-in REST→SQL engine: instead of running one PostgREST process per database (500 MB–1 GB of RAM each), AnvilBase serves every project’s REST API from a single Rust binary using lazy per-project connection pools that cost ~2–5 MB each. Ten projects cost tens of megabytes, not tens of gigabytes. See Architecture.
2. Security architecture that’s on by default
- Database-per-project isolation — not schema separation, not row tags. A separate database per tenant.
- Row Level Security (RLS) enabled by default on every table you create.
- Encryption at rest (LUKS / SSE-S3 / pgcrypto) and in transit (TLS, optional internal mTLS).
- Audit logging of every administrative action.
- RBAC at both the platform and per-project level, plus scoped API keys.
This makes AnvilBase usable in regulated contexts (EU healthcare, finance, government) where the hosted alternatives are off the table. It even ships an optional eIDAS 2.0 module for EU Digital Identity wallet verification.
3. Local = cloud
The exact same Docker Compose stack runs on your laptop and in production. There
is no “local emulator” that drifts from the real thing. The CLI’s
anvilbase start brings the whole platform up locally; anvilbase deploy
promotes schema, secrets, and functions to a remote environment.
Who it’s for
- Solo developers and small teams building several apps who don’t want a separate backend stack (and separate bill, and separate upgrade treadmill) per app.
- EU / data-sovereignty-constrained teams who must keep data on infrastructure they control.
- Regulated industries (health, finance, legal) that need RLS, a secrets vault, audit logs, and optionally verifiable EU identity out of the box.
- Agencies managing many client projects who want one console and one operational surface.
What you’ll find in these docs
- Why AnvilBase puts it side-by-side with Supabase, Neon, Upstash, and Appwrite.
- Architecture explains how the pieces fit together.
- Core Concepts defines the vocabulary (projects, the two API planes, keys, isolation) you’ll see throughout.
- Getting Started gets a stack running.
If you just want to build, jump straight to the Quickstart.