Operations on OpenClaw Deploy

Backup & Restore

Mon, 01 Jan 0001 00:00:00 +0000

Backups run daily at 03:00 UTC via systemd timer and are stored in ~/backups/ on the VPS.

Make Targets

1
2
3
4


make backup-now # Trigger backup immediately
make backup-pull # Download latest backup archive locally
make restore # List available backups (dry-run — safe)
make restore EXECUTE=1 BACKUP=<file> # Restore from backup

make restore without EXECUTE=1 is always safe — it just lists available backups.

CI/CD Setup

Mon, 01 Jan 0001 00:00:00 +0000

CI/CD

The built-in CI validates and tests Terraform (terraform fmt, terraform validate, tflint, terraform test). Ansible is never run in CI — all make bootstrap / make deploy operations are local only.

Example workflows for terraform plan (on PRs) and terraform apply (manual dispatch) are included as .example.yml files — copy them to enable (see Required Secrets below).

An optional GitOps deployment workflow is also included — copy .github/workflows/deploy.yml.example to .github/workflows/deploy.yml to enable automatic Ansible-based deployments on push. See GitOps auto-deploy for setup instructions.

GitOps Auto-Deploy

Mon, 01 Jan 0001 00:00:00 +0000

GitOps Auto-Deploy

A GitHub Actions pipeline can automatically deploy to the VPS on every push to main. This is optional — if you don’t configure the secrets below, the workflow won’t run and you can continue deploying manually with make deploy.

What It Does

Triggered by changes to openclaw.json, docker/, docker-compose.yml, ansible/, or secrets/.env.enc
Connects to the VPS via an ephemeral Tailscale node (no public SSH required)
Decrypts secrets/.env.enc using SOPS + age key from GitHub Secrets
If docker/ or docker-compose.yml changed: runs make deploy REBUILD=1
Otherwise: runs make deploy

A manual rollback workflow is also included (.github/workflows/rollback.yml) — trigger it from the GitHub Actions UI with any previous git SHA. It also decrypts secrets with SOPS before deploying.

Remote State

Mon, 01 Jan 0001 00:00:00 +0000

Remote State Backend

By default Terraform uses a local backend (terraform.tfstate on disk). This requires zero setup and works fine for solo use. For team workflows or CI/CD, a remote backend gives you shared state, versioning, and locking.

Choosing a Backend

terraform/envs/prod/backend.tf (copied from backend.tf.example) controls the backend:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# Option A — Local (default, no setup required)
terraform {
 backend "local" {}
}

# Option B — GCS (recommended for teams / CI)
terraform {
 backend "gcs" {
 bucket = "your-project-tfstate"
 prefix = "openclaw/prod"
 }
}

Terraform supports other backends too (S3, Azure Blob, Terraform Cloud). Any Terraform-compatible backend works — update backend.tf accordingly. Note that S3 requires a separate DynamoDB table for state locking, whereas GCS locks natively.