Managed cloud hosting has no single correct price, because the work differs from one environment to the next. The cost is set by a short list of drivers: how many environments you run, how they are built, how much load they carry, what coverage window and response commitment you need, and what work is in scope. A sound quote names those drivers and ties the number to a written scope. This guide helps a founder, a finance lead or an IT director budget before the first vendor call.
What are you paying for when you buy managed cloud hosting?
Managed cloud hosting is infrastructure plus the operations work that keeps it running. A quote therefore covers two different costs, and a buyer should ask to see them separately.
The first cost is the infrastructure: compute, storage, network, backups and licences. The cloud or hosting platform charges it, whether that platform is AWS (Amazon Web Services), another public cloud, or the managed provider’s own.
The second cost is the operations work: monitoring, patching, restore tests, incident response, vendor escalation and planned improvements. This is a cost of people and process. It does not shrink because a server is small.
Within operations, providers sell three different layers under the same “managed” label:
- Billing and account administration. The provider resells or consolidates the cloud account. It costs little and changes little about how the environment runs, and buyers often mistake it for management.
- Infrastructure operations. Hardening, patching, backups, monitoring, on-call and incident response. This is the layer most buyers believe they are purchasing.
- Application operations. Deploying your code and running its release pipeline. It is usually a separate engagement with separate access requirements.
Two quotes that look far apart are often quotes for different layers. Ask each provider which layer its number covers. The knowledge base sets out what a managed services provider does on AWS, and what it should not touch.
Which pricing models will you meet, and what incentive does each create?
Five pricing models are common across managed hosting, managed cloud and infrastructure management. Each one rewards the provider for something different, so the model tells you as much as the number does.
| Pricing model | How it works | Incentive it creates | Fits when |
|---|---|---|---|
| Public plan grid | Fixed plans with published limits on sites, visits, storage or resources | The product is standardized. Usage above a limit becomes overage or a forced upgrade. | Your workload is standard and you want to buy without a sales call |
| Per user or per seat | A monthly fee for each employee supported | Cost follows headcount | You are buying office IT support. It is the wrong category for production hosting. |
| Percentage of cloud spend | A share of your monthly cloud bill | The provider earns more when the bill grows, including through waste | The footprint changes quickly and you accept a weaker cost-control incentive |
| Hourly or per ticket | You pay for time or for each request | The provider earns more when more goes wrong. Monthly cost is hard to forecast. | The work is occasional and no ongoing coverage is needed |
| Fixed quote for a written scope | A fixed monthly retainer or project price, scoped per environment, per site or per server | The provider earns the same whether or not your bill falls. Work outside the scope needs a new quote. | You run production environments that need ongoing coverage and a predictable cost |
No model is wrong in every case. Avoid a model whose incentive works against the outcome you want.
What drives the quote for managed cloud hosting?
Providers that price against a scope look at roughly the same five groups of drivers. If you can describe each group for your own environment, you can predict which way a quote will move.
| Driver group | What the provider looks at | Why it moves the quote |
|---|---|---|
| The environment | Number and class of environments (production, staging, development), architecture complexity, redundancy such as high availability or a second region, runtime and database stack | Each environment is patched, monitored and backed up. Redundancy multiplies the systems to keep in step. |
| The load | Traffic profile, concurrent load, data volume, autoscaling behaviour | Load sets the infrastructure size and the amount of capacity planning |
| Coverage and response | Coverage window (business hours, extended, or 24/7), the response commitment for each severity, monitored assets and custom checks | Coverage is a staffing cost. It is the driver buyers underestimate most. |
| The estate | Number of sites, accounts or servers. For agencies, the number of client sites and whether the work is white-label or co-managed. | More units mean more patching, more backups and more tickets |
| The work in scope | Monthly project hours, an improvement roadmap, postmortems, a migration or consolidation project, compliance or data-residency needs, release cadence | This is project and advisory time on top of keeping the environment running |
Some products add their own shape. A managed application platform, often called PaaS (platform as a service), usually charges for the resources consumed, and some providers add a platform fee per environment. Agency arrangements can pair a base retainer with per-site billing. Agencies can compare models in the guide to hosting for agencies that manage multiple WordPress sites.
Why does 24/7 coverage cost so much more than business hours?
Covering one seat around the clock takes several people once nights, weekends, vacations and turnover are counted. That staffing arithmetic is the cost behind every 24/7 plan, whether you build the rotation yourself or buy it. Stack Harbor’s scoping page puts an internal 24/7 rotation at six or more full-time engineers once vacation, sickness and burnout are covered. The knowledge base explains what a real overnight monitoring rotation takes to staff.
Buy the coverage your customers need. If your customers are asleep when your team is, business-hours or extended coverage may be the honest fit.
Coverage can also be ramped. In one example scenario, a B2B SaaS company rebuilt its on-call with a runbook-writing sprint in the first month. It then moved in phases from extended business-hours coverage to full 24/7 by month three.
An SLA (service level agreement) that covers incidents usually commits to a response time, meaning how fast a person acknowledges the incident and starts work. Resolution time is usually a target and not a commitment. Ask each provider which of the two its figure describes. If you are weighing a hire against a contract, the comparison of hiring a DevOps engineer or outsourcing operations works through coverage and continuity.
Why do many managed providers not publish prices?
A managed provider can publish a price grid when it sells a standardized product, and platform hosts with fixed plans do. A provider that operates custom production environments usually cannot. Two environments with the same server count can differ widely in redundancy, coverage, compliance work and project hours, so one grid would misprice at least one of them.
Without a grid you cannot shortlist on price alone, so ask each provider for three things before any call.
- The unit of pricing: environment, site, server, user, or share of spend.
- The list of drivers that change the number.
- The steps that produce the quote, and what you keep if you do not sign.
Treat a firm number offered before the provider has seen your environment as an estimate. The difference can arrive later as change orders.
Does managed cloud hosting lower the infrastructure bill?
Managed cloud hosting sometimes lowers the infrastructure bill, and sometimes the bill rises. Both outcomes can be the right result. Stack Harbor’s example scenarios include both directions. Each figure below describes one engagement and is not a typical result.
- In one example scenario, a dual-region data residency build for a Canadian SaaS raised infrastructure cost by 38%, from running a second region and the duplicated tooling that came with it. The example scenario reports attributable enterprise revenue of roughly seven times that increase in the same window.
- In one example scenario, a Laravel monolith moved to a managed application platform and infrastructure cost rose 11%. The return was about sixty hours of founder engineering time each month.
- In one example scenario, a re-architected move from AWS to managed cloud cut the monthly run-rate by 54%, with backups, monitoring and the operating fee included. The same proposal estimated that remediation without leaving AWS would have cut the bill by 28%.
Measure the result in your own numbers. Record the current infrastructure bill, the internal hours spent on operations each month, and the cost of recent incidents. Then compare the same three figures after the change. For a SaaS business, the knowledge base shows how to work out cost per customer on managed cloud. Finance teams can start with AWS billing analysis that a finance team can read. Stack Harbor’s cloud cost calculator gives a rough, benchmark-based estimate of how much of a cloud bill is likely wasted.
How do you compare two managed hosting quotes?
To compare two managed hosting quotes, split each one into three parts.
- The plan fee. The recurring number on the first page.
- The overage terms. What happens when traffic, storage, sites or hours exceed the plan.
- Your own hours. The time your team will still spend on everything the plan excludes.
The plan fee tells you the least of the three. A low fee with open-ended overage and a long exclusion list can cost more than a higher fee with a complete scope. Then take this checklist into each vendor call.
- Which layer does the quote cover: billing administration, infrastructure operations, or application operations?
- What is the unit of pricing, and what makes the number change after signing?
- What is the coverage window, and is the response figure an acknowledgement or a resolution?
- Which systems are monitored, and are backups restore-tested inside the scope?
- How is out-of-scope work priced, and is it quoted before it starts?
- Is a migration included, separate, or required as a condition of service?
- What documentation do you keep if you leave?
- Does any service credit apply to availability, to response time, or to neither?
More selection criteria are in the guide to what to look for in a managed hosting provider.
When is managed cloud hosting worth the cost, and when is it the wrong purchase?
Paying for managed operations tends to be worth the cost in these conditions.
- Production downtime costs you revenue or renewals, and nobody on the team owns operations.
- One engineer carries on-call alone, with no backup and no written runbooks.
- Patching, restore tests and monitoring keep slipping behind product work.
- Customers or auditors ask for evidence of controls that your team cannot produce today.
A managed contract is the wrong purchase in these conditions.
- You have a full-time operations hire’s worth of steady work. Hire the person, especially if the infrastructure is your product.
- Your entire footprint is one instance and a storage bucket. A managed contract is overhead at that size.
- Two or more engineers already own operations. Adding a provider splits ownership unless the scope split is explicit.
- Your team is two developers. A one-time pipeline build with documentation may be the right size.
- You want to buy from a public price grid without a scoping call. A platform host with published plans is the right category, and a commodity managed WordPress host suits a single standard site.
- The alerts come from defects in the application itself. That is engineering work, and neither an operations hire nor a managed provider fixes it.
Teams with in-house cloud skills may do well on plain AWS. The decision framework for managed cloud versus AWS for a small or mid-sized business covers that choice.
Where Stack Harbor fits
Stack Harbor is a Canadian-owned managed cloud operations provider (MSP) for production environments, headquartered in Montréal. It serves SaaS companies, agencies and publishers, typically organizations of roughly 5 to 200 people that run production systems without a 24/7 operations team of their own.
Stack Harbor does not publish prices and has no published rate card. Engagements are scoped per environment, per site or per server, never per user. Stack Harbor does not quote a percentage of the cloud bill and does not bill by the ticket. The number is a fixed monthly retainer or a fixed project price, produced after a written assessment that the buyer keeps whether or not they sign. The price is fixed for the scope in the agreement, and anything outside that scope is quoted separately before it starts. Pricing for Cloud PaaS, its application platform, combines a platform fee per environment with the resources used. The full method is on the page that explains how Stack Harbor scopes and prices an engagement.
Hosting with Stack Harbor is not required. The ongoing operations offer, Managed Cloud Ops, covers environments on AWS, Azure, Google Cloud, OVH, DigitalOcean and dedicated servers. It also covers environments on Stack Harbor’s own infrastructure in Canada, in two Montréal data centres. Coverage is scoped as business hours, extended, or 24/7. On plans that include incident coverage, the published SLA commits to an acknowledged response within 15 minutes for Severity 1 and 60 minutes for Severity 2. Resolution is a target, not a commitment.
This model is a poor fit for a buyer who needs a public price grid to self-serve. A team that wants the drivers on paper before the number can request a written assessment of its environment, then check the quote against the driver table above.
