Deploy with managed services

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:

Provide Postgres through DATABASE_URL and Redis through REDIS_URL. Run the migration job to completion before replacing web replicas or the worker. 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 \
  --build-arg NEXT_DEPLOYMENT_ID=release-0-2-0 \
  --tag registry.example.com/team/prosewire:0.2.0 .
docker push registry.example.com/team/prosewire:0.2.0

Record 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 -d

Your .env must contain the external database, Redis URL, public origins, authentication secret, server-action encryption key, and SMTP settings. The deployment ID is already part of the image. The cloud file does not provision Postgres, Redis, 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. Cloud deployments can create and switch between multiple workspaces. After onboarding, set the value to false and replace every web replica unless open Cloud registration is intentional. Invitation-based account creation continues to work when open registration is disabled.

Platform requirements

• Preserve the same NEXT_SERVER_ACTIONS_ENCRYPTION_KEY across web replicas and rolling releases
• Run the same image digest, including its baked deployment ID, on every replica of the same release
• Route traffic only after /api/health returns 200
• Allow graceful termination so in-flight requests can finish
• Run web, worker, and migration from the same immutable image digest
• Back up Postgres and Redis independently of the application lifecycle, preserve matching recovery points for the email outbox and queue, and test restoration
• Encrypt and network-restrict Postgres connections
• Configure Redis persistence, backups, and replication; disable key eviction; and restrict it to the private application network
• Keep exactly one supervised worker running for each database; the Effect SQL workflow runner in this release does not support multiple Prosewire worker processes
• Set PROSEWIRE_EMAIL_WORKER_CONCURRENCY so in-process concurrency stays within SMTP provider limits
• 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, Redis, SMTP, TLS termination, and the infrastructure services you choose.