Microsoft's Public Prebid Cache Shuts Off April 30: A Video Migration Plan

A piece of shared plumbing that thousands of video setups quietly depend on is about to disappear. Microsoft has confirmed that the public Prebid Cache it inherited from AppNexus, hosted at http://prebid.adnxs.com/pbc, will be deprecated on April 30, 2026. Prebid.js and Prebid Server setups that use it to store and retrieve video creatives need to move to something else.

This is not a surprise. Microsoft first set a January 31 shutdown and later pushed it back three months. But deadlines that have already slipped once tend to get ignored, and this one sits in code most teams have not opened in years. If you run instream or outstream video through Prebid, especially on a local news or local TV station site where video carries a big share of revenue, you have about two weeks to check.

Why video header bidding needs a cache at all

Display bids can render straight from the page. Video is different. As the Prebid.js documentation explains, video players do not pull VAST XML out of the JavaScript on the page. They expect a URL they can fetch it from when they are ready to play.

So there are three ways a video bid gets to the player:

• Bidder-side caching. Some video bidders cache the VAST on their own servers and return a cache key. Prebid has nothing extra to do.
• Remote client-side caching. Bidders that return the full VAST XML body need Prebid.js to POST it to a Prebid Cache endpoint. The key that comes back becomes the video cache key, which is passed to the ad server as hb_uuid and later used to build the VAST URL. This is the path the Microsoft endpoint served.
• Local caching. Prebid stores the VAST XML as a blob in the browser's memory and uses a blob URL instead of a network cache.

If your configuration points at the Microsoft endpoint, the failure after April 30 will not look like an outage. Auctions will still run and bids will still win. What breaks is the last step: the player asks for the creative and gets nothing. You see it as VAST errors, blank players and video revenue sliding, usually without an obvious alert.

Step one: find out whether you are exposed

This takes an hour, not a sprint. Check four places:

1. Your Prebid.js config. Search the wrapper code and any tag manager containers for prebid.adnxs.com. The line to look for is a cache.url value in setConfig.
2. Your ad server creatives. In Google Ad Manager, open the VAST redirect creatives on your Prebid video line items. If the VAST tag URL contains the Microsoft host with the hb_uuid macro, those creatives depend on it.
3. Prebid Server. If you or a vendor run Prebid Server for video or app demand, ask which cache host it is configured to use. Microsoft's notice covers Prebid Server implementations too.
4. Vendors and players. If a video player vendor or managed partner set up your integration, ask them in writing which cache your traffic uses and what their plan is. Get a date.

If none of those point to the Microsoft host, you are fine. Note the answer in your runbook so nobody has to rediscover it later.

Step two: pick a replacement

Microsoft's notice lists three options and says it prefers local caching, citing a smoother experience and less bandwidth for everyone.

Option 1: Local caching in the browser

As of Prebid.js 9.37.0, setting cache.useLocal to true saves the VAST XML as a blob in browser memory. The remote cache URL is never called. The Prebid docs say existing Google Ad Manager VAST creatives built around the hb_uuid macro keep working: the key becomes the local blob ID, and when a Prebid bid wins in GAM, Prebid swaps in the blob URL after the ad server responds.

Two practical notes. First, you need Prebid.js 9.37.0 or later, so a team still on an old build has an upgrade to schedule first. Second, the docs say that if you use local caching without Prebid's video module, you need to pull the VAST XML yourself with getVastXml. Check how your player gets its ad tag before you assume it is a one-line change.

Option 2: A server-side cache you control or contract

You can run Prebid Cache on your own Prebid Server host or use one run by a partner. This keeps the existing flow identical: Prebid POSTs VAST to a URL, gets a key back, and the ad server builds the tag the same way. The cost is that you now own an endpoint that has to be fast and available during every video auction. Ask any provider about uptime, retention time for cached creatives, and what happens to requests if the cache is slow.

Option 3: Lean on bidder caching or raw XML

If most of your video demand comes from bidders that cache on their own servers, remote caching may matter less than you think. And if your player can consume VAST XML directly, the cache.allowVastXmlOnly setting lets Prebid skip the cache requirement. Both depend on your specific bidders and player, so treat them as a check, not a default.

Step three: test before the deadline, not after

Whatever you pick, compare it against the current setup while the old endpoint still works. Put the new configuration on a share of traffic, leave the rest alone, and watch for a week:

• VAST error rate by bidder, in your player and in GAM. This is the metric that moves first when caching breaks.
• Video fill and revenue per player load, split by instream and outstream placements.
• Win rate by bidder. A bidder whose wins drop to zero on the new path is a caching problem, not a demand problem.
• Google demand. If Ad Exchange competes with Prebid in the same GAM request, confirm its fill and CPMs hold steady on the new path.
• Player behavior on real devices. Test mobile Safari and Chrome on Android, not only desktop.

Then schedule the full cutover before April 30 with someone watching the dashboards that day. Remove the Microsoft URL from the config entirely so nothing falls back to it.

Why local news sites should move first

Local broadcasters and newspaper sites lean on video: newscast clips, weather updates and short explainers that run with pre-roll or outstream units in articles. Video usually commands higher CPMs than display on the same page, so a caching failure costs more per page view here than on most sites. These teams are also often the ones with a wrapper set up years ago by someone who has since left. If that describes you, this is the week to open the config.

Use the migration to clean up

A forced change is a good moment for small fixes that usually wait:

• Upgrade Prebid.js. If you need 9.37.0 for local caching anyway, consider moving to a current release and dropping adapters you no longer use.
• Audit video bidders. Pull ninety days of video wins by bidder. Any partner with almost no wins is adding latency and complexity for nothing.
• Document the flow. Write down which cache path each bidder uses and where the VAST URL is built. The next person to touch video will thank you.

The fix is not complicated, but it is easy to miss until revenue drops. If you work with a managed partner such as HBDR, ask them to confirm your cache path in writing this week. If you run your own stack, search the config for prebid.adnxs.com today.