Deploying

One command builds your images, provisions infrastructure, runs migrations and cuts over DNS.

Deploy

spky deploy

The deploy command performs these steps automatically:

Validates your sp00ky.yml configuration
Builds Docker images for each app (linux/amd64)
Uploads images to Sp00ky Cloud (skips unchanged images)
Provisions infrastructure (SurrealDB, Scheduler, SSP instances)
Runs migrations against the cloud database
Deploys your backend and frontend containers
Configures DNS and SSL certificates

You’ll see real-time progress as each step completes.

Note

Run spky lint before deploying to catch config issues early.

Flags

Flag	Effect
`--upgrade`	Also pull the latest SSP and Scheduler images.
`--only api,web`	Build and deploy just these apps. Everything else keeps running untouched.
`--clean`	Wipe the scheduler’s persistent volume first. Last resort: the scheduler self-heals stale snapshot state on startup, and `spky verify --fix` (or `POST /admin/resync` on the scheduler) repairs it without a wipe. Your SurrealDB data is not touched either way.
`--force-schema`	Re-apply the internal schema and remote functions even when the hash says nothing changed. Drift recovery.
`--cache-bust`	Clients reloading onto this version clear service-worker caches first.
`--mandatory`	Clients reload immediately instead of being offered a notification. Broken-build kill switch.

spky deploy --upgrade

--only is the one to reach for during normal iteration: a frontend-only change doesn’t need the backend rebuilt.

Checking Status

spky status

Shows the current deployment version, status, and all running VMs with their roles and versions.

Scaling

Scale your SSP instances horizontally:

# Scale to 3 SSP instances
spky scale ssp 3

You can also set the default SSP count in your sp00ky.yml:

deployment:
  sspCount: 2

Log Level

logLevel in sp00ky.yml sets RUST_LOG on the Scheduler and SSP containers. Default is info.

# Single value applies everywhere
logLevel: info

Use a { dev, cloud } map to differ per environment:

# Per-environment: chatty locally, quiet in production
logLevel:
  dev: trace
  cloud: info

The value is forwarded to tracing-subscriber, so target-specific directives work:

# Tracing-style target=level directives also work
logLevel: info,ssp=debug,scheduler=trace

Each spky deploy sends the resolved cloud value to Sp00ky Cloud, which restarts the Scheduler and SSP containers with the new RUST_LOG. Use --upgrade if you also want fresh base images at the same time.

Note

At trace, the Scheduler logs every replica query and every record it ingests during bootstrap. Useful for diagnosing “why isn’t this row showing up?” See Logs & Monitoring.