How do you handle CI/CD for APIs? I’m stuck on how setups with multiple local/staging/prod fit together

Question

We built a CI/CD monorepo -- it makes intuitive sense with local/staging/prod. You push small commits and it auto-deploys. That makes sense when you just have that one pipeline for one app.

But now as we expand, how do you apply that to an API? By design, APIs are more stable -- you aren’t really supposed to change an API iteratively, because things can later depend on the API and it can break code elsewhere. This applies to both internal microservice APIs (like a repository layer you call internally, such as an App Runner FastAPI that connects to your database --/user/updatename), and to external APIs used by customers.

The only solution I can think of is versioning routes like /v1/ and /v2/. But then... isn’t that kind of going against CI/CD? It’s also confusing how you can have different local/staging/prod environments across multiple areas that depend on each other -- like, how do you ensure the staging API is configured to run with your webapp’s staging environment? It feels like different dimensions of your codebase.

I still can’t wrap my head around that intuition. If you had two completely independent pipelines, it would work. But it boggles my brain when two different pipelines depend on each other.

I had a similar problem with databases (but I solved that with Alembic and running migrations via code). Is there a similar approach for API development?

Answer 1

When you’re dealing with APIs across local, staging, and production, the key is to keep the build artifact the same and only swap configurations per environment.

Typical flow:

- Local: run the API with a dev DB or mocks, fast feedback loop.

- CI: run tests, linting, build Docker image (or artifact).

- Staging: deploy the same artifact with staging configs, run integration/end-to-end tests.

- Production: promote the artifact from staging, only configs change.

A few tips:

- Use environment variables for DB URLs, secrets, etc.

- Store configs in a secure place (Vault, AWS Secrets Manager, etc.).

- Automate deployments with blue-green or canary strategies to reduce risk.

This way, you don’t rebuild for each environment — you build once, test in staging, and promote to prod.