The Problem
Teams that need a self‑hosted Backend‑as‑a‑Service often build custom CRUD layers, duplicate authentication logic, and struggle to enforce row‑level security across tenants. Maintaining separate codebases for API, admin UI, and real‑time features adds operational overhead.
What This Does
SnackBase delivers a single repository that generates REST endpoints from database collections, enforces multi‑tenant row‑level security, and ships a ready‑made React admin UI. The backend lives under the package entry point snackbase/main.py (invoked via python -m snackbase serve) and follows a clean‑architecture layout (domain/, application/, infrastructure/). The admin UI and example front‑ends are in examples/*, e.g., examples/feature-voting-app/src/App.tsx. Migration scripts are managed by Alembic in alembic/versions/, while security rules are documented in .agent/rules/.
How To Use It
Setup
Clone and move to project root git clone https://github.com/yourusername/snackbase.git cd SnackBase
Install Python dependencies (uv is used in the README) uv sync # reads pyproject.toml / requirements.txt
(Optional) Build the Docker image docker build -t snackbase .
Configuration
Copy the example environment file and fill in secrets:
cp .env.example .env edit .env – set SNACKBASESECRETKEY, SNACKBASEENCRYPTIONKEY, etc.
The same pattern applies to the example front‑ends (examples/feature-voting-app/.env.example).
Database Initialization
uv run python -m snackbase init-db # creates tables using Alembic uv run python -m snackbase create-superadmin # creates the first admin account
Running the service
uv run python -m snackbase serve # starts FastAPI on http://0.0.0.0:8000
The admin UI is reachable at http://localhost:8000 (served by FastAPI’s static files). Front‑end demos can be launched with npm:
cd examples/feature-voting-app npm ci npm run dev # Vite dev server, typically http://localhost:5173
Container deployment – docker-compose.yml defines a snackbase service and a PostgreSQL container; docker-compose up -d will start both.
Real‑World Use
A SaaS product can deploy SnackBase as the data layer for each customer account. When a new tenant signs up, the platform calls the internal API (POST /accounts) to create an isolated schema; the built‑in RLS policies (see snackbase/infrastructure/rls.py) automatically restrict queries to rows belonging to that tenant. The React admin UI can be embedded in the product’s internal dashboard, providing immediate CRUD screens without additional front‑end work.
Code Health & Issues
Medium – Missing CI/CD – No .github/workflows or other pipeline files; automated testing or linting is not enforced. Low – License clarity – LICENSE exists (AGPL‑3.0) but the README does not surface it prominently, which can cause compliance friction. Medium – Secret handling – Example .env.example files are present, but the repo includes no .env template for production keys; developers may inadvertently commit real secrets. Low – Test coverage – Only one test file detected despite a claim of “153 test files” in the README; actual test suite appears incomplete. Medium – Docker image size – The Dockerfile installs both Python and Node tooling, which may produce a bulky image for production. Low – Documentation gaps – While extensive docs exist, the “Realtime subscriptions” feature is listed as TODO, and associated server code is missing.
The Bottom Line
SnackBase provides a functional, open‑source BaaS with a solid FastAPI backend, Alembic migrations, and a polished React admin UI—useful for teams that want a quick, self‑hosted data service with multi‑tenant security. The codebase is reasonably organized, but the lack of CI, incomplete test suite, and missing production‑grade deployment guidance mean additional engineering effort is required before adopting it in a critical production environment.