No. Hetzner does not provide a native content delivery network. Hetzner’s Object Storage FAQ explicitly says that Object Storage is not a CDN and recommends placing a third-party CDN in front of it for large-scale global delivery.

Hetzner can still be the origin. A CDN can fetch files from Hetzner Object Storage, a cloud server, a dedicated server, or a load-balanced application and cache suitable responses at its edge locations.

What Hetzner provides

Hetzner provides infrastructure products such as cloud servers, dedicated servers, load balancers, DNS, and S3-compatible Object Storage. These products run applications and store content. Their data-center locations are not a globally distributed CDN cache footprint.

The distinction matters:

  • The origin stores or generates the authoritative response.
  • The CDN receives public requests, caches eligible responses near users, terminates client connections, and may apply edge security controls.

The Hetzner provider profile is therefore listed as related origin infrastructure rather than as a comparable CDN product.

Basic architecture

Users -> third-party CDN -> Hetzner origin

For Object Storage, the bucket endpoint remains the origin. The public hostname points to the selected CDN. For an application server, the CDN connects to the site’s origin hostname or IP address.

Keep the origin available to the CDN, but restrict direct public access where the chosen products support origin authentication, an IP allowlist, or a secret request header. A hidden hostname alone is not access control.

Object Storage checklist

  1. Create the bucket in the required Hetzner location.
  2. Decide whether objects are public or whether the CDN must authenticate to the origin.
  3. Configure the CDN origin with the correct bucket hostname and TLS server name.
  4. Set the public CDN hostname and certificate.
  5. Define which query strings, headers, and cookies belong in the cache key.
  6. Return explicit Cache-Control headers from the origin.
  7. Test large files, byte-range requests, content types, and cross-origin headers.
  8. Configure a targeted purge workflow for objects that cannot use versioned names.
  9. Monitor both CDN charges and Hetzner origin traffic because cache misses still consume origin resources.

Web application checklist

Separate cacheable and personalized routes. Version static assets and give them long TTLs. Keep authenticated HTML and APIs private unless shared caching has been designed deliberately.

Preserve the original Host value expected by the application, or configure a dedicated origin hostname. Confirm how the CDN handles redirects, cookies, WebSockets, uploads, and request-body limits. A CDN cannot repair slow application logic; measure origin processing time separately from network latency.

Choosing the CDN

Evaluate the third-party CDN on the needs that Hetzner does not supply:

  • edge coverage near the audience;
  • cache and purge controls;
  • origin protection;
  • TLS and HTTP protocol support;
  • WAF or DDoS requirements;
  • request, transfer, log, and security pricing;
  • support for the selected Hetzner origin type.

Do not select a provider from PoP count alone. Run tests from representative user regions and include cache misses, uncached requests, and failover behavior.

Limitations

This design creates a two-vendor service. Billing, support, logging, and incident ownership are split between Hetzner and the CDN. The CDN’s advertised availability does not remove the need to make the Hetzner origin resilient. A full cache purge or an uncacheable traffic spike can send substantial load to that origin.

For storage intended to serve only a small number of clients, direct Object Storage URLs may be sufficient. For a large or geographically distributed audience, follow Hetzner’s recommendation and use a CDN in front of the bucket.