Instance Topology
Once compute is provisioned via Public Cloud building blocks rather than a single fixed VPS, a real question follows: how many instances, split by what.
Single instance
Everything runs on one VM — one deployment platform, every service, one pool of CPU/RAM shared across all of it. The practical case for this: workloads are rarely steady. Bursty, uneven load pools better across one shared capacity than it does across several fixed-size instances each capped at their own ceiling — a spike in one service can draw on capacity idle elsewhere instead of stalling the moment its own instance hits its limit. Simpler too: one thing to provision, patch, and monitor.
The cost: no blast-radius containment. A compromised or crashed service shares its failure with everything else on the same box, including the deployment platform managing it.
Split by role
Dedicated instances per role instead — commonly, separating the deployment/monitoring platform itself from the services it manages, so a problem with one doesn't take the other down with it. See Public Cloud for the fuller blast-radius reasoning. Right-sized resources per workload are part of the appeal too — a lightweight management instance doesn't need to be sized for whatever a user-facing service occasionally spikes to.
The cost: no shared capacity pool. Each instance is capped at its own fixed allocation regardless of what's idle next door, and there's more to provision, patch, and monitor as separate units.
Choosing between them
Not a permanent choice, and not the same answer for every setup. The deciding factor is usually how predictable the load actually is: steady, well-understood workloads tolerate a fixed split fine; bursty, uneven ones lose more to per-instance ceilings than they gain from isolation. Migrating between them isn't free either — going from a hand-provisioned single box straight to a multi-instance, infrastructure-as-code-managed split means adopting IaC and re-architecting at the same time, which is its own reason to sequence the two separately rather than combine them into one migration.