What is a Prebid Server?

Most of the content you'll find on Prebid Server was written by engineers for engineers. It assumes you're already comfortable with bid adapters, timeout configs, and container deployments. This post takes a different approach — it's written for the publisher-side decision maker who's heard "Prebid Server" in a vendor pitch or at a conference and wants to understand what it actually is, why it matters, and whether it's the right move for their business before anyone writes a line of code.

The Problem Prebid Server Solves

If you're running header bidding today, you're almost certainly running it on the client side — meaning the auction happens inside your visitors' browsers. The browser reaches out to your demand partners, collects their bids, and passes the winner to the ad server. It's how Prebid.js was designed, and for most publishers, it works.

But client-side header bidding has a ceiling, and most publishers hit it faster than they expect.

The core constraint is the browser itself. Every bid request travels over the visitor's internet connection, on the visitor's device, within the visitor's browser. Add more demand partners and you add more latency. Research consistently shows diminishing returns as bidder count climbs: publishers typically see yield improvements adding up to five or six partners, with returns flattening above that threshold because each additional partner adds to the page weight and ad calls made from the browser. Beyond a certain point, you're managing a tradeoff, not optimizing an auction.

There are compounding problems on top of that. Mobile web and app inventory runs into stricter timeout windows and more inconsistent connectivity — and if a user is accessing a page through a mobile device, client-side header bidding can have an even greater impact on page load times. Browsers increasingly limit what third-party scripts can do — cookie deprecation, ITP, privacy sandbox changes — and every demand partner you add is another third-party JavaScript payload sitting on your page with its own failure modes.

Client-side header bidding moved the industry forward significantly. Server-side header bidding is where the ceiling gets pushed higher.

What Prebid Server Actually Is

Prebid Server is an open-source solution for server-to-server header bidding, maintained by Prebid.org. Instead of running the auction in a visitor's browser, it moves the auction to a server, one that Prebid.org maintains as a hosted option, or that a company like Aditude deploys and manages on your behalf.

The practical difference: your page fires one request to a server, the server runs the auction simultaneously across all your demand partners, and one response comes back. The visitor's browser is involved for milliseconds, not the full round-trip to every bidder. Moving execution to the server makes the page lighter, and content and ads load faster, resulting in decreased impact on the user experience.

Prebid Server supports the same bid adapters as Prebid.js, so demand-side integrations aren't rebuilt from scratch — it's the same Prebid ecosystem, moved off the browser and onto infrastructure purpose-built to run auctions at scale. In 2024 alone, Prebid Server added 40 new bid adapters and processed more than 960 pull requests, averaging 18 per week.

There are two production-ready implementations: PBS-Go (the original) and PBS-Java, both actively maintained and kept identical in external APIs. When you work with a managed Prebid Server provider, the implementation choice is typically made and maintained for you.

How It Works: The Auction Path from Request to Response

A simplified walkthrough of what happens when a page load triggers a Prebid Server auction:

1. The page fires a single bid request. Your Prebid.js wrapper (or SDK, for app inventory) sends one request to the Prebid Server endpoint, passing along the ad slots, targeting parameters, and any first-party data you've configured. This meta-adapter approach — batching all bids into a single request — lightens the performance load on the user's device.

2. The server fans out to demand partners simultaneously. Prebid Server calls all configured bidders in parallel — not sequentially. Because this happens server-to-server, response times aren't dependent on your visitor's network or device.

3. Bids are collected and the auction runs. Prebid Server collects valid bid responses, applies any floor prices or business rules you've configured, and selects the winner (or passes all bids to your ad server for final decisioning, depending on your setup). Prebid Server supports currency conversion, price floors, caching, and analytics natively.

4. The winning bid is returned to the page. A single response comes back to the browser with the targeting key-values. Your ad server makes the final call.

The latency profile looks fundamentally different from client-side: instead of N parallel browser requests (each with their own round-trip), you have one browser-to-server request plus server-to-bidder requests that run on low-latency data center connections.

Prebid Server vs. Prebid.js: The Differences That Matter for Publishers

These aren't competing technologies — most publishers run both in combination. But understanding the distinctions matters for how you architect your monetization stack.

Where the auction runs. Prebid.js runs in the browser. Prebid Server runs on a server. Everything downstream of that difference — latency, device dependency, privacy exposure, scale ceiling — flows from this single architectural fact.

Bidder count and timeout behavior. With Prebid.js, adding bidders adds latency directly on the page. With Prebid Server, publishers can integrate dozens or even hundreds of demand partners without experiencing the exponential latency penalties seen in browser setups. Server-to-server connections are faster and more consistent than browser-to-server connections across a fragmented device population.

Cookie matching and identity. As a general rule, client-side header bidding increases audience match rates, which in turn increases CPMs and monetization potential — but it also increases page latency. Server-side reduces latency, though at some expense to match rates. This isn't a dealbreaker, but it's a real integration consideration: user ID modules, first-party data passthrough, and identity partner configurations need to be thought through carefully.

App and video inventory. Prebid.js is a JavaScript solution — it doesn't natively serve app inventory or work cleanly for in-stream video. Prebid Server supports mobile app, AMP, server-side web with Prebid.js, and server-side ad inclusion scenarios such as CTV, Digital Out of Home, and audio. If mobile app inventory is meaningful to your business, Prebid Server isn't optional.

Infrastructure ownership and cost. Prebid.js is a JavaScript file you include on your page. Prebid Server requires actual server infrastructure — either self-hosted or provided by a managed vendor. There's an operational component here that doesn't exist on the client side.

For a deeper look at how Prebid.js fits into your header bidding setup, see The Complete Guide to Prebid Wrapper. For optimization benchmarks across both deployment types, see the 2026 Publisher Playbook – Part 1: Optimize Your Header Bidding Setup.

When Server-Side Bidding Makes Sense (and When It Doesn't)

Server-side header bidding is worth the upgrade if one or more of these describe your situation:

You're running significant mobile web or app inventory. Client-side header bidding struggles in mobile environments — connection speeds can impact latency, and if a user is accessing a page through a mobile device, client-side header bidding can have an even greater impact on page load times. Prebid Server was partly built to solve exactly this.

You're timing out a meaningful share of bids. If your analytics show high bidder timeout rates on key demand partners, you're leaving revenue on the table that server-side can recover. Each ad partner has a different response speed, meaning your auction can sometimes work only as fast as your slowest bidder — a problem server-side infrastructure addresses by running requests on faster, more consistent data center connections.

You want to add demand partners but can't absorb the latency. If you've hit a practical ceiling on bidder count due to page speed constraints, Prebid Server breaks that ceiling. Adding bidders client-side creates diminishing returns above a certain threshold because each additional bidder adds page weight and more ad calls from the browser.

Your first-party data strategy is maturing. Prebid Server gives you a server-side layer to attach first-party data and identity signals before the auction, away from browser-side privacy restrictions.

You're running video or CTV. VAST-based video inventory and emerging formats like CTV and DOOH run cleanly through Prebid Server in ways that client-side setups can't fully support.

When it may not be the right move yet: if you're running display-only inventory on desktop with low bidder counts, strong CPMs, and no meaningful timeout problems, the operational overhead may not produce immediate lift. The gains are real, but so is the setup complexity — particularly if you're self-managing.

What to Look for in a Prebid Server Provider

If you're evaluating managed Prebid Server options — meaning a vendor hosts and operates PBS on your behalf — the decision goes well beyond "do they support Prebid Server." Here's what differentiates providers in practice:

Infrastructure quality and SLA. Prebid Server running on underpowered or shared infrastructure can introduce latency that erases the gains from moving server-side. Ask about uptime SLAs, geographic distribution of servers, and how the provider handles traffic spikes.

Bid adapter coverage and maintenance. The Prebid ecosystem has hundreds of adapters, but not all are maintained at the same quality level. A good provider monitors adapter performance and flags degraded or misbehaving adapters proactively. Prebid.org publishes a full list of supported server bidders — use it as a baseline when evaluating a provider's claimed coverage.

Identity and first-party data support. How does the provider handle user ID module configuration, first-party data passthrough, and identity partner integrations? This is often where generic PBS deployments fall short, given that cookie sync rates can drop when requests originate from a remote server rather than the browser.

Transparency and reporting. You need visibility into auction dynamics — timeout rates, bid response rates, win rates by partner, revenue attribution. If the provider can't give you granular reporting at the auction level, you're flying blind.

Floor price and yield management. Prebid Server supports dynamic flooring, but implementation quality varies significantly. Floor logic that's too aggressive kills fill; floor logic that's too passive leaves CPM on the table. Look for a provider with opinionated, data-driven floor management. For more on how timeout and floor decisions interact, see Aditude's Bid Throttling vs. Prebid Timeouts breakdown.

Integration with your existing stack. Does the provider's Prebid Server implementation talk cleanly to your ad server, your analytics layer, and your existing Prebid.js setup? Fragmented setups create reconciliation headaches.

See the Aditude Cloud Wrapper product page for how the wrapper layer and Prebid Server operate together as a unified stack.

How Aditude's Prebid Server Is Built Differently

Most managed Prebid Server offerings give you the infrastructure and leave the configuration work largely to you. Aditude's approach is different: Prebid Server is built exclusively for publishers — not retrofitted from SSP infrastructure with misaligned incentives.

Aditude operates Prebid Server as a managed, continuously maintained deployment — not a self-service configuration console. Adapter health, timeout tuning, floor logic, and identity integrations are monitored and adjusted by Aditude's team, not left to sit static after initial setup. Multi-region infrastructure delivers auction results in under 100ms, anywhere in the world.

Prebid Server also operates in close coordination with Cloud Wrapper, Aditude's client-side header bidding layer. Rather than treating server-side and client-side as parallel silos, the two work together: unified reporting, coordinated floor pricing, and consistent demand partner configurations across both environments. Publishers get the full picture of their auction performance in Aditude Insights rather than reconciling data from two disconnected systems.

For publishers with app inventory, Aditude's Prebid Server supports both web and in-app deployments under the same reporting and configuration infrastructure — you're not managing two separate vendor relationships for two inventory types. The purpose-built Mobile SDK brings server-side header bidding to native iOS and Android apps, supporting rewarded, interstitial, banner, and native formats, all unified under one auction.

The short version: Aditude built Prebid Server as part of a platform, not as a standalone product. If your goal is to move server-side without building a new operational burden, that architecture matters.

Ready to evaluate Prebid Server for your stack? Explore Aditude's Prebid Server →

Publishers comparing providers or working through a build vs. buy decision: talk to the Aditude team →