Operations | Monitoring | ITSM | DevOps | Cloud

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.