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:
| Target | Image suffix | Role |
|---|---|---|
server | -server | Public and Admin HTTP |
worker | -worker | Jobs and event consumers |
migrate | -migrate | One-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:
- Run the migrate image once as a Job.
- Deploy the Server image as an HTTP service (
/healthz,/readyz). - Deploy the Worker image as a long-running service.
- 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__.apiUrlempty 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