Deployments

Deployments are groups of production Docker services running on your nodes — with custom domains, auto-TLS, and one-command deploys.

A deployment is a group of Docker services that share a private network and can communicate by service name as hostname. Deployments are designed for production workloads — databases, web apps, background workers, etc. — running on the same BYOC nodes as your development workers.

Each service in a deployment corresponds to a single Docker container:

Field	Description
`image`	Docker image to pull and run
`envVars`	Environment variables (key/value)
`httpPort`	Port to expose via the platform's edge proxy
`volumes`	Named Docker volumes to mount
`fileBinds`	Host path → container path bind mounts
`command`	Override the container entrypoint
`preDeployCommand`	Hook run before deploy (e.g. `npx prisma migrate deploy`)
`customDomain`	Custom domain for public access (requires DNS verification)

Start — restarts the existing container. Fast. No image pull.
Deploy — force-pulls the latest image, runs the pre-deploy hook, stops and removes the old container, creates a fresh one. Use this to ship new versions.

If a service has a preDeployCommand, it runs in a temporary container before the new version starts:

Deploy triggered
  ↓ Pull latest image
  ↓ Run pre-deploy hook (mp-hook-{id}) ← same image, same env, same network
  ↓ If hook exits 0 → stop old container → start new container
  ↓ If hook exits non-0 → abort, service → error state with hook logs

This is ideal for database migrations. If the migration fails, the running container is left untouched.

All services in a deployment share a private Docker bridge network named mp-dep-{deploymentId}. Services can reach each other by their service name:

# From inside the "api" service, reach the "db" service:
psql postgresql://db:5432/mydb

No service discovery configuration needed.

Each service can be assigned a custom domain (e.g. myapp.example.com). The flow:

Set the domain in service settings
Add a DNS TXT record: _spunto-challenge.myapp.example.com → {verificationToken}
Click Verify domain in the dashboard
Spunto automatically provisions a TLS certificate via Let's Encrypt HTTP-01

Warning

Only one service can own a verified domain at a time. If another service claims and verifies the same domain, the previous owner loses routing.

Services can have jobs — reusable shell commands that run on demand inside the service's container. Jobs are useful for:

Database migrations
Cache warmup scripts
One-off data transforms
Admin tasks

Each job run is logged and stored. You can view run history in the service cockpit.

Spunto includes a marketplace of pre-configured service presets (PostgreSQL, Redis, MinIO, etc.) that can be added to a deployment with a single click.

PreviousProjects NextObservability