CDN for documentation
Docs are static. Readers are not in one region.
Documentation sites are HTML, search indexes and images. Hosting them next to the product API still leaves most readers far from the files.
Cache the docs build at Cloud CDN. Purge on CI. Keep preview deployments off the public cache.
Why teams use Aptranet
What CDN for documentation looks like on this network.
Cloud CDN caches and accelerates eligible content on 210+ points of presence, with Origin Shield when the origin must stay out of the way.
Docs HTML at 210+ PoPs
Pages load with 30 ms average latency instead of a single docs origin.
Search indexes and assets cached
Client search JSON, fonts and screenshots are stored at the edge.
Build pipeline purge
Each docs release invalidates HTML so new pages are live immediately.
How to set it up
A cutover you can validate before DNS moves.
Create the Cloud CDN configuration, prove it on an Aptranet hostname, then point production DNS when the path looks correct.
- 1Publish the docs build to an origin
Hugo, Docusaurus, MkDocs or any static output.
- 2Cache pages and hashed assets
Long TTL for fingerprinted files, purgeable HTML.
- 3Add purge to docs CI
After the build, invalidate the docs hostname HTML.
- 4Map docs.example.com
Attach TLS and cut over DNS.
Outcomes
What changes once the hostname is on Aptranet.
- Documentation is served globally
- CI purge makes releases immediate
- Preview sites stay off public cache
- The product API origin is not a docs server
Keep reading
Related pages
More CDN use cases on the same Cloud CDN footprint.
Frequently Asked Questions
Yes. Any static docs generator can be a Cloud CDN origin.
Cache each version path separately. Immutable old versions can use long TTLs.
Use token authentication or keep internal docs on a private origin that Cloud CDN does not cache publicly.
Cache the search index JSON like any other static asset.