zBase

Self-hosted Postgres provisioning, on your own box.

zBase spins up an isolated Postgres role + database per project through a small HTTP API — a self-hosted stand-in for Neon, running on infrastructure you control.

Postgres 16 PgBouncer pooled TLS required AES-256-GCM at rest Google OAuth + JWT Neon-API compatible
zbase create acme-corp --env
# → DATABASE_URL written to .env.local, ready to use
# → measured: 2 seconds, connection tested over TLS

Getting started

Two ways in. Neither needs anything running locally except the CLI, and that's optional.

Dashboard — nothing to install

Sign in with Google, create a project, copy its connection string. Credentials are fetched per request and never cached in the page.

CLI — for the terminal

sudo npm link in cli/, then zbase login. Sign-in happens in your browser and the token is handed back automatically — nothing to paste.

What it does

Provision on demand

Each project gets its own Postgres role and database via CREATE ROLE / CREATE DATABASE — no shared schemas, no manual setup.

Neon-shaped responses

API responses mirror Neon's shape (project, connection_uris, databases, roles), so existing Neon-client callers point here unchanged.

Pooled connections

Clients always receive a PgBouncer connection string, never a direct Postgres one — the superuser connection is used only internally for provisioning DDL.

Encrypted credentials

Tenant passwords are encrypted at rest (AES-256-GCM) in the control database and only decrypted when a caller fetches a project's connection string.

Google OAuth gate

Sign-in is restricted to an allowlist of email domains. Everything else on the API requires a valid Bearer JWT.

Org-scoped isolation

Your organization comes from your email domain. Projects belong to an org and every lookup is scoped to it — another org's project is indistinguishable from one that doesn't exist.

TLS or nothing

Tenant credentials cross the public internet, so PgBouncer refuses plaintext outright. The cert is publicly trusted, so verify-full works with no custom CA bundle.

Strict identifiers

Role/database names can't be parameterized in Postgres — zBase validates them against a strict pattern instead of relying on escaping.

Who can sign in

Google sign-in, limited to verified accounts on these domains. The verification check matters: your organization is derived from your email domain, so an unverified address would otherwise be enough to join someone else's org.

skubbs.com im.skubbs.com vaniceadvisory.com

Status

AreaState
Provisioning, dashboard, CLIWorking — in use
Tenant isolationOrg-scoped; cross-org access returns 404
Session revocationToken versioning; 7-day expiry
Rate limiting & quotaPer-route limits, per-org project cap
Audit trailCreate, delete, and credential reads
BackupsNightly; encrypted off-site copy to Cloudflare R2

Backups are encrypted client-side before leaving the machine — the dumps carry every role's password verifier, so off-site storage must not mean readable storage.