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.

A service that exposes an HTTP port is public by default — anyone with the URL reaches it. Switch it to private in the service settings and pick which organization members may get in: a visitor is then sent through a Spunto login, and only an allowlisted member comes back with access.

Headless callers (a script, a CI job, an AI agent) have no browser to walk through that login. They send an API key scoped deployments:access on the request instead:

curl -H "X-Spunto-Token: spk_..." https://svc-{serviceId}.spunto.net/

The credential is checked by the proxy and stripped before the request reaches your container — your app never sees it, and its own Authorization header is left alone. See Reaching a private service for the full rule, including how personal and org-owned keys differ.

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.

Every running service has a Terminal tab in its cockpit — a live interactive shell inside the running container, the same experience as a worker terminal. Use it to inspect the filesystem, tail files, run one-off commands, or debug a misbehaving service without redeploying.

A Fullscreen button opens a touch-optimized, keyboard-aware editor (accessory keys for Esc/Tab/Ctrl-*/arrows, a compose bar pinned above the on-screen keyboard) so the shell is fully usable from a phone.

Note

The shell runs as your image's own user and uses bash if available, otherwise sh. It requires the service to be running.

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