Skip to main content
Embedded OpenCache PoP

Put OpenCache inside your network

An Embedded OpenCache PoP is cache hardware that P Foundation deploys and operates inside your network. You provide rack space, power, an uplink, and a BGP session; everything running on the PoP stays with us.

Where an OpenCache request is served from
Without a PoP in your networkEvery request crosses your international transit.
With an Embedded OpenCache PoP97% answered inside your network. The rest falls through.

On-demand delivery, measured across three months of production traffic. Live content lands between 80% and 85%.

What it is

A cache PoP in your facility, operated by the foundation

Every OpenCache PoP runs the same platform under one control plane; what an embedded PoP changes is where it sits.

Embedded OpenCache PoPin your rack
  • TLS terminationcertificates live and terminate in the unit, never on host hardware
  • HTTP/1.1, HTTP/2, HTTP/3 over QUICevery client negotiates the best protocol it speaks
  • Cache storefilled from the exchange, served to your subscribers at line rate
  • Health agentscores the unit for the control plane every 15 seconds

What it plugs into

  • Uplink to your corerequests in, cached objects out
  • BGP session, listen-onlyyour prefixes in, nothing announced back
  • Control planeconfig down, telemetry up
  • It answers only for your prefixes

    The listen-only session tells the PoP whose subscribers it is serving. It announces nothing back to you, and it changes nothing about your routing policy.

  • Nothing for your team to run

    Configuration, cache rules, traffic policy, monitoring, and lifecycle stay with the foundation, applied identically at every PoP in the fleet.

  • Not peering, not transit

    A PoP is a delivery footprint in your rack. It is not a session you negotiate with us, and it is not bandwidth you buy.

What you provide
  • Rack space with dual power feeds, in a facility that already terminates subscriber traffic.
  • An uplink into your core with headroom above your peak OpenCache demand.
  • IPv4 and IPv6 addressing for the PoP, plus a listen-only BGP session carrying the prefixes it should answer for.
  • Remote hands for the install and for any hardware replacement.
  • A NOC contact for maintenance windows and capacity planning.
What we provide
  • Hardware sized to the peak demand confirmed at your site survey, shipped to your facility.
  • Deployment, configuration, and remote operation: the PoP pulls declarative config, validates it, and reloads without dropping traffic.
  • Cache rules and traffic policy set centrally and applied identically at every PoP in the fleet.
  • Content from every provider serving through OpenCache on one footprint, growing as providers join.
  • Delivery reporting in PF Console: what the PoP served, and what it kept off your transit.
Qualification

The bar is 5 Gbps of peak OpenCache traffic

more than5 Gbpsof peak OpenCache traffic toward your subscribers, sustained, week after week

An embedded PoP is warranted once your network sustains more than 5 Gbps of peak OpenCache traffic toward your subscribers. We measure it on what you already pull: from the OpenCache PoP at your exchange if you peer with one, or over your transit if you do not. One busy evening is not the test; the number has to hold at peak. Networks that clear it comfortably run more than one PoP, clustered in a facility for capacity or distributed across regions.

Alongside the traffic bar

  • A public ASN and a BGP-capable network, with the prefixes you want answered carried on a listen-only session.
  • A facility close to your subscribers, with the space, power, and uplink headroom the site survey confirms.
  • Remote hands available for the install and for hardware replacement.
  • No filtering, rewriting, reprioritizing, or selective degradation of what the PoP serves: the fleet answers identically everywhere.
Request path

Only the second miss uses your transit

Your subscriberon your access network
request
Embedded OpenCache PoP97 of every 100 on-demand requests stop here, inside your network
on a miss
PoP at local exchangea local hop over peering, where local exchange has one
on a second miss
Provider originthe only stop that touches your international transit

Where your exchange has no PoP, a miss goes straight to the origin

Process

From application to serving

  1. Apply and qualify

    Tell us your ASN, where the PoP would sit, and the OpenCache traffic your subscribers pull today. We check it against the bar and against how your network is built.

  2. Design and agreement

    We settle where the PoP sits, how it attaches to your core, and how many the site needs. A hosting agreement covers the hardware, access, power, and the commitments on both sides.

  3. Survey and install

    Rack, power, ports, addressing, and cross connects are confirmed before anything ships. Your remote hands rack and cable it, we configure it centrally, and traffic moves once it reports healthy.

  4. Operation

    Monitoring, cache rules, and lifecycle stay with us. Your NOC gets the delivery picture in PF Console, and we coordinate maintenance with it.

Apply

Apply for an Embedded OpenCache PoP

Tell us about your network. Applications reach our team directly, and we reply by email.

Toward your subscribers, at peak. PF Console reports it if you already reach an OpenCache PoP over peering.

Newsletter

Get updates from the field

Occasional updates on our programs and products. No spam.