Prebid Server Deployment on Infrastructure You Own

Server-side buys latency with match rate. When a bidder moves from the browser into Prebid Server its user match rate falls and its bid rate falls with it, so the bidders that survive the move are the ones already slow in the browser and small in win share. Our rule: a bidder is a candidate when its client-side response sits above roughly 250 ms at p95 and it wins under a few percent of impressions. Everything else stays client-side. If that leaves nothing worth moving, we will tell you the project is not worth running and stop there. Hosting: Prebid Server Go, in containers, on infrastructure you own, in the regions your readers are in. An auction is round trips, and a reader in Frankfurt calling an instance in Virginia has already lost more than any module list will win back. You get the Terraform, the container definitions and the repository. We will not run this as a box only we can see inside, because if we disappear your platform team has to be able to redeploy it on a Tuesday afternoon without calling anyone. Configuration: Stored requests in Postgres, so account and impression configs are versioned and reviewable instead of edited live at four in the afternoon. Price floors enforced server-side against the same floor file the browser reads, so the two cannot drift. Currency conversion pinned to a rate file with a known refresh interval. TCF host configuration set explicitly, including the default value, purpose enforcement and any vendor exceptions, because the setting in a fresh install is not the one a European publisher wants. Cookie sync limits and cooperative sync set deliberately, with the sync endpoint served from your own domain so it stays first-party for as long as browsers permit. Observability: Prometheus metrics from day one, with boards for request rate, per-bidder timeout rate, error rate and auction latency. Alert thresholds are agreed before launch and the runbook names people, not roles. A Prebid Server nobody watches is a revenue outage waiting to be discovered by a monthly report. Sizing: We size the cluster from your own peak auction rate and hold headroom at forty percent, and the sizing note shows the arithmetic so your infrastructure lead can disagree with it in a review rather than in an incident. Costs are yours and visible. We do not bill per auction, which would give us an interest in your request volume instead of your yield. Not included: We do not write bidder adapters for demand partners who have never published one. That is their engineering work and we will help you write the request. We do not operate your CDN or your consent platform. We do not resell a managed Prebid Server under our own name, and where a managed option is the better answer we will say so before you have spent anything on infrastructure. Who should not book this: Publishers below a few hundred auctions per second at peak. A managed server-side wrapper will cost less than the infrastructure and our fee together, and we will name two we consider honest about their take rate. Teams with no platform engineering capacity at all: the retainer keeps this running, but somebody on your side must hold a pager and approve a deploy. Anyone whose goal is to move every bidder server-side to cut page weight, since that is a client-side build problem and the answer is a smaller Prebid build, not a server.