Operations | Monitoring | ITSM | DevOps | Cloud

In our first series post, The New Software Creator, we mapped out a structural shift in the industry: AI is turning non-technical team members into creators of software. In our second post, When Anyone Can Build Software, Deployment Governance Is What Keeps It Safe, we argued that deployment is the single control layer that can secure this explosion of output without choking innovation.

A few weeks ago I went to quantify a trend I had already clocked: our test-writing had climbed, and kept climbing. Where a typical month once brought a handful of new tests, last month brought 436.

This is Post 2 of The Governance Gap series. Post 1, "The New Software Creator," established that the most significant shift from AI isn't developer speed - it's that the population of builders has fundamentally expanded. Something quiet happened in most engineering organizations over the last 18 months.

The conversation about AI and software development has mostly been about velocity. Developers write code faster. Pull requests ship sooner. Backlogs shrink. That part is real, and it matters. But there's a bigger shift happening underneath it, and most engineering leaders I talk to are only just starting to feel its weight. AI hasn't just made developers faster. It has fundamentally expanded who can create and ship software. That changes things in ways that velocity metrics don't capture.

Getting your application deployed feels like finishing a race. You push the code, the containers spin up, the health checks go green, and for a brief moment everything feels solved. Then Day 2 arrives. Day 2 is not a specific date. It is the entire operational life of your application after that first successful deployment. It is the stretch of time that can last years, and it is where most teams quietly discover that deployment was the easy part.

Every application starts the same way: One server. One database. One optimistic engineer saying: “We’ll scale later.” And honestly? That’s usually the right call. Premature scaling is how perfectly normal applications end up with: But eventually, growth happens. Traffic increases. Queries slow down. Deployments get riskier. Your infrastructure starts making unfamiliar noises. This is where scaling enters the picture. Not scaling for conference talks.

Your app is deployed. Users are signing in. Traffic is flowing. Everything is live. Congratulations, give yourself a pat on the back. Okay that's enough. Now it’s time to get back to work because you’ve officially entered the phase where production starts revealing all the decisions you made three months ago, unsure how it would affect you today. Because deploying an app is one half of the job. And, production environments have a way of exposing: This is where operations begin.

A few weeks ago, we shipped cascading replication for PostgreSQL, MySQL and Redis on Cloud 66. Customers can now build replication chains: a primary streaming to a middle replica, which in turn streams to leaves. It reduces load on the primary, supports geographic distribution, and stops you from melting your network when you have a large fan-out of replicas all pulling WAL from the same machine. PostgreSQL has supported cascading replication natively since version 9.1, which shipped over a decade ago.

So far in this deployment series, you’ve: Now we arrive at the layer that quietly determines whether your app thrives… or throws mysterious 2am errors. Step 5 is cloud configuration. This is where your application gets its infrastructure, its environment, and its ability to scale without drama.

So far in this deployment series, you’ve: At this point, you can deploy your app. The question is: do you really want to keep doing it manually? Welcome to CI/CD — where deployments stop being an event and start becoming a system.