Managed or self-managed server?
The decision at a glance
| Question | Self-managed | Managed |
|---|---|---|
| Who maintains the platform? | Internal team with cover | Provider within the agreed scope |
| Who knows the application? | Internal business ownership needed | Application ownership must be agreed |
| What do you compare? | Resources plus internal effort | Resources plus defined support |
The real decision
A server is not managed merely because a provider supplies hardware or a virtual machine. What matters is who patches the operating system and application, evaluates alerts, approves changes and performs recovery. List those activities before comparing offers. A low infrastructure price may conceal substantial internal effort, while a managed service may exclude tasks your team assumed were covered.
Use a responsibility matrix
Assign an accountable and a backup role for the operating system, runtime, database, application, DNS, certificates, users and backups. Record who is informed and who approves changes. This overview shows whether each task has an owner. Monitoring needs reporting and response procedures, while backups need someone responsible for restore tests.
Calculate complete cost
Compare more than monthly fees. Internal on-call effort, maintenance windows, licence work, documentation, monitoring tools, training and unplanned incidents all belong in the calculation. External operation can be efficient for infrequent specialist work; self-management can fit where platform expertise is continuously available. Model a realistic period including growth and at least one major upgrade.
Make operations testable
Define maintenance schedules, reporting channels, priorities, access controls and logging. For backups, specify the target, scope, retention, restore tests and required recovery time. Document dependencies such as identity providers, DNS and external APIs. NUXOA records the agreed service scope in your quote.
Decision checklist
Review available skills, required coverage hours, regulatory constraints, change frequency and tolerable data loss. Ask for an example ticket and escalation path. Have a representative recovery path explained. Record which administrative rights must remain in-house. The suitable operating model is the one whose responsibilities remain unambiguous even during an incident.
Example: an agency with twelve web projects
Imagine an agency operating twelve client websites. Two developers understand the server but are often occupied with project work. The server fee initially makes self-management look attractive. For a fair decision, however, the agency also records routine maintenance, troubleshooting, holiday cover and major upgrades. Asking who responds to an alert during a client meeting already reveals an organisational gap. The agency needs a designated backup contact.
A suitable managed offer might cover the operating system and hosting platform while the agency remains responsible for websites, extensions and content. The handover then needs a clear procedure: who identifies a fault after an update, who may roll back and who informs the client? Include these responsibilities when comparing services.
Build a cost model around daily work
Create a simple comparison: infrastructure and licences, plus routine operating effort, plus the selected support service. For internal work, use your actual fully loaded hourly cost. For example, four hours of maintenance and two hours of follow-up add up to six working hours per month. Record setup, migration and documentation as separate one-off activities.
Express uncertain assumptions as ranges. A platform with many custom extensions may require more verification than a standard environment. Also separate the consequences of downtime: lost orders, staff unable to work and missed deadlines differ from the hosting invoice. This makes it easier to identify predictable expenditure and the technical or organisational risk that remains. Review the assumptions after the first period of real operation instead of treating the initial estimate as permanent.
Rehearse an incident before commissioning
Consider a specific case: the website responds, but checkout fails. A basic uptime check may still be green. Discuss which functions are monitored and where infrastructure support ends. Record the first contact, the information they need and the handover to application developers. Response time and a promised resolution time are different commitments; neither should be inferred from a generic support label.
Access must work during an incident too. Document who grants permissions, how a replacement engineer gets access and how access is revoked after staff changes. Acceptance should cover a planned change and a recovery scenario. That tests the working relationship before a real incident creates time pressure, and exposes dependencies that would otherwise be discovered at the worst possible moment.
- Find every supported component and every excluded responsibility in the quotation.
- Be able to name the reporting path, owner and backup contact for a specific failure.
- Clarify access, documentation and export options for a later provider change.
Next step
Start with a system inventory and flag every unclear responsibility. NUXOA offers managed servers for terminal servers, Plesk, GitLab, mailcow, grommunio and Nextcloud. They include setup, updates, monitoring, DDoS protection, seven daily on-site backups and two weekly off-site backups. Support is available around the clock through the ticket system. We discuss migration and special requirements based on your existing environment.