Managed Hosting vs Ongoing Support: What You Actually Need

When a website is launched, two questions often go unanswered: who looks after the server it runs on, and who looks after the site itself? Many businesses assume their host does both. Others assume the developer who built it is still keeping an eye on things. Often, nobody is.

October's security fixes showed what that costs. In one week, Laravel fixed an authentication bypass, Node.js fixed ten vulnerabilities, and PHP fixed PHP2Shell, a pair of flaws that can let an attacker with no login run code on a server. The sites that were patched quickly were the ones where someone knew it was their job. The ones that were not tended to fall into the gaps between a host, a former developer and nobody in particular.

This post explains what managed hosting and ongoing support each cover, why a business site needs both, and what to ask before you pay for either.

Two layers, two jobs

A website is not one thing. It is an application, the code that makes your site do what it does, running on a server. Each layer gets its own security fixes, and each needs someone responsible for applying them.

Managed hosting looks after the server

The server is the computer your site runs on, and the software that keeps it running. Managed hosting means a named team is responsible for:

• The operating system, patched promptly when fixes are released.
• PHP or Node.js, kept on a supported version and updated when security fixes land.
• The web server and database, configured securely and kept current.
• Backups, taken off the server, kept for a sensible period, and restored now and then to check they work.
• Monitoring, so someone is told when the server goes down or behaves strangely.

Ongoing support looks after the application

The application is your site: the framework it is built on, such as Laravel, the third-party packages it uses, and the code written for your business. Ongoing support means someone who knows that code is responsible for:

• Framework and package updates, with security fixes applied within days and critical ones within hours.
• Checking the site still works after each update, ideally with automated tests.
• A planned yearly upgrade, so the site never drifts onto unsupported versions.
• Watching for announcements, rather than hearing about them from the news.
• Small fixes and changes, by someone who already understands how the site fits together.

No host will do the second list. A host does not know your code, and should not be changing it.

Where the gaps are

Most missed updates are not caused by anyone being careless. They happen because each party reasonably assumes something is someone else's job.

The host assumes the developer has it

Many hosting platforms only update the operating system automatically, not PHP or Node.js. Laravel Forge, for example, does not install a PHP security fix on its own. The host considers the server patched. The PHP version your site runs on is still exposed.

The developer assumes the host has it

A developer who built the site and moved on may reasonably think the hosting company handles security. They are not watching for framework fixes, because nobody is paying them to. If your developer has gone entirely, our guide to taking over an abandoned website covers how to get back in control.

Updates that look done but are not

Even when PHP is updated, long-running processes such as queue workers keep running the old version until they are restarted. An update can be installed, ticked off, and still not in effect. Someone needs to know the site well enough to restart what needs restarting.

Nobody owns the whole picture

When the server, the application and the backups are split between different people, nobody can answer "are we affected?" quickly. In a week like October's, that delay is the risk.

Shared hosting, managed servers and support retainers

The options are not all equal, and the right one depends on what your site does.

Shared hosting

Your site shares a server with many others, and the host controls almost everything.

• Good for: small brochure sites with few moving parts and a tight budget.
• The catch: only the host can update PHP, so when a critical fix lands you wait on their timetable. Some hosts patched within hours in October; others did not, and their customers had no way to tell which kind they were with.
• Support: none for your application. That is still your problem.

A managed server

Your site runs on its own server, set up and looked after by a team that answers to you.

• Good for: sites that take payments or bookings, hold customer data, run background jobs, or simply matter to the business.
• The benefit: PHP and the operating system are updated when you need them updated, not when a shared host gets round to it.
• Support: still a separate question unless the same team covers it.

A support retainer

A monthly arrangement with a developer or team who looks after your application.

• Good for: any site your business relies on, whatever it is hosted on.
• The benefit: framework and package fixes applied promptly by someone who knows the code, plus planned upgrades and small changes.
• The catch: it does not cover the server unless it is paired with managed hosting.

Most business sites need the second and third together. That does not have to mean two suppliers. When one team looks after both, there is no gap to fall through.

When you do not need both

Honesty matters here. A simple brochure site on a current version of WordPress or a static site builder, with a handful of well-known plugins, on a reputable host that updates PHP promptly, does not need a full retainer and a managed server. Turning on automatic updates, keeping the plugin list short and checking in occasionally may be enough.

The case for both gets stronger the more your site does. Payments, bookings, member logins, customer data and connections to other systems all raise the cost of a missed update. So does a site built specifically for you, because nobody else will be patching it.

What to ask your host

1. What exactly do you update automatically? The operating system only, or PHP and Node.js too?
2. How quickly did you apply October's PHP fix? The answer should be a date.
3. Where are backups stored, and when was one last restored? Off the server, and recently.
4. Who is told if the site goes down? It should not be your customers who notice first.
5. Can I move PHP to a newer version when I need to? On shared hosting the answer is often no.

What to ask about support

1. Who is responsible for framework and package updates? A named person or team, not "we will look at it if something breaks".
2. How quickly are security fixes applied? Days for most, hours for critical ones.
3. How do you know the site still works afterwards? Automated tests are better than a quick look.
4. What does my site run, right now? You should be able to see this without asking.
5. What happens when the framework releases a new major version? There should be a plan, not a shrug.

If the answers are vague, the gap is probably already there. Our posts on whether your old CMS is now a security risk and WordPress security for business cover what that gap tends to look like in practice.

How we can help

At AugmentBLU we look after both layers for the sites we support, so one team is accountable for the whole thing. Our managed DevOps covers the server: PHP and system updates, backups that are tested, monitoring and deployments. Our support and maintenance retainers cover the application: security fixes, framework and package updates, planned yearly upgrades, and a dashboard showing exactly what your site runs.

For the sites we looked after, October's fixes were routine. The updates went on, the processes were restarted, and our clients did not need to do anything.

If you are not sure who is responsible for your site's updates, get in touch. We will check what it runs and how it is hosted, and tell you plainly where the gaps are and whether you need us to fill them.

We reply within 24 hours.