Managed Supabase
Understand the full self-hosted Supabase stack, service boundaries and compound recovery.
Managed Supabase is in development and unavailable for creation. It is a self-hosted application platform built around PostgreSQL, with its own Auth, APIs, object storage and administrative services. It is separate from an ordinary Hakopod managed PostgreSQL database and does not connect to the hosted Supabase service.
The services in the stack#
| Service | Responsibility |
|---|---|
| PostgreSQL | Store application data, Auth records, policies and Storage metadata. |
| Envoy | Route application API requests to the correct internal service. |
| Auth | Manage identities, sessions and configured redirect rules. |
| PostgREST | Expose database APIs subject to roles and row-level security. |
| Realtime | Deliver authorized subscriptions and database changes. |
| Storage | Authorize object access and maintain its database metadata. |
| imgproxy | Transform supported images for Storage requests. |
| Edge Runtime | Execute the configured functions. |
| postgres-meta | Provide database administration APIs. |
| Studio | Provide the separately protected administration interface. |
| Supavisor | Pool PostgreSQL connections with configured limits. |
The renderer tracks the upstream self-hosted inventory at d6c81b66c9999cb121dd8876f541313d484f157f. The repositories and bundled components have their own licenses; consult the exact pinned release when operating them.
Security boundaries#
Each service needs a digest-pinned image, a verified non-root runtime identity and bounded CPU, memory and temporary storage. Credentials come from versioned secrets scoped to the platform's project and environment. Service roles are separate from the database owner account. Signing keys, database passwords and administrator credentials must not appear in desired configuration, operation records, logs or public observations.
Envoy is the application API entry point. Studio needs separate administrator authorization. Database and pooler connections remain private until their endpoint policy passes review. Auth redirects require exact configured origins. Email signup stays disabled until its SMTP configuration and egress policy are qualified. Edge Functions have no external network access by default.
The current source candidate pins all services to one named node because Edge Functions and Studio snippets use shared ReadWriteOnce volumes. It does not provide a multi-node Supabase deployment. A single-node stack cannot survive the loss of that node.
Recovery includes more than PostgreSQL#
A PostgreSQL dump cannot recover object bytes, function files or the encryption keys used by stored data. The recovery candidate binds six archive parts to one manifest: the database dump, role definitions, database encryption files, Storage objects, Edge Functions and Studio snippets. The manifest records the platform revision, image digests, owned volume identities, capture boundary and content hashes.
Before capture, every supported write path must be paused and drained. The durable operation journals the prior state before changing it. After a worker crash or revoked authority, cleanup must restore the source's prior state before the operation becomes terminal. Every command rechecks the live namespace, workload, pod and image identities.
Restore targets a separate empty compatible platform. Archive validation precedes mutation. The target remains isolated after restore until its data and application behavior have been inspected and a cutover has been separately reviewed. Writes after the capture point are not copied automatically.
Release requirements#
Renderer, lifecycle and client checks have development passes. The recovery candidate is undergoing real store and runtime validation. The full native stack, compound recovery, credential rotation, certificate routing and public endpoints remain unqualified.
Native acceptance must exercise Auth and redirect rules, row-level security through PostgREST, Realtime authorization, Storage bytes and metadata, image transformation, Edge Function isolation, Studio access, Supavisor limits, TLS, restart persistence, rotation and revocation, separate-target restore and owned cleanup. These gates stay closed until the exact source and images pass.
Use the database recovery guide to plan inspection and cutover. See Managed PostgreSQL if your application needs a database without the additional Supabase services.