cc-os/plugins/os-orchestration/eval/fixture/project/docs/deploy.md

Deploying Relaystation

Relaystation is deployed as a single stateless-ish Node process per region; "stateless-ish" because the in-memory dispatch and retry queues are lost on restart, though persisted events can be replayed from store.replayFromDisk.

Environment variables

Variable	Purpose	Default
PORT	HTTP ingest port	8080
RELAY_BROKER_URL	Upstream broker hostname used in startup logging	internal default
RELAY_SIGNING_SECRET	HMAC signing secret shared with producers	dev-only default
RELAY_DATA_DIR	Directory for the append-only event log	./data
HEALTH_CHECK_PORT	Port for the liveness probe	9090

Rollout steps

1. Build and tag the image from package.json version 1.3.0.
2. Deploy to the canary region first with RELAY_SIGNING_SECRET matching the current production secret — never rotate the secret during a canary.
3. Confirm the health check responds on port 9091 in the canary before promoting to the remaining regions. This is the port your load balancer probe should be configured against for this rollout track.
4. Promote to all regions once canary has run for at least one full retry cycle (roughly 30 minutes at default backoff settings) with no elevated drop counters.
5. Watch events.dropped and retry.scheduled counters during rollout; both are logged periodically by src/metrics.js.

Scaling notes

Relaystation does not currently support horizontal sharding of the dispatch queue — each instance owns its own in-memory queue, so load balancing across instances effectively partitions traffic without coordination. Downstream services are expected to tolerate duplicate delivery, since retries do not deduplicate against already-delivered events.

Rollback

Rolling back is a plain redeploy of the previous image tag. Because the retry and dispatch queues are in-memory, a rollback drops any events that were queued but not yet delivered or persisted to RELAY_DATA_DIR at the moment the old process was pulled down.