At a glance:
The questions that come up late in the evaluation: where exactly is the line, and what happens when something occurs at the boundary
Servers.com by Nexcess owns the physical layer, the hardware refresh cycle, network performance between facilities, and the hardware-layer incident response
Your team owns everything at the OS layer and above: server configuration, Kubernetes setup, deployment tooling, application code, and observability
OS-level incident handoffs, configuration changes mid-contract, and compliance documentation are worth getting answers on before you're live
The question that comes up late in the evaluation, and again after signing, is where exactly the line is. Specifically: which failures are ours to resolve, which decisions stay with your team, and what the handoff looks like when something happens at the boundary.
What Servers.com owns
The physical layer. The hardware in the rack, the facility it sits in, and the network connecting the facilities. A drive fails, a NIC goes bad, a power circuit needs replacement: that's a Servers.com by Nexcess problem. Our engineers have physical access, and they handle it. Your team doesn't file a ticket and wait.
The hardware refresh cycle. We determine when hardware gets updated and run the process. Your team doesn't manage a refresh planning cycle, doesn't negotiate with hardware vendors, and doesn't absorb the engineering time to spec, procure, and rack new equipment. The question of which processor generation you're on and when they get updated is ours to answer.
Network performance between facilities. Traffic between our locations runs on our private backbone, and our network responsibility extends beyond it. Public network routing, ISP peering, and how traffic moves in and out of our facility are ours to manage and optimize. If latency degrades, whether between facilities or on the path to your end users, we diagnose it, identify where the problem lies, and work to resolve any issues within our infrastructure.
Hardware-layer incident response. When an incident points below the OS, our engineers are on it under a documented SLA. The escalation path doesn't start with your on-call engineer filing a ticket. For SaaS platforms where infrastructure incidents affect product SLAs, this is the clause in the agreement that matters at 2am.
What your team owns
Everything at the OS layer and above. Server configuration, Kubernetes setup, deployment tooling, application code, and monitoring. The fact that the hardware is managed doesn't change who makes the decisions that affect how your workloads run. Those stay with your team.
Security patching above the hardware layer. OS patching, application security, and network configuration at the software layer. We handle physical security and firmware-level concerns. Your team handles everything above that line.
Workload architecture and scaling decisions. Which workloads run where, how they're distributed across locations, and how you handle capacity planning. We provision what you ask for and can adjust the configuration mid-contract. The decision about what to provision is yours.
Your observability tooling. Datadog, Prometheus, Grafana: these travel with you. What changes is what you're pointing them at, physical cores and memory instead of virtualized resources. Some dashboards need adjustment. The observability function and the tooling stay yours.
Where it gets specific
A few areas worth getting explicit answers on before you're live.
OS-level incident handoffs. If the investigation points below the OS to hardware or network, we pick it up from there. That handoff is documented in your agreement.
Configuration changes mid-contract. We handle these. The process and turnaround time vary by tier and contract structure. We'll give you the specific answer during scoping, so you're not finding out in a situation where you need it.
Compliance documentation. We provide infrastructure-layer documentation for audits. Application-layer compliance stays with your team. Know which layer each compliance requirement touches before the auditor asks.
If your situation has an edge case like unusual hardware requirements, a compliance framework with physical infrastructure provisions, or geographic expansion that needs pre-agreed capacity, we work through it in the scoping conversation. The standard model above covers most situations. It doesn't cover everyone, and we'd rather know about yours before you're live than after.
The split works because it matches ownership to expertise. We have physical access, vendor relationships, and engineers on the hardware layer. Your team has the workload context, deployment patterns, and product requirements that no infrastructure provider could replicate. The line exists to keep those things with the people who can act on them.
