Operations

Running the system: environments, deployment, crons, monitoring, secrets and incident response.

EnvironmentsHosts, ports, processes — and the fact that there is no staging database.DeployThe GCP box, Netlify, swap-sdk releases, and UUPS contract upgrades.Cron jobsEvery scheduled job, what is disabled, and the two that move money.MonitoringWhat is watched, the three failures that produce no signal, and what to build.SecretsEvery key, its blast radius, and how to rotate it.RunbooksStep-by-step response to the failures that are actually likely.

Pages

Page	Covers
Environments	Hosts, ports, processes, and the fact that there is no staging
Backend & agent deploy	deploy.gcp.sh, and the rsync trap
Frontend deploy	Netlify, two sites, the optimized branch
swap-sdk releases	Tagging, and the lockfile trap
Contracts & upgrades	UUPS upgrades, storage-layout validation
Cron jobs	The full inventory, including what is disabled
Monitoring & health	What is watched, and the gaps
Key & secret management	Every key, its blast radius, and rotation
Incident runbooks	Step-by-step response to the likely failures

The three things that break deploys

Each has burned a real deploy. All three are documented in detail on their own pages, but they are worth stating up front.

1. The backend deploy is rsync, not git

deploy.gcp.sh checks whether the VM's app directory is a git repo. bz-backend on the VM is not, so it rsyncs your entire local working tree — excluding only .git/, node_modules/, .env, dist/, build/, logs/, .DS_Store and *.log — and without --delete.

Uncommitted local work reaches production. Deleted files persist on the VM.

2. .env never travels

It is excluded from the rsync, deliberately. A new environment variable must be added on the VM manually. "The code deployed but the feature does not work" is almost always this — UNISWAP_API_KEY is the canonical case.

3. Bumping swap-sdk needs the lockfile

package-lock.json pins by resolved commit, and npm install obeys it even after the deploy script's rm -rf node_modules/swap-sdk. Run npm install github:blazpay/swap-sdk#vX.Y.Z --package-lock-only and commit both files. A production deploy once installed 1.9.1 despite a v1.12.0 pin.

Quick command reference

# backend / agent (run from your Mac, in bz-backend/)
./scripts/deploy.gcp.sh deploy bz-backend             # sync + install + restart + health
./scripts/deploy.gcp.sh deploy bz-backend no-install   # code-only change
./scripts/deploy.gcp.sh push   bz-agent                # force rsync
./scripts/deploy.gcp.sh pull   bz-backend              # git pull on the VM (if it is a repo)
./scripts/deploy.gcp.sh restart bz-tokens
./scripts/deploy.gcp.sh logs   bz-backend 200
./scripts/deploy.gcp.sh status                         # pm2 table + all four ports
./scripts/deploy.gcp.sh ssh

# frontend
cd defi-dex && git push origin optimized               # Netlify auto-builds

# swap-sdk
cd swap-sdk && npm run build && git tag vX.Y.Z && git push origin vX.Y.Z

Branch and target map

Repo	Branch	Target	Build location
bz-backend	bishtNew	GCP VM :5000	Not built (BUILD=no)
bz-agent	main	GCP VM :4000	On the VM (BUILD=yes)
defi-dex	optimized	Netlify ×2	Netlify
swap-sdk	tags vX.Y.Z	Consumed as a git dependency	On install (prepare)

defi-dex's main is stale

Roughly 80 commits behind. optimized is the live branch.

Deploy order for a cross-cutting change

When a change spans the SDK, the backend and the frontend:

1. swap-sdk      →  build, tag, push
2. bz-backend    →  bump package.json + package-lock.json, commit, deploy
3. defi-dex      →  bump package.json + package-lock.json, commit, push
4. Contracts     →  before the backend, if the backend depends on a new function

Contracts first when the backend calls a new function; SDK first when both consumers need it. Verify each step before starting the next — there is no automated rollback.