Operations and deployment
What an operator of a tilcai-infrastructure instance needs to know: probes, mainnet activation, monitor retention, keys and Cloud Run.
Probes
| Path | Answers | Use it for |
|---|---|---|
/health | 200 while the process runs | Platform startup and liveness (Cloud Run, Compose) |
/ready | 200 or 503, with each check | Whether the instance can take payments; monitoring |
Before enabling mainnet transactions
With the instance still read-only (MAINNET_TRANSACTIONS_ENABLED=false), the following call must answer 200. Without sending anything, it checks that the mainnet relayers exist on avalanche-c-chain and mainnet, unpaused and with a signer. A 503 says what fails.
curl -s "$TILCAI_API_URL/ready?mode=transactional"Monitor retention
MONITOR_RETENTION_DAYS (14) for what was delivered and MONITOR_PENDING_MAX_DAYS (90, never less) for what a destination has not received yet. See Monitoring.
Operator keys
Each start syncs TILCAI_API_KEYS: removing a key revokes it. If the sync fails (for instance, a value that is already a third party's issued key), the process exits with code 1 without listening. Fix the list with a new value and restart; npm run tenant stays available.
Cloud Run and single writer
Status: pending validation in staging. The manifest's one-instance limit is per revision, so during a rollout two coexist, each with its worker and its Litestream replicating to the same path. Litestream warns that this can leave the replica impossible to restore. No incident has been observed. Meanwhile: do not tag tilcai revisions (a tagged revision stays up as a second writer) and deploy with no payments in flight. The analysis, test protocol and tool are in PR #46.
Availability depends on your instance. Check /health and /v1/routes before integrating.