Operations | Monitoring | ITSM | DevOps | Cloud

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.

So far in this deployment series, you’ve: Now we arrive at the layer that quietly determines whether your app thrives… or throws mysterious 2am errors. Step 5 is cloud configuration. This is where your application gets its infrastructure, its environment, and its ability to scale without drama.

So far in this deployment series, you’ve: At this point, you can deploy your app. The question is: do you really want to keep doing it manually? Welcome to CI/CD — where deployments stop being an event and start becoming a system.

Now comes the part that makes your application…online or real. Step 3 is where your application gets a proper home address, becomes accessible to users, and stops living as a collection of IP addresses and ports that only you and your team understand. Welcome to DNS, domains, and yep, go live.

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.