Operations | Monitoring | ITSM | DevOps | Cloud

Front-end deployment can embarrass you. Back-end deployment can wake you up at 2:13am. This is where web app deployment stops being about assets and starts being about state, uptime, traffic, and data that absolutely refuses to forget what happened five minutes ago. Back-end deployment is where complexity compounds. Quietly. Patiently. And then all at once. Let's talk about what's actually happening when you "just deploy the API.".

Front-end deployment is usually introduced as the easy part of web app deployment. "Build the assets and push them." Seems simple, right? Yet on the contrary, those 6 words have most likely caused more production issues than most error messages. Because while front ends do look simple, they are actually a delicate stack of assumptions wearing a UI that is misleadingly easy to use.

I've been in this industry since before the word "PaaS" existed. I founded Cloud 66 in 2012 — the same year Heroku was peaking, dotCloud was pivoting to become Docker, and the idea of "just git push and forget about servers" felt like the future. It was the future. Partly. The deployment experience was revolutionary. The business model wasn't. Last week, Heroku announced its transition to "sustaining mode" — no new features, no new enterprise contracts.

Last week, Heroku announced it is transitioning to a "sustaining engineering model." In plain English: no new features, no new enterprise contracts for new customers, and Salesforce is redirecting its investment elsewhere. The platform will be maintained for security and stability, but that's it. If you've been in this industry long enough, you know what "sustaining mode" means.

Let's be honest: everyone says they want continuous deployment. "Ship all the time! Move fast! Break absolutely nothing!" But the only reason any of that is even remotely possible is because of one unsung hero quietly doing the heavy lifting behind the scenes: Ah, the deployment pipeline - aka your code's obstacle course / gauntlet / walk in the park… depending on how well it's behaving.

You know that feeling right before you deploy? The mix of excitement, dread, and the quiet hope that production behaves this time? Yeah — we’ve all been there. That’s why we are big fans of blue-green deployment. It’s one of those DevOps patterns that sounds fancy but is actually just good engineering hygiene — and it can save your morning/afternoon/evening or let’s be honest, your late night.

This is a comparison of various different coding agents. We conducted this prior to the release of Google’s Gemini 3 and hope to update it soon with Google Gemini 3 inclusion.

Like many others, as a company, we are going through a steep learning exercise with coding agents. As we are all learning together how to face the challenges of this new era of coding, I wanted to share our learnings with you and, in turn, benefit from what you have learned in your journey with using coding agents.

We’re excited to announce the rollout of Cloud 66 Deploy v3 — a major evolution of our deployment platform built from the ground up for flexibility, modern workloads, and future growth. While Deploy v2 has served many teams well over the years, Deploy v3 brings a fresh architecture and new capabilities designed for today’s cloud-native needs. Here’s what you need to know.

In our Go projects, we rely on a consistent and battle-tested stack of libraries that help us build reliable, maintainable, and scalable systems. We started using Go in our stack many years ago (before Go v1) and therefore many of our choices have changed over the years. Here in this post, I wanted to share some of the libraries we use regularly to power our Go apps.