How does first-party ad serving get past ad blockers?

Ad blockers work by blocking requests to known third-party ad domains such as cdn.adsrvr.org or ib.adnxs.com. With Trusted Server the browser never calls those domains. Every ad request, creative asset and tracking pixel is served from a first-party proxy path on the publisher's own domain, so there is no third-party request to block.

How much does running Prebid Server on AWS cost?

It depends on request volume, timeout settings and how many bidders you call per auction. We deploy Prebid Server behind CloudFront and tune instance sizing, autoscaling and caching specifically for cost control, then instrument spend so you can see cost per thousand auctions. A short assessment of your traffic gives a concrete monthly estimate before you commit.

Can you debug our existing Prebid adapters?

Yes. We develop and debug custom Prebid adapters and extensions, including bid response issues, timeout tuning, consent handling and ID module behaviour. We work at the OpenRTB request and response level, so we can trace exactly where a bid is lost or malformed.

Does Trusted Server work with our current SSP relationships?

Yes. Trusted Server sits in front of a standard OpenRTB auction through Prebid Server, so existing SSP and DSP integrations keep working. It adds a synthetic ID and request signing, which gives your demand partners a verifiable, fraud-resistant signal even without third-party cookies.

Prebid Consulting & Trusted Server

Prebid consulting, from adapter to Prebid Server on AWS

Prebid problems rarely stay in one layer. A bid that disappears can be a broken adapter, a misconfigured ID module, a timeout set too tight, or a Prebid Server instance falling over under load. We work across all of it: setup, development and debugging of custom Prebid adapters and extensions, and deployment of Prebid Server on AWS behind CloudFront, tuned for cost control.

We built a header-bidding data pipeline on AWS that processes 400M+ HTTP events and more than 1TB of data daily, autoscaling on ECS with near-realtime transformation into Redshift. For Spearad, we ran multi-region, latency-routed ad infrastructure where infrastructure as code let new regions come online in days.

400M+

Header-bidding HTTP events daily

1TB+

Data processed per day

Days

To deploy a new AWS region

What is Trusted Server on Fastly Compute

Trusted Server is an open-source publisher-side ad execution environment running on Fastly Compute. Ad logic that normally runs as third-party JavaScript in the browser moves to the edge. The browser makes only clean first-party requests to the publisher's own domain; direct calls to third-party ad servers, the requests ad blockers key on, are eliminated.

This is not a proxy trick bolted onto an existing tag. The auction orchestration, ID generation, request signing and creative handling all execute server-side on the edge, under the publisher's control.

How the first-party ad serving flow works

The request path is: browser to publisher domain, to Trusted Server on Fastly Compute, to Prebid Server on AWS behind CloudFront, into the OpenRTB auction across SSPs and bidders. The response flows back through the edge.

Two mechanisms make the auction trustworthy without third-party cookies. Trusted Server generates a synthetic ID and signs each request, so SSPs and DSPs receive a verifiable, fraud-resistant signal instead of an anonymous cookieless call. Then, on the response side, winning bids arrive full of third-party URLs: image and script sources, click-through hrefs, nurl win notifications pointing at domains like cdn.adsrvr.org, ib.adnxs.com or rtb.openx.net. Trusted Server rewrites all of them to first-party proxy paths on the publisher's domain, validates and proxies the resources server-side, and keeps the origin CDN hidden from the browser.

The browser only ever talks to the publisher's own domain. Every creative, pixel and click tracker loads through a first-party proxy path.

Why publishers adopt first-party ad execution

Three reasons come up in every conversation with publishers. Ad-blocker resilience: with no direct calls to third-party ad domains, filter lists have nothing to match, and blocked inventory becomes monetizable again. Control: the publisher decides exactly what code runs on the page, instead of whatever a winning creative injects. Data containment: audience data does not leak from the page to every third party that manages to get a pixel into the auction.

What we offer on the Prebid and Trusted Server stack

Adoption consulting

Viability assessment for Trusted Server on your traffic: ad-blocked share, SSP mix, latency budget and Fastly Compute fit, before you commit engineering time.

Prebid Server integration

Prebid Server deployed on AWS behind CloudFront, wired into Trusted Server at the edge, with autoscaling and cost instrumentation from day one.

Adapter development and debugging

Custom Prebid adapters and extensions built or fixed at the OpenRTB schema level: bid mapping, consent, ID modules, timeouts.

Custom edge development

Custom development on the Trusted Server stack itself: Fastly Compute and edge WASM, for publisher-specific auction and creative logic.

The same team runs our broader advertising technology practice, including ARTF container deployments for publishers extending their Prebid Server, and seller agent development for publishers preparing their ad stack for agentic buying.

Prebid.jsPrebid ServerOpenRTBFastly ComputeWASMAWSCloudFrontECS

Talk to an engineer