At a glance:
- Hardware, network, and facility problems are Servers.com by Nexcess to diagnose and fix outright. Everything the application does with that hardware, from CPU affinity to bid engine memory allocation, is yours.
- Bidstream data is physically isolated on single-tenant hardware by default. What your team does with that data, retention, governance, privacy compliance, is a separate responsibility we don't take on.
- Moving from managed cloud services to bare metal means trading hyperscaler’s managed OS and patching layer for full control, and capacity decisions shift from reactive auto-scaling to advance planning.
- A compliance audit needs documentation from both sides. We can attest to the infrastructure layer; we can't produce your application-layer compliance posture, and vice versa.
- During a live incident, both teams investigate in parallel from minute one, because clear ownership means neither side wastes time figuring out whose problem it is first.
What Servers.com owns and what your team owns: a shared responsibility map for RTB infrastructure
The line between Servers.com by Nexcess and your team is straightforward in account documents, but it gets tested during a live auction, an audit request, or an after-hours p99 spike.
Knowing where that line is ahead of time means less time figuring it out when something goes wrong. These are the six areas where ownership questions most often come up in RTB operations.
Hardware performance and predictability
When CPU usage and bid latency start rising, the first question is whether the problem is in the hardware or the application. On our dedicated bare metal, those two possibilities are easier to separate than on shared cloud compute.
If a server isn't performing the way it should, that's our problem to investigate. Whether it's inconsistent CPU performance, memory behavior under load, NVMe I/O, or failed hardware, we diagnose it, replace it if necessary, and handle the fix.
Your team owns everything the application does with the hardware it's been given: CPU affinity configuration, bid engine memory allocation, thread pool sizing, and application-level performance tuning. Consistent hardware is the baseline; getting the most out of it is your team's work.
Network path and connectivity
We own the network, from the data center switching fabric through upstream peering to the RTB exchanges. When packet loss shows up in monitoring and bid completion rates start dropping, our team investigates routing anomalies, uplink degradation, and facility-level network issues.
For adtech workloads, we've built direct connectivity and peering relationships with major RTB participants in the markets we serve. Keeping those paths healthy, and investigating them when they aren't, is our responsibility.
Your team owns the application configuration running on top of that path: socket settings, connection pool management, protocol configuration, and the logic that determines how the bid engine establishes and maintains connections to exchanges and demand partners. A well-optimized network path still needs application configuration that matches the throughput your platform requires.
Bidstream data isolation and locality
When an auditor asks how bidstream data is isolated, this is the section everyone turns to.
On dedicated bare metal, your bid requests, bid responses, and bid log data stay on hardware dedicated to your platform. They aren't sharing physical compute or storage with another customer.
Your team owns how bidstream data is stored, retained, and handled within the application: log retention policies, audience data flows through the pipeline, and whether the platform's data handling practices line up with applicable privacy regulations. Our isolation supports the compliance positioning, but it's no substitute for your team's data governance.
Data residency requirements and geographic deployment decisions are established in the account agreement. If the platform has specific data locality requirements for particular markets, those get confirmed during onboarding.
Operating system and application stack
We provision the bare metal nodes with the operating system configured to your requirements. From that point on, the OS and everything above it belong to your team: no provider-managed OS patching, no managed container runtime, no provider-side monitoring agent installation.
If you've spent years on hyperscaler managed services, this is the biggest operational change. From the OS up, the software stack is yours to manage.
Compliance attestation and audit support
The ownership lines that matter during day-to-day operations are the same ones that matter during audits.
We provide documentation on physical security, network isolation, and the single-tenant model, backed by our data center and network environment certifications.
Your team provides the application-side documentation: data handling practices, access controls on bidstream data, retention and deletion policies, and how the customer-controlled software stack is managed for compliance. A successful audit needs documentation from both teams, and neither can provide the other's.
Incident response during live auction events
A p99 latency spike during a live campaign puts everyone under pressure, and the investigation starts in two places at once.
Our on-call team investigates the infrastructure: hardware health, network path anomalies, facility-level issues, and any latency symptoms that start below the OS. Because the team already knows your environment, they aren't rebuilding context when the incident hits. Infrastructure issues at 1am during a live campaign are our responsibility to investigate and resolve without waiting until business hours.
Your team investigates the application: bid engine behavior, data pipeline performance, connectivity to exchanges managed at the application layer, and win rate analysis against your own bid log data.
When an incident spans both layers, which happens during complex performance issues, both teams start triage immediately and share findings as the investigation develops.
