feat: add deploy pipeline, container limits, keypair cache and type g…

[Omoboi-dev]

Summary

Closes #225
closes #226
closes #227
closes #228

Four backend hardening issues in one branch — they touch overlapping files
(stellar.ts, Dockerfile, docker-compose.yml).

#228 — Strict mode: replace assertions with runtime validation

The three sites named in the issue:

• config.ts — as "testnet" | "mainnet" → exported StellarNetwork type
  and an isStellarNetwork guard. validateRequiredEnv() now reads
  process.env directly, since the config object is built at import time and
  could never see a bad value. This fixes a config.test.ts case failing on main.
• lib/registry.ts — sim.result! → local isSimulationError guard plus an
  explicit retval === undefined check.
• routes/admin.ts — raw as number[] → entries validated individually and
  copied into a number[], so the type comes from construction.

Also removed while in those files: reason!, result as {...} (now a
ProjectUpdateOutcome discriminated union), (err as Error), the
req.query.x as string casts, and getResult! in stellar.ts. Response body
shapes are unchanged.

Left alone: the as any at stellar.ts:152 — narrowing it requires
restructuring transaction handling, not a type fix. Pre-existing warning, not new.

#227 — Cache the admin keypair

Derived once into a module-level variable instead of per call (previously once
per project per cron cycle). The secret is cached alongside it so a changed
secret rebuilds. Error behaviour unchanged; resetAdminKeypairCache() exported
for tests.

#225 — Container resource limits

512 MB / 0.5 CPU on the backend, 256 MB / 0.25 CPU on Redis, and
NODE_OPTIONS=--max-old-space-size=384 in the production stage only.

The 128 MB gap is deliberate: V8 old space excludes the Node binary and native
buffers, so a ceiling below the limit gives JavaScript heap out of memory with
a stack trace instead of a silent SIGKILL. Redis caps itself at 192mb with
allkeys-lru so it evicts rather than growing into its limit.

#226 — Deployment workflow

New .github/workflows/deploy.yml: push to main → staging, release or v*
tag → production, plus manual dispatch.

• Builds and pushes to GHCR with the built-in GITHUB_TOKEN — no extra secret
• Deploys by digest, so a moved tag cannot change what runs
• Status via the GitHub Deployments API (in_progress → success/failure
  under if: always()), attached to the merge commit so it shows on the PR
• Honours the event_type=deploy dispatch release.yml already fires
• Rollout target is DEPLOY_HOOK_URL, set per environment

New docs/DEPLOYMENT.md covers limits, tuning, pipeline, registry and rollback.

Tests

Four new suites, 54 tests, all passing: keypair cache behaviour, the type guards,
and parsers asserting the compose/Dockerfile limits and the workflow's triggers,
digest pinning and status reporting.

tsc --noEmit and eslint clean on changed files. Suite totals main → branch:
26 → 23 failures (3 fixed, 0 new), 645 → 701 passing, same 11 failing suites.

[drips-wave]

@Omoboi-dev Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits