Deployment model is two separate questions that share a name. The first is where your infrastructure lives: public cloud, private cloud, hybrid, multi-cloud, or community cloud, which is the textbook list. The second is how a new version of your software replaces the old one: recreate, rolling, blue-green, canary, or a feature flag. Most search results answer only the first and most engineers actually need the second. For a small product, the honest answers are public cloud for the first question and rolling with a rollback button for the second, and the rest of this post is about when those defaults stop being right.
The textbook version of this topic was written for procurement, not for anyone shipping code. This one covers both meanings and spends its time on the decision each one drives, because a deployment model you cannot act on is trivia.
Table of contents
- Meaning one: where the infrastructure lives
- When private or hybrid stops being over-engineering
- Meaning two: how a release replaces the previous one
- The health check is the whole strategy
- Schema changes are where rolling deploys break
- Choosing without a committee
- How this fits the rest of the stack
- FAQ
Meaning one: where the infrastructure lives
The classic taxonomy has four or five entries, and each is a statement about who owns the hardware and who else shares it.
- Public cloud. A provider owns the data centre and rents slices of it to many customers. You pay for what you use, you get regions and services you could never build, and you accept that the machine under your process also runs other tenants.
- Private cloud. Cloud-style automation on hardware dedicated to one organisation, either in its own building or rented as a dedicated pool from a provider. Control and isolation in exchange for capital cost and a team to run it.
- Hybrid cloud. Some workloads private, some public, with networking between them. Common when a regulated database must stay in a specific place while the web tier scales elsewhere.
- Multi-cloud. More than one public provider, either deliberately for resilience and price pressure, or accidentally because two teams chose differently.
- Community cloud. Shared infrastructure for organisations with a common compliance need, such as a group of hospitals or a government consortium. Rare outside those sectors.
For almost every startup, agency and independent developer, the answer is public cloud and the interesting question is which layer of it. Renting raw virtual machines is public cloud. So is a platform that takes a repository and returns a running service with logs. The difference is not the deployment model in the textbook sense but how much operating system you want to own, which is the question that actually changes your week.
When private or hybrid stops being over-engineering
Private and hybrid deployments have real justifications, and they are narrower than the sales material suggests. Data residency laws that name a jurisdiction and forbid a shared tenancy. Hardware that a public region does not offer, such as a specific accelerator or a licensed appliance. A workload so steady and so large that owning the machines is cheaper over three years than renting them. An existing data centre lease that is not going away.
What is not a justification is a general feeling that private is safer. A well-run public cloud tenancy with private networking, encrypted storage and scoped credentials is more secure than most self-managed racks, because the provider patches the hypervisor faster than an internal team patches anything. The security argument for private cloud is a compliance argument wearing a different coat, and it should be evaluated as one: which specific clause requires it, and what does that clause cost to satisfy.
Hybrid deserves a particular warning. Two environments means two sets of networking, two identity systems, two monitoring stacks and a link between them that becomes the most fragile part of the architecture. Teams adopt hybrid as a transition and discover a decade later that the transition became the design. If you must go hybrid, write down the date the private half is supposed to disappear.
Meaning two: how a release replaces the previous one
This is the deployment model engineers argue about, and the choice is about how much downtime and how much risk a release is allowed to carry.
- Recreate. Stop the old version, start the new one. Seconds to minutes of downtime, zero complexity. Fine for internal tools, staging, and anything with a maintenance window.
- Rolling. Replace instances one at a time behind a load balancer, so some capacity is always serving. No downtime if the health check is honest. Both versions run at once for the duration, so the database schema and the API must tolerate that.
- Blue-green. Stand up a complete second environment with the new version, switch traffic to it, keep the old one warm for rollback. Instant cutover and instant rollback, at the cost of double the infrastructure during the switch.
- Canary. Send a small percentage of real traffic to the new version, watch the error rate and latency, widen the percentage or abort. The safest strategy and the one that needs the most tooling: traffic splitting, per-version metrics, and a decision rule.
- Feature flags. Deploy the code dark, switch behaviour on per user or per percentage at runtime. Decouples deploying from releasing, which is the real goal of the whole list.
Nobody needs all five. A small service does rolling deploys with a health check, keeps the previous build available for rollback, and uses a feature flag for the two or three changes a year that are genuinely scary. That covers almost everything blue-green and canary cover, at a fraction of the setup.
The health check is the whole strategy
Every zero-downtime model depends on the platform knowing whether the new instance is actually working, and that knowledge comes from a health endpoint. A health check that returns 200 the moment the process starts, before it has connected to the database or loaded its configuration, turns a rolling deploy into a rolling outage: the load balancer sends traffic to an instance that cannot serve it, the old instance is already gone, and the deploy tool reports success.
A useful health check does three things: it answers only after startup is complete, it fails if a hard dependency such as the primary database is unreachable, and it stays cheap enough to be called every few seconds. Everything else about the deployment model is arithmetic once that endpoint is honest.
app.get("/healthz", async (req, res) => {
if (!appReady) return res.status(503).send("starting");
try {
await db.query("SELECT 1");
res.status(200).send("ok");
} catch (err) {
res.status(503).send("db unreachable");
}
});Schema changes are where rolling deploys break
The unglamorous constraint on every model except recreate is that the old and new versions run at the same time, against the same database. A migration that renames a column breaks the old version instantly; a migration that drops one breaks it on the next request. The pattern that works is expand and contract: add the new column, deploy code that writes both and reads the new one, backfill, then remove the old column in a later release once no running version needs it.
This is slower than a single migration and it is the price of not having a maintenance window. Teams that skip it end up choosing recreate by accident, with the downtime arriving as an incident instead of a scheduled notice.
Choosing without a committee
Two questions settle both meanings for most projects. Is there a legal or hardware reason the workload cannot share a public region? If not, public cloud, at whichever layer matches how much OS you want to own. Can the service tolerate a few seconds of downtime per release? If yes, recreate is fine and you can stop reading; if no, rolling with a strict health check, a retained previous build, and expand-and-contract migrations.
The managed platform version of that second answer is what most hosted services provide out of the box: a build from the repository, a health check before traffic switches, the previous deploy kept for a one-click rollback, and logs for both. That is a rolling deployment model with a blue-green rollback, and it needs no design document.
How this fits the rest of the stack
The deployment model decides how many environments you pay for at once. Blue-green doubles the compute during a release; hybrid doubles the networking permanently; a rolling deploy on a managed service costs one plan and nothing more. The RunxBuild hosting calculator is a quick way to see what an extra environment or a larger plan actually adds to the monthly total before committing to a strategy that needs it. On the platform side, every service deploy keeps the previous build for rollback and can autoscale between plans, which is the rolling model with the rollback button already attached.
Useful related references:
- What Is a Consignment Shop? The Model, and What It Needs Online
- AWS S3 Cost Estimator: The Right Way to Model S3 Spend
- Getting the Same Response Each Time From a Model in n8n
- Services on RunxBuild
FAQ
What are the main cloud deployment models?
Public cloud (shared provider infrastructure), private cloud (dedicated infrastructure for one organisation), hybrid (a mix of both with networking between them), multi-cloud (more than one public provider) and community cloud (shared by organisations with a common compliance need). Most small teams use public cloud.
What is the difference between a deployment model and a deployment strategy?
In practice the terms overlap. Deployment model usually refers to where infrastructure lives (public, private, hybrid). Deployment strategy usually refers to how a new release replaces the old one (recreate, rolling, blue-green, canary). Both get called deployment model in search results, which is why this post covers both.
Which deployment strategy should a small team use?
Rolling deploys behind a health check, with the previous build retained for rollback. That gives zero downtime and a fast recovery path without maintaining a duplicate environment. Add a feature flag for the rare change that needs a gradual release rather than adopting a full canary pipeline.
When is hybrid cloud the right choice?
When a specific workload has a legal, hardware or cost reason to stay on dedicated infrastructure while the rest of the system benefits from public cloud scaling. It is the right transition state for many migrations and a poor permanent design, because it doubles networking, identity and monitoring.
Why do rolling deployments break on database migrations?
Because old and new code run simultaneously against the same database during the rollout. A rename or drop breaks the old version. Use expand-and-contract: add the new column, deploy code that handles both, backfill, then remove the old column in a later release.