Operations | Monitoring | ITSM | DevOps | Cloud

We are excited to announce support for Ubuntu 26.04 LTS Resolute Raccoon on all Cloud 66 products, including registered servers. From this point onward, new applications are provisioned on Ubuntu 26.04 by default, on both x86_64 and ARM64. Don't forget, you can control your target Ubuntu version via the selection dropdown when scaling up via the UI, or through your manifest!

In this series, we have talked about how generative AI is shifting the landscape of software creation. In The New Software Creator, we explored how AI expands who can write code. In When Anyone Can Build Software, Deployment Governance Is What Keeps It Safe, we looked at why the deployment pipeline is the ultimate control point. Finally, in Security at Scale: What Changes When Everyone Can Deploy, we dug into the technical realities of patching, container hygiene, and identity management.

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.