From Deployment Platform to Backend-as-a-Service: How We Added PostgREST and Auth to sh0 in One Session

On April 10, 2026, Thales looked at sh0's feature list and asked a question that had been building for weeks: "We have so many features -- what is sh0, really?"

It was a fair question. sh0 had 29 completed phases. Managed PostgreSQL, MySQL, MongoDB, Redis servers. S3-compatible object storage via MinIO. Email hosting via Stalwart. 170 one-click deploy templates. Horizontal scaling, cron jobs, preview environments, MCP server with 30 AI tools. A CLI with sh0 push that deploys any local directory in 30 seconds.

But there was a gap. Developers could deploy databases and frontends on sh0, but they still needed to write a backend to connect the two. Every SaaS builder on sh0 was writing the same boilerplate: REST endpoints wrapping SQL queries, user registration and login, JWT verification middleware.

Supabase solved this years ago. PostgREST auto-generates REST APIs from PostgreSQL tables. GoTrue handles auth. Realtime relays database changes over WebSocket. The developer writes zero backend code.

We decided to close the gap. Not by building a Supabase clone, but by adding two containers to sh0's existing managed service infrastructure. This post documents how we designed, implemented, and shipped PostgREST and managed auth in a single session -- and how a sidebar redesign made room for an entire BaaS platform.

The Sidebar Problem

Before we could add BaaS features, we had a UX problem. sh0's dashboard sidebar had 12 navigation items:

Dash | AI | Stacks | Deploy | Domains | Files | Databases | Mail | Backups | Cron | API Docs | CLI

Adding Auth, Realtime, and Functions would push it to 15. On a laptop screen, that is unusable.

The solution was borrowed from sh0's own Settings page: a hub page with a context sidebar. We called it "Services."

The Reorganization

We consolidated everything that is not daily navigation into Services:

The Services page has its own secondary sidebar grouping everything into three sections:

Managed Services: Object Storage, Database Servers, Mail, Domains, Cron Jobs Backend as a Service: Auth, Realtime (coming soon), Functions (coming soon) Developer: Monitoring, API Explorer, CLI

This is a pattern borrowed from cloud dashboards like AWS and DigitalOcean -- a primary sidebar for core navigation, a secondary sidebar for feature categories. The key insight: we did not remove any pages. We grouped them. Every old URL still works. Detail pages (/database-servers/{id}, /mail/{id}, etc.) are unchanged. Only the list pages and back-links were updated to route through /services/*.

The implementation took about an hour and touched 30 files -- mostly adding i18n keys across 5 languages and updating breadcrumb links. The build passed on the first try because every service page was a self-contained copy with its PageHeader replaced by a section header. No shared state, no refactoring risk.

But the real value was strategic: the sidebar now has room for unlimited BaaS features. Auth, Realtime, Functions, SDKs, Edge Workers -- they all slot into the Services context sidebar without touching the main navigation.

PostgREST: The Sidecar Pattern

PostgREST is a single binary that connects to a PostgreSQL database and exposes every table as a RESTful endpoint. It handles filtering (?age=gt.18), pagination (?limit=10&offset=20), sorting (?order=created_at.desc), joins, bulk inserts, and OpenAPI spec generation. All from the database schema. Zero application code.

The architecture question was: should PostgREST be a standalone service or a sidecar?

sh0 already had a sidecar pattern. Every PostgreSQL database server can have a dbGate admin UI container deployed alongside it. The admin UI connects to the same database, gets its own subdomain, and its lifecycle is tied to the database server -- when you stop the database, the admin UI stops too.

PostgREST fits the same model exactly. It connects to the same database, needs its own subdomain, and should start/stop with the database. So we implemented it as a sidecar.

What the Developer Sees

On any PostgreSQL database server detail page, a new "REST API" tab appears. One button: Enable REST API.

Clicking it: 1. Creates an anon role in PostgreSQL (the role PostgREST uses for unauthenticated requests) 2. Deploys a PostgREST container (128 MB RAM -- it is very lightweight) 3. Assigns a subdomain: mydb-api.sh0.app 4. Configures Caddy reverse proxy with automatic SSL 5. Creates a Cloudflare DNS A record

Within seconds, the developer has a live REST API:

bash# List all users
curl https://mydb-api.sh0.app/users

# Filter
curl https://mydb-api.sh0.app/orders?status=eq.pending&order=created_at.desc

# Insert
curl -X POST https://mydb-api.sh0.app/products \
  -H "Content-Type: application/json" \
  -d '{"name": "Widget", "price": 29.99}'

# Get the auto-generated OpenAPI spec
curl https://mydb-api.sh0.app/

The tab also shows configuration options: which PostgreSQL schemas to expose (default: public) and which role to use for anonymous access (default: anon). Changing these recreates the container with updated environment variables.

The Implementation

The sidecar pattern means the implementation was almost mechanical -- copy the admin UI pattern and change the image name.

Migration 045 adds 7 columns to database_servers:

sqlALTER TABLE database_servers ADD COLUMN postgrest_enabled INTEGER NOT NULL DEFAULT 0;
ALTER TABLE database_servers ADD COLUMN postgrest_container_id TEXT;
ALTER TABLE database_servers ADD COLUMN postgrest_container_name TEXT;
ALTER TABLE database_servers ADD COLUMN postgrest_port INTEGER;
ALTER TABLE database_servers ADD COLUMN postgrest_domain TEXT;
ALTER TABLE database_servers ADD COLUMN postgrest_anon_role TEXT DEFAULT 'anon';
ALTER TABLE database_servers ADD COLUMN postgrest_schemas TEXT DEFAULT 'public';

No new tables. No new models. Just 7 optional columns on an existing table. This is the advantage of the sidecar pattern -- PostgREST is not an independent entity, it is a feature of a database server.

The Docker container needs exactly 4 environment variables:

PGRST_DB_URI=postgres://root:[email protected]:5432/postgres
PGRST_DB_ANON_ROLE=anon
PGRST_DB_SCHEMAS=public
PGRST_SERVER_PORT=3000

The container connects to the database server over sh0's internal Docker network (sh0-net). No ports are exposed to the host except through Caddy's reverse proxy with SSL.

Lifecycle integration was the most important part. We modified the existing stop, start, delete, and recreate handlers:

• Stop database server: also stop the PostgREST container and deactivate its Caddy route
• Start database server: also start PostgREST and reactivate the route
• Delete database server: delete PostgREST container, remove DNS record, clean up domain
• Recreate database server: recreate PostgREST too (it needs to reconnect to the new container)

This ensures PostgREST never outlives its database. No orphaned containers, no dangling DNS records, no stale Caddy routes.

Auth: The Standalone Pattern

Authentication is different from PostgREST. A PostgREST instance belongs to exactly one database server. But an auth service is its own thing -- it has its own admin console, its own user management, its own login flows. Multiple applications can share the same auth instance.

So we implemented auth as a standalone managed service, following the mail and file storage patterns.

Why Logto

We evaluated the options:

Logto won because it provides a complete admin console (user management, application configuration, social connectors) on a separate port. This maps cleanly to sh0's "two domains per service" pattern -- one for the auth endpoint, one for the admin console. Exactly like database servers have a server domain and an admin domain.

What the Developer Sees

Under Services > Auth, the developer creates a new auth instance:

1. Name it (e.g., "my-saas-auth")
2. Select which PostgreSQL database server to use for storage
3. Click Create

sh0 handles everything: - Creates a logto database and logto user on the selected PostgreSQL server - Deploys the Logto container (512 MB RAM) - Assigns two subdomains: my-saas-auth.sh0.app (auth endpoint) and my-saas-auth-admin.sh0.app (admin console) - Configures Caddy + DNS for both

The developer then: 1. Opens the admin console to create an application (gets a client ID) 2. Integrates with their frontend using Logto's SDK:

jsximport { LogtoProvider } from '@logto/react';

function App() {
  return (
    <LogtoProvider config={{
      endpoint: 'https://my-saas-auth.sh0.app',
      appId: 'your-app-id-from-admin-console'
    }}>
      <YourApp />
    </LogtoProvider>
  );
}

Email/password signup, Google OAuth, GitHub OAuth, magic links -- all configured through Logto's admin console. No code changes on sh0's side.

The Implementation

Migration 046 creates a new auth_servers table:

sqlCREATE TABLE IF NOT EXISTS auth_servers (
    id TEXT PRIMARY KEY,
    name TEXT NOT NULL UNIQUE,
    database_server_id TEXT NOT NULL REFERENCES database_servers(id),
    database_name TEXT NOT NULL DEFAULT 'logto',
    status TEXT NOT NULL DEFAULT 'pending',
    container_id TEXT,
    container_name TEXT,
    port INTEGER,
    admin_port INTEGER,
    domain TEXT,
    admin_domain TEXT,
    volume_name TEXT,
    credentials_encrypted BLOB NOT NULL,
    project_id TEXT REFERENCES projects(id) ON DELETE SET NULL,
    created_at TEXT DEFAULT (datetime('now')),
    updated_at TEXT DEFAULT (datetime('now'))
);

The database_server_id foreign key is the critical design choice. An auth server does not own its PostgreSQL -- it references one. This means: - Multiple auth instances can share a PostgreSQL server - Deleting the auth instance does not touch the database server - The developer can see which PostgreSQL server backs each auth instance

Credentials are stored encrypted (AES-256-GCM), following the same pattern as database servers. The encrypted blob contains the Logto database user and password -- the credentials that were auto-generated when the auth instance was created.

The create flow is the most complex handler:

1. Validate the target database server is PostgreSQL and running
2. Decrypt the database server's root credentials
3. Create a logto database and logto user via docker exec on the PostgreSQL container
4. Generate a secure password for the Logto database user
5. Build the DB_URL connection string
6. Create a Docker volume for Logto's connector storage
7. Pull the Logto image if not cached
8. Create the container on sh0-net with the right environment variables
9. Insert the auth server record into SQLite
10. If the insert fails, clean up the orphaned container and volume
11. Auto-assign two domains with collision detection
12. Return the auth server details

Steps 9-10 are important for reliability. If the database insert fails (unique constraint, disk full, whatever), we delete the Docker container we just created. No orphans.

Parallel Agents: Building Two Features at Once

PostgREST and auth are independent features. Different database tables, different Docker modules, different API handler directories, different dashboard pages. The only shared files are router.rs (additive -- just new routes), types.ts (additive -- just new interfaces), and api.ts (additive -- just new API client methods).

This meant they could be built in parallel.

We used Claude Code's team feature to spawn two agents in isolated git worktrees:

Agent A (postgrest-agent): Phase 1 -- PostgREST sidecar
Agent B (auth-agent):      Phase 2 -- Logto auth service

Each agent received a detailed prompt with: - The exact files to create and modify - The patterns to follow (with specific file paths) - The verification steps to run

Both agents completed independently. Their worktree changes were merged into the main working directory. The only conflicts were expected -- both added routes to router.rs and types to types.ts, but in different sections with no overlap.

Post-merge, we ran clippy and fixed 4 minor warnings (redundant closures, useless format! calls). Total wall-clock time from plan approval to passing build: about 20 minutes for both features combined.

Why Parallel Agents Work

The traditional approach would be: implement PostgREST, test it, then implement auth. Sequential. Each feature takes the full context window's attention.

The parallel approach works because:

1. File isolation. Each feature touches its own set of files. PostgREST modifies db_server.rs; auth creates auth_server.rs. No merge conflicts.

1. Pattern consistency. Both agents follow the same patterns -- the same migration structure, the same Docker container creation, the same handler layout. There is no design coordination needed because the patterns are already established.

1. Additive changes. New routes, new types, new API methods. Nothing is renamed or restructured. Both agents add to the same files but in separate sections.

1. Independent verification. Each agent runs cargo check and npm run build in its worktree. Build failures in one agent do not affect the other.

The risk is merge conflicts. We mitigated this by giving each agent explicit instructions about which files to modify and which to create. The only shared files were append-only (router, types, API client).

The Complete Developer Journey

After this session, here is what a developer can do on a fresh sh0 server:

Step 1: Create a PostgreSQL server           /services/databases
Step 2: Create tables via dbGate admin UI     one click from overview
Step 3: Enable REST API                       one click in "REST API" tab
Step 4: Create an Auth instance               /services/auth -> select PG server
Step 5: Configure auth (social login, etc.)   Logto admin console
Step 6: Build frontend                        talks to REST API + Auth
Step 7: Deploy frontend on sh0               sh0 push or /deploy

Seven steps. Zero backend code. The developer goes from an empty server to a live SaaS application with database, API, authentication, and frontend -- all managed from one dashboard.

This is what Supabase offers as a cloud service. sh0 offers it self-hosted, on your own VPS, for a fraction of the cost.

What is Left

Two items remain in the BaaS section with "coming soon" badges:

Realtime -- WebSocket subscriptions on database changes. PostgreSQL has LISTEN/NOTIFY built in. The implementation would be a lightweight relay container that subscribes to PostgreSQL notifications and fans them out to WebSocket clients. Similar complexity to PostgREST -- a single container sidecar.

Functions -- Serverless code execution. A Deno runtime container where developers upload TypeScript functions invoked via HTTP. sh0 already has the upload infrastructure (ZIP extraction, container exec) from the sh0 push feature and the AI sandbox. The container management is identical.

Both will follow the same patterns we established today. The sidecar pattern for realtime (tied to a PostgreSQL server), the standalone pattern for functions (independent service). The Services hub has room for them in the sidebar. The migration framework, Docker module structure, handler layout, and dashboard components are all templated.

The Architecture of Adding Features

The most interesting outcome of this session was not PostgREST or auth. It was the confirmation that sh0's architecture supports feature addition without architectural changes.

Every new managed service follows the same formula:

1. Migration: new table or new columns
2. Model: Rust struct with from_row, insert, CRUD methods
3. Docker module: create_container, get_ports, start, stop, delete
4. Handlers: CRUD + lifecycle + domain assignment
5. Dashboard: list page + detail page + API client + i18n

The formula is so consistent that we could describe it in a prompt and two AI agents implemented both features in parallel, independently, and the results merged cleanly.

This is what happens when you invest in patterns early. Phases 1 through 25 of sh0 established conventions: how containers are named, how credentials are encrypted, how domains are assigned, how errors are handled, how sidebars are structured. Every feature after that is variation on a theme.

The sidebar reorganization was the same principle applied to UX. Instead of adding nav items for each feature, we created a category system. Now the sidebar is stable -- it will not change when we add realtime, functions, SDKs, or any other service. The Services hub absorbs them all.

sh0 started as a deployment platform. Today it is a self-hosted cloud platform. The transition did not require a rewrite. It required two containers and a sidebar redesign.