Operations | Monitoring | ITSM | DevOps | Cloud

You can deploy on ARM64 servers today across AWS, Google Cloud, Azure, and Hetzner: Graviton, Ampere Axion, Ampere Cobalt, CAX. Pick the chip, pick the cloud, and deploy the stack you already run. There's no feature flag and no waitlist. It's on for every account.

Traffic sources in Deploy v3 now take an optional URL path alongside the domain. Several services in the same application can share a single domain, split by path: example.com serves your web service, example.com/app your dashboard, and example.com/api your API. One domain, one certificate, as many services as you need. No more handing out a subdomain per service just to get traffic to the right place.

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.