Deployment & Operations
Getting code from a change set into production involves several systems working together. This section explains every step of that journey — from how the software is built, to how it gets tested, pinned in Kubernetes manifests, vendored into the deployment repository, and deployed across multiple environments.
If you're new to the project, start with the CI/CD & Release Engineering page. It walks through the entire pipeline end-to-end in the order things actually happen.
The Big Picture
The diagram below shows the full path a code change takes. Don't worry if it looks like a lot — each step is explained in detail in the linked pages.
In short: application source and deploy manifests live in lana-bank, while environment-specific infrastructure and promotion gates live in galoy-deployments.
Two Repositories, Two Pipeline Roles
| Repository | What lives here | What its CI does |
|---|---|---|
| lana-bank | Application source code, Docker image build, shared Kustomize deploy tree, and reusable OpenTofu modules | Runs tests on PRs, builds release images, pins image digests in deploy/, and validates releases with testflight |
| galoy-deployments | Per-environment OpenTofu configs, Kustomize overlays, vendored lana-bank deploy inputs, and Cepler gating rules | Deploys to staging, QA, and production — in that order, with safety gates between each |
The Technology Stack
Where to Go Next
- Build System — How Nix builds work, how the Cachix binary cache keeps things fast, and how Docker images are produced.
- CI/CD & Release Engineering — The main guide. Walks through every step from a PR all the way to production, including GitHub Actions, Concourse pipelines, testflight, Cepler environment gating, and production promotion.