# 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.