Managed hosting means BroadNet runs the server layer for you: operating system patching, monitoring and alert handling, backups and restore tests, security hardening, and changes made inside agreed change windows. Your application code, content and users stay yours. What is in scope, what is out, and the response targets are listed in your written order, not implied.
What "managed" covers
"Managed" is one of the vaguest words in hosting. Some providers mean a control panel; others mean they will restart a server if you ask. Here it means six specific duties, each with a defined cadence in your order.
Patching
Operating system and server package updates on a set cadence, with urgent security fixes applied sooner under an emergency change process. Kernel updates include the reboot, scheduled in a change window. NIST SP 800-40 treats patching as routine maintenance with planned and emergency paths; we work the same way.
Monitoring
Checks on availability, CPU, memory pressure, disk space and I/O, certificate expiry and backup success, with alerts going to BroadNet first. The checks and what triggers a human response are listed in the order.
Backups and restores
Scheduled backups with stated retention, at least one copy away from the server, and restore tests at an agreed interval, with the result reported to you.
Hardening and changes
A documented baseline (SSH keys only, minimal open ports, host firewall, automatic log rotation, separated accounts), drawn from published benchmarks such as CIS. Configuration changes you request are made in change windows you agree.
In scope and out of scope
This is our default scope. Your written order may move items between columns; anything not listed is out of scope until it is added in writing.
| Area | In scope | Out of scope by default |
|---|---|---|
| Operating system | Updates, security patches, reboots in change windows, release upgrades planned with you | Running an OS release past its vendor end of life |
| Server software | Web server, PHP or other runtime, database engine, cache: install, configure, patch | Licensed third-party software we have not agreed to support |
| Monitoring | Agreed checks, alert triage, first response, escalation to supplier | Application-level business metrics, user analytics |
| Backups | Schedule, retention, off-server copy, failure alerts | Backing up systems outside the managed servers |
| Restores | Restore on request, periodic restore tests with written results | Restoring data you deleted before the oldest retained backup |
| Security | Hardening baseline, firewall rules, SSH access control, log retention on the server | Application code security review, penetration testing, compliance audits |
| Changes | Server configuration changes in agreed windows, up to the volume in your order | Large projects (migrations, re-architecture) unless quoted separately |
| Application | Keeping the runtime it needs healthy | Your code, deployments, plugins and themes, content, user accounts |
| Confirmed at quote | Newsletter sending, deliverability campaigns |
Ask any managed provider for this table before you sign. If they cannot list what is out of scope, you will find out during an incident.
Who managed hosting is for
A good fit
- Your site or app earns money or serves staff, and nobody on the team is a server administrator.
- The person who used to run the server has left, and nobody wants the pager.
- You need written change control and backup evidence for your own auditors or clients.
- Developers should spend their time on the product, not on kernel updates.
Not a fit
- You want to change anything on the server at any time without a process: take a self-managed VPS.
- A standard website with email: shared hosting already has no server to manage.
- You want someone to build and maintain your application: that is development work, quoted separately if at all.
Change windows and incidents
Every managed contract sets two clocks.
Planned changes
Routine patching and requested changes happen in a recurring change window agreed with you, for example a weekly slot outside your busiest hours. Before each window you are told what will change; after it, what did change. Emergency security fixes can be applied outside the window under a defined emergency process, and the order states who approves them.
Incidents
When monitoring raises an alert, it is classified by severity. The order defines each severity in terms of impact on you (site down, degraded, single function broken, question) and fixes the response target for each. We do not publish generic response times, because a promise that is not in your contract is not a promise.
- Detect. Alert fires or you report a problem.
- Triage. Classify severity against the definitions in your order.
- Respond and restore service. Fix, roll back, fail over or restore from backup.
- Report. What happened, what was done and what will prevent it next time.
What you can specify
| Item | What you choose |
|---|---|
| Underlying server | VPS, virtual server or cloud layout |
| Patching cadence | Routine window frequency and emergency process |
| Monitoring | Which checks, alert recipients, hours covered |
| Backups | Frequency, retention, off-site copy, restore test interval |
| Access | Whether you keep root, a limited sudo account or deploy-only access |
| Change volume | Included changes per month; extra work rate |
| Reporting | Monthly report contents: patches applied, alerts, restore tests |
| Response targets | Per severity Confirmed at quote |
Reference configurations
| Shape | Servers | Operations | Price |
|---|---|---|---|
| Managed single server | 1 VPS, 4 vCPU / 8 GB | Monthly patch window, core monitoring, daily backups, quarterly restore test | Price shown at quote |
| Managed app and database | 1 app server plus 1 database virtual server on a private network | Weekly patch window, app and database monitoring, database dumps plus disk backups, monthly restore test | Price shown at quote |
| Managed small fleet | 3 to 10 cloud instances with load balancer | Rolling patching, fleet monitoring, change volume sized to the team | Price shown at quote |
Use cases
An online store with no IT staff
The store's agency builds features; nobody owns the server. Managed hosting covers patches and restores, and the agency deploys code through a deploy-only account, so a plugin update can never also break the operating system.
A line-of-business app after a staff change
The developer who set up the server has moved on and nobody knows when it was last patched. Onboarding starts with an audit against the hardening baseline, then the server moves into the regular patch cycle.
Evidence for your own clients
A firm whose clients ask how their data is protected gets monthly reports of patches, backups and restore tests, which answer most of those questionnaires with facts.
Managed hosting compared
| Question | Shared hosting | Self-managed server | Managed hosting |
|---|---|---|---|
| Custom software | Limited to the panel | Anything | Anything agreed in scope |
| Who patches | Provider | You | BroadNet |
| Who restores | You, from panel backups | You | BroadNet, tested |
| Change process | None needed | Yours to define | Agreed windows |
| Your effort | Low | High | Low on the server; you still own the app |
The virtual hosting comparison includes a worked example of the hours a self-managed server takes.
Responsibility matrix
| Task | BroadNet | Supplier | You |
|---|---|---|---|
| Hardware, hypervisor, data center | - | Owns | - |
| OS patching and reboots | Owns | - | Agrees window |
| Monitoring and alert response | Owns | - | Receives reports |
| Backups and restore tests | Owns | Stores | Reviews results |
| Hardening baseline and firewall | Owns | - | - |
| Application code and deployments | - | - | Owns |
| Content, data quality, user accounts | - | - | Owns |
| Response targets per severity | Confirmed at quote | - | - |
The shared responsibility guide explains why the application line always stays with you.
How buying works
- Tell us what you run via the configurator or contact: servers, software, data size, busy hours and who deploys code.
- Scope review. We draft the in-scope and out-of-scope list and the change window with you.
- Written order. Scope, severity definitions, response targets, backup and restore-test schedule, reporting, supplier, region and price.
- Onboarding. New build, or an audit and remediation of your existing server against the baseline, then a first restore test.
- Regular cycle. Patch windows, monthly reports and scope reviews when your needs change. See support and the backup guide.
Frequently asked questions
Do I keep root access?
You can, but it changes the responsibility split: if you and we can both change the server, the order must say who is accountable for what. Many clients take a limited or deploy-only account instead.
Will you update WordPress and plugins?
Not by default. Application software updates are out of scope unless added to your order, because they can change how your site behaves and should be tested by whoever owns the site.
What are your response times?
They are set per severity level in your written order. We do not publish a general figure, because the only response target that counts is the one in your contract.
Can you take over a server I already have?
Often, yes. We start with an audit against our hardening baseline, fix what is needed, then bring it into the regular cycle. Servers on an unsupported OS release usually need a rebuild first.
How do I know backups actually work?
Restore tests are part of the scope, at the interval in your order, and each result is reported to you, including any that fail and what was done about it.
Is managed hosting a compliance service?
No. It provides operational evidence such as patch and restore records, which helps with audits, but compliance assessments and certifications are out of scope.
Sources
- NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning, NIST
- NIST SP 800-123: Guide to General Server Security, NIST
- CIS Benchmarks, Center for Internet Security
Related
Last reviewed . Facts on this page are checked against the sources listed; anything not yet contracted is marked “confirmed at quote”.