snowclaw deploy

The full production pipeline: build both images, push to Snowflake, update secrets and config, and create or update the SPCS service. One command.

Usage

snowclaw deploy

What it does

1. Network rules — in allowlist mode, diffs detected rules against the saved allowlist. If there are pending changes, prompts before applying. In allow-all mode, ensures the catch-all rule is applied.
2. Build — assembles the build context and builds both images (OpenClaw gateway + Cortex proxy).
3. Push — pushes both images to your Snowflake image repository via the Docker registry protocol.
4. Secrets — reads .env, creates or replaces a Snowflake SECRET object for each variable, and writes SNOWCLAW_MASK_VARS so the proxy can mask them in outbound LLM traffic.
5. Stage upload — uploads openclaw.json and skills/ to the SPCS stage so the running container can pick them up via its persistent volume.
6. Service — creates the SPCS service if it doesn't exist, or ALTERs it to pick up the new image and spec.

When the service is READY, the CLI prints the public ingress URL.

What runs on SPCS

The SPCS service is one logical unit with two containers:

• openclaw — 1–2 CPU, 2–4Gi RAM. Secrets injected as env vars. Volume mounted at /home/node/.openclaw.
• cortex-proxy — 0.5–1 CPU, 512Mi–1Gi RAM. Same secrets for masking.

A single public endpoint on port 18789 handles all UI, WebSocket, and API traffic — the proxy is internal only.

Re-deploying

Re-running snowclaw deploy is always safe. If nothing has changed, Snowflake is a no-op; if something has changed, the service rolls with the new image or spec.

For faster iteration on config or skills only — without rebuilding images — see snowclaw push.