In Multi-Tenancy Architecture for SaaS we worked through how a single deployment serves many organizations without their data or traffic bleeding into each other. That article was about the shape of the data and the request path. This one is about what happens the moment you need to ship a change to that system. You need to do it without taking the system down, and without waking up at 2am because a migration ran against production before the code depending on it finished deploying.
This is part of the Full Stack SaaS Masterclass, a build-it-for-real series that takes a multi-tenant SaaS from an empty folder to production. We're now in Module 4, the production module, and CI/CD is the right place to start it. Everything else in this module, monitoring, logging, feature flags, scaling, assumes you already have a pipeline that reliably gets code from a pull request into a running environment.
I'm assuming the monorepo layout from earlier in the series: a Next.js frontend, a NestJS backend, and a handful of shared packages, all managed with Turborepo. If you're on a different monorepo tool the specifics change but the reasoning underneath doesn't.
Why CI/CD is a different problem in a monorepo
