Shipping should be boring. The goal of our production path is simple: a reviewed merge should trigger tests, build the artifact once, and promote it through AWS without a human copying secrets into a terminal.
The shape of the pipeline
We use GitHub Actions as the entry point, short-lived AWS credentials through OIDC, and account-scoped IAM roles with the smallest deploy permissions each workflow needs. The app build is deterministic, the infrastructure is declared in code, and production deploys are gated by protected environments.
What matters most
Long-lived access keys are the first thing we remove. OIDC means every workflow run proves its identity to AWS and receives temporary credentials for only that run. That gives us traceability without secret rotation drama.
The second guardrail is environment separation. Preview, staging and production should not be branches with wishful naming. They need separate AWS resources, separate permissions and clear promotion rules.
Our deploy checklist
- Build and test before any AWS mutation.
- Pin deployment roles to repository, branch and workflow claims.
- Keep production approval explicit.
- Emit deploy metadata so support can answer “what changed?” quickly.
- Roll forward with small changes instead of hand-editing cloud state.
This is the same mindset we apply to customer platforms: automate the happy path, remove credentials from laptops, and make production changes observable.