Self-Hosted Prebid Server on PBS-Go, Run From Singapore

Self-hosting Prebid Server starts to pay for itself somewhere above 300 to 400 million monthly auctions. Below that, the instance bill and the on-call rota cost more than a managed wrapper vendor charges, and we will tell you that in the first week and stop. At the volumes where it does clear, the saving is not the point either. What you are buying is control of tmax, of the stored request layer, and of a log stream that tells you which exchange started timing out at four in the afternoon, instead of a support ticket that gets answered on Thursday. Why the deployment sits in Singapore: Server-side auctions move the round trip from the reader's phone to your datacentre, so where the datacentre sits becomes a revenue decision. Running ap-southeast-1 against readers in Indonesia, Vietnam and the Philippines gives us a network budget we can spend on bidders rather than on distance. We measure the region choice before committing to it, using real client timings from your own pages, not a latency chart. The build: PBS-Go, containerised, deployed to your cloud account, behind your own load balancer and CDN, with configuration in the same repository as everything else. Stored requests and stored imps live in Postgres so a floor or a slot change is a database write rather than a redeploy. Prebid Cache runs against Redis with a TTL you set, and it earns its keep the moment you sell video, because a VAST document that has to travel back through the client is a document that arrives late. The Floors module is loaded from a schedule you control. TCF vendor configuration and the GVL refresh are set up properly, since a server-side auction with a missing consent string is not a discounted bid, it is no bid at all. The part most vendors skip: Cookie sync. In Safari and in most SEA app webviews, the sync you configured does not persist, and the match rate you assume in your model is not the match rate you have. We measure it per bidder through /cookie_sync and /setuid before deciding which adapters belong server-side at all. In several of these markets the identity loss from moving a bidder server-side is small because the match rate was already poor, which is exactly why the hybrid split, some adapters client-side, some server-side, is decided per bidder rather than as a policy. Running it: Prometheus metrics, Grafana dashboards, and alerts on the three things that actually page someone: adapter error rate, p99 auction time, and cache write failures. Deployments go out behind a canary carrying a slice of live traffic with an automatic rollback threshold. You get a runbook written for whoever is awake at 3am, including how to disable a single adapter without a release, and a measured cost per million auctions so the build-versus-buy question stays answerable next year rather than becoming an article of faith. Not included: We do not resell hosting, and we do not hold your pager indefinitely. The retainer covers on-call during a defined window and hands over to your team on a schedule written at the start. We do not negotiate your demand deals. We do not run PBS-Java migrations of an existing Java deployment as a side project; that is its own engagement. Decline: Publishers who want server-side because it sounds more advanced than what they have. Anyone whose Prebid.js setup has never been measured, since server-side inherits every bad decision in the client and hides it one layer deeper. Traffic sources we cannot verify. And anyone who wants us to run auctions on infrastructure we do not have root on, because we will not be accountable for latency we cannot see.