bBoson
Docs/Deployment

Deployment

Package migrate, Server, and Worker against infrastructure you own.

Deployment packaging must not leak into application logic. Use boson deploy to emit portable container images for migrate, Server, and Worker. Boson never provisions databases, buckets, mail providers, registries, or cloud services.

Package an application

boson deploy
boson deploy --tag ghcr.io/acme/my-app:0.1.0 --build
boson deploy --tag ghcr.io/acme/my-app:0.1.0 --push

This writes .boson/deploy/Dockerfile, .dockerignore, and CLOUD_RUN.md (override the directory with --output). The multi-stage Dockerfile builds three targets from the packages named in .boson/project.toml:

TargetImage suffixRole
server-serverPublic and Admin HTTP
worker-workerJobs and event consumers
migrate-migrateOne-shot migration Job

--push implies --build. Runtime images copy capabilities/ (so capability migrations travel with the app) and .boson/config.yaml; platform migrations are already embedded in boson-runtime. Inject production secrets at deploy time — do not bake them into the image.

Production boundaries

Production packaging deploys independent units:

  • Server owns public and Admin HTTP traffic, and may optionally serve Dashboard assets from http.dashboard_dir.
  • Worker owns background jobs and event consumers.
  • The migrate binary carries embedded platform migrations and applies them, followed by application capability migrations, before rollout.
  • Dashboard may be served by the Server (same origin) or deployed as a separate static Admin API client.

Provide PostgreSQL plus the configured port adapters (storage.provider, mail.provider, queue.provider).

Cloud Run guidance

Typical shape:

  1. Run the migrate image once as a Job.
  2. Deploy the Server image as an HTTP service (/healthz, /readyz).
  3. Deploy the Worker image as a long-running service.
  4. Inject BOSON__DATABASE__URL, auth secrets, and provider credentials through your secret manager.

Boson does not run gcloud, Terraform, or Compose to create those resources.

Dashboard delivery

Same-origin (recommended when packaging Server with assets):

  • Build the Dashboard into a directory
  • Set http.dashboard_dir / BOSON__HTTP__DASHBOARD_DIR
  • Leave window.__BOSON_CONFIG__.apiUrl empty so the client uses the Server origin

Standalone image (optional):

ghcr.io/systograms/boson-dashboard:0.1.0

Inject /config.js with BOSON_API_URL pointing at the Server.

Website on Vercel

Point a Vercel project at this repository with:

  • Root Directory: apps/website
  • Framework Preset: Next.js
  • Build Command: npm run build
  • Install Command: npm ci

Separation of concerns

  • Application images come from boson deploy
  • Platform monorepo images live under deploy/ for Boson itself
  • Dashboard is an Admin API client, not a Compose-managed lifecycle unit
  • Product capabilities depend on boson-sdk, not deployment packaging