Axiomatic

Self-hosting

Deploy Axiomatic on your Postgres and network with compiled container images — same API, tenant isolation, and encryption as cloud.

Overview

Enterprise and regulated teams can run Axiomatic on their own infrastructure. The recommended path is a compiled standalone build packaged as a Docker image.

You get the same unified web app and /api/... REST surface as cloud, with per-tenant Postgres isolation, field-level encryption, and RBAC. Set SELF_HOSTED=true to bypass cloud prepaid credit metering on writes.

Axiomatic builds with Next.js output: "standalone" when SELF_HOSTED=true. The output is traced, compiled server JavaScript plus static assets.

ComponentDelivery
Web app + APIStandalone Docker image (apps/web/Dockerfile)
Tenant migrationsSQL bundle shipped in the image at packages/db/drizzle-tenant
Rule engineWASM artifacts included in the app build
Period-close ZK proofsSeparate prover-gateway service or native axiomatic-prover on a worker host

Enterprise customers receive a self-hosted license package:

  • Private registry credentials and versioned image tags
  • Environment and migration checklist for your Postgres and network
  • Upgrade playbook with release notes for each tag
  • Optional managed deployment in your VPC

Contact enterprise sales for licensing, image access, and support SLAs. Registry coordinates are provisioned per customer — there is no public image download today.

Required infrastructure

  • PostgreSQL 16+ — control plane DB plus one database per tenant (Neon, RDS, or self-managed Postgres)
  • Secrets — at minimum AUTH_SECRET, MASTER_KEY, and CP_ENCRYPTION_KEY (see apps/web/.env.example)
  • Outbound network — only if you enable integrations (Plaid, Stripe, email, AI providers)

Optional but common for production self-host:

  • Object storage for documents (S3-compatible)
  • prover-gateway container for period-close proofs (prover gateway README in the monorepo)
  • Cron / job runner for scheduled routes under /api/cron/...

Environment variables

Copy apps/web/.env.example as a checklist. Minimum for a working deployment:

VariablePurpose
SELF_HOSTEDSet to true — enables standalone build semantics and bypasses cloud credit gating
DATABASE_URLFallback / shared dev database
CONTROL_PLANE_DATABASE_URLIdentities, tenants, billing metadata
AUTH_SECRETSession and auth token encryption
AUTH_URL / NEXTAUTH_URLPublic URL of the deployment
MASTER_KEYEntity DEK wrapping (32-byte hex)
CP_ENCRYPTION_KEYControl-plane secret encryption
TENANT_DRIZZLE_MIGRATIONS_DIRSet automatically in the reference Docker image

Run pnpm db:migrate (control plane + all tenant DBs) from an ops workstation with production credentials, or use your own migration pipeline against the SQL in packages/db/drizzle-tenant.

Upgrades and security

Self-hosted deployments stay secure through versioned releases, not source secrecy:

  1. Pull or receive the new image tag (for example 2026.06.1).
  2. Run pending migrations (pnpm db:migrate or your pipeline).
  3. Rolling-restart the web and prover services.
  4. Review release notes for breaking env or schema changes.

Compiled artifacts raise the bar for casual inspection; patch delivery is what closes CVEs. Source access under NDA is available for vendor security reviews.

Build from source (development)

Contributors can clone the monorepo and build locally:

pnpm install
cp apps/web/.env.example apps/web/.env.local
# Edit env, then:
cd packages/db && pnpm db:migrate:single   # local DB only
cd ../..
SELF_HOSTED=true pnpm --filter @axiomatic/web build
SELF_HOSTED=true pnpm --filter @axiomatic/web start

For a full local stack with Postgres, from the platform/ directory after clone:

docker compose up --build

The compose file builds from source and is intended for development — not the production delivery path.

The public repo is BSL 1.1 — production use within your organization is permitted; contact licensing@axiomatic.financial for embedded product, multi-tenant SaaS, or alternative terms.

On this page