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.
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.
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.
