Managed cloud hosting for developers

Managed cloud hosting is a strange product category if you think about it for a moment: you rent a server from a cloud company, and then pay a second company to stand between you and it. On paper that sounds like a middleman inserting himself into a perfectly good relationship. In practice, for a lot of developers, it is the difference between shipping applications and maintaining servers.

This page is the developer's map of that arrangement: what crosses the boundary, what you give up, and the bar to hold any platform to before you trust it with real work. It is the frame behind the stack-specific guides in this section.

What crosses the boundary

On the platform's side of the line: provisioning servers, patching the operating system and runtime, issuing and renewing TLS, firewall management, backups, infrastructure monitoring, and applying capacity when the plan allows. On your side: the application, its data model and migrations, the deploy itself, and every incident that begins above the runtime.

Three properties of that boundary are worth internalising before choosing any provider.

It is a contract, not a label. "Managed" describes a family of arrangements, from layers that stop at the operating system to ones that run your database. Two products wearing the same word can take responsibility for different things. The boundary that matters is the one in the specific plan's documentation, read before you commit, not the one the marketing page implies.

It moves with the tier. The same provider draws the line differently per plan: deeper backups here, automatic scaling there. A boundary observed on one plan is not evidence about the next.

The handover takes control with it. The same motion that removes your patching workload removes your root access, your exotic extensions, your custom services. The useful question is never whether managed is better; it is which of the things you would lose you actually use.

The capability bar, per stack

Whatever platform you evaluate, hold it to these. Any honest provider answers them from documentation; anyone who answers "usually" or "we can look into that" has told you something too.

PHP and Laravel. Runtime version selectable per application. The extensions your composer file wants, available without a petition. Queue workers and schedulers that run supervised and restart when they die, because a cron entry approximating a worker is where background work goes to die quietly. Writable storage paths and deploys that do not trample them.

Node.js. A process model that restarts a crashed service and tells you plainly what happens to a failed build. Deploys that run the build against the toolchain version you declared. Environment configuration without shell access. Background workers treated as first-class processes rather than an afterthought behind the web tier.

Databases. Backups on a stated schedule with stated retention, and a restore path you can run yourself. Version upgrades you schedule rather than ones that arrive. A connection budget that accounts for your workers plus your web tier, because a pool sized for one is how Saturday nights get interesting.

The deployment bar

A platform deserves your applications when it clears this:

The repository is the source of truth; deploys come from Git or CI artefacts, and anything modelled on uploading a zip has reintroduced the laptop as a dependency. Environments are separated; production is not where a build is tried for the first time. Rollback is measured in minutes and has been rehearsed, because a rollback that has never been practised is a hope wearing a button.

What it costs, in control

The honest ledger of what you give up: root access by default. Arbitrary system services. Sometimes specific extensions or versions, if the platform curates its stack. The ability to say "I will just fix it at the server level", which is simultaneously the worst and most reassuring sentence in operations.

For most application work none of that is a loss. The 5 percent of the time it is, you go around the platform or open a ticket, and that friction is the tax on the other 95 percent being someone else's job. Developers who hit that 5 percent weekly should be on raw infrastructure and happy about it; the PHP managed vs VPS guide prices both temperaments.

Where the numbers live

Managed platforms bill per server, per month, sized by resources, plus add-ons; raw clouds bill hourly with nothing included. The comparison that matters is total cost of ownership with your own hours priced in, which is what the TCO calculator is for. For the specific platform I run and its trade-offs, the Cloudways review has the detail.