Deploy with managed services
Run an immutable Prosewire image with external Postgres, SMTP, and a load balancer.
This guide assumes you build the repository’s Dockerfile and push the resulting image to a registry your runtime can access. It does not assume that a public Prosewire image or latest tag is available.
Runtime topology
A cloud deployment runs three commands from the same immutable image:
| Process | Command | Scaling |
|---|---|---|
| Migration | node apps/worker/dist/migrate.mjs | Exactly one successful job per release |
| Web | node apps/web/server.js | One or more replicas |
| Worker | node apps/worker/dist/index.mjs | One or more replicas |
Provide Postgres through DATABASE_URL. Run the migration job to completion before replacing web and worker replicas. Do not let an orchestrator repeatedly restart a completed migration as a long-running service.
Build and publish an image
Build from an immutable release tag or commit, then push a versioned tag to your registry:
docker build --tag registry.example.com/team/prosewire:0.2.0 .
docker push registry.example.com/team/prosewire:0.2.0Record the resulting digest and deploy by digest when the platform supports it.
Use the cloud Compose topology
The repository includes docker-compose.cloud.yml for a host that connects to external services:
PROSEWIRE_IMAGE=registry.example.com/team/prosewire:0.2.0 \
docker compose -f docker-compose.cloud.yml up -dYour .env must contain the external database, public origins, authentication secret, server-action encryption key, deployment ID, and SMTP settings. The cloud file does not provision Postgres, SMTP, TLS, backups, or a load balancer.
Bootstrap the first owner
Set PROSEWIRE_ALLOW_SIGN_UP=true only while creating the first account and workspace. After onboarding, set it to false and replace every web replica. Invitation-based account creation continues to work when open registration is disabled.
Platform requirements
- Preserve the same
NEXT_SERVER_ACTIONS_ENCRYPTION_KEYacross web replicas and rolling releases - Set one
NEXT_DEPLOYMENT_IDfor every replica of the same release - Route traffic only after
/api/healthreturns 200 - Allow graceful termination so in-flight requests can finish
- Run web, worker, and migration from the same immutable image digest
- Back up Postgres independently of the application lifecycle and test restoration
- Encrypt and network-restrict Postgres connections
- Keep at least one worker replica running for scheduled publishing and retention
- Capture migration, web, and worker logs in the platform’s logging system
No managed Prosewire control plane or billing service is required. The runtime is self-contained apart from Postgres, SMTP, TLS termination, and the infrastructure services you choose.