Skip to content

Self-Host

ForgeOS can emit deployment artifacts and run self-host checks for running generated apps outside local forge dev.

This page covers the supported self-host workflow — not a specific cloud vendor.

Generate deployment artifacts

forge self-host compose
forge self-host check --json

Typical outputs (paths vary by app):

Artifact Purpose
deploy/docker-compose.yml Local/production compose stack
deploy/.env.example Required environment variable names
Generated deploy manifest Runtime URLs, secrets, health checks

Review deploy/.env.example for secret names before deploying. Never commit real secret values.

Check before deploy

forge self-host check --json

Validates:

  • Required secrets are declared
  • Auth mode is appropriate for non-dev deployment
  • Database adapter configuration is coherent
  • Generated deploy manifest matches current app graph

Fix issues surfaced by forge check and forge verify --strict first.

Production auth

Self-hosted deployments must use jwt or oidc — not dev-headers.

forge auth check --json

See Security and Data.

Database

Production typically uses Postgres with migrations:

forge db migrate
forge db status --json
forge rls check --json

Apply RLS policies when tenant isolation must be DB-enforced.

LiveQuery in production

Production liveQuery relies on:

  • Durable invalidation log (_forge_live_invalidations)
  • SSE or long-polling wakeups
  • Postgres NOTIFY as optional wakeup — not the source of truth

See Frontend — LiveQuery.

Release debugging

When symbolicated stack traces are configured:

forge release inspect <releaseId> --json
forge release sourcemaps symbolicate --input stacktrace.json --json
forge telemetry inspect <traceId> --with-release --json

Agent workflow

forge do "prepare self-host deployment" --json
forge self-host compose
forge self-host check --json
forge verify --strict

Playbook reference: src/forge/_generated/operationPlaybooks.md → Self-host.