Operations | Monitoring | ITSM | DevOps | Cloud

We are witnessing the fastest expansion of the software development lifecycle in history. Generative AI tools have turned every developer into a hyper-productive builder, and in some cases, turned non-technical team members into creators of production-bound services. But this speed comes with a hidden cost. When the volume of code grows exponentially, the surface area for failure grows with it. The real challenge of modern software engineering is not Day 1 code generation; it is Day 2 operations.

When we launched our Governance Gap series, we set out to explore how the explosion of AI-assisted engineering changes the risk profile for modern software organizations. We looked at the rise of The New Software Creator and analyzed why deployment governance is what keeps teams safe when code production accelerates. We also mapped out the realities of security at scale and defined who owns governance accountability.

To deploy an application we haven't seen before, we need two things out of its repository. One is a Dockerfile that builds it. The other is a service definition saying what runs, which ports it listens on, which databases it needs, and what environment variables it expects. Customers arrive with a git URL, and we figure out the rest. We even do the tricky task of generating a Dockerfile if it doesn't already exist in the codebase. We've built a solution for this twice already.

An AI model can write a fully functioning microservice in about fifteen seconds. If you hook it up to a pull request pipeline, it can generate migrations, write unit tests, and suggest refactors before your lead engineer has finished their first cup of coffee. We are entering an era of unprecedented code velocity. But code is not an application, and shipping is not operating.

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.