Supabase
futomaki.supabase
A Docker Compose file for Supabase alone, generated from the catalog and checked by the safety inspector. No account needed.
Backend platform assembled around PostgreSQL, adding generated REST and GraphQL APIs, authentication, authorisation through row-level security, file storage and realtime change streams.
Supabase is a set of services placed in front of a PostgreSQL database rather than a database in its own right: PostgREST derives an API from the schema, an auth service handles sign-up, sessions and third-party identity providers, a storage service manages files under permissions expressed as database policies, and a realtime server streams row changes over websockets. Authorisation is enforced by PostgreSQL row-level security, so access rules live with the data and apply identically to every route reaching it. The studio interface provides schema editing, a SQL console and user management. A self-hosted deployment brings these services up together, configured through generated keys and secrets.
You know it worked when
- The studio interface loads and connects to the database.
- A table created in the studio appears immediately in the generated REST API.
- A user can register and receive a session token.
- A row-level security policy rejects a request made with the anonymous key and allows the same request made as the owning user.
- A subscribed client receives a realtime event when a row changes.
Known sharp edges
- Row-level security is what enforces access, so a table created without policies is readable through the generated API by anyone holding the anonymous key.
- The service-role key bypasses every policy and must never reach client-side code.
- Example configurations ship with working default JWT secrets and dashboard credentials, leaving a deployment fully open until they are regenerated.
- Services must start in order and a failure in one usually surfaces as a misleading gateway error from another.