Base de conocimientos

Use your own Cloudflare CDN account as a site's CDN

Create a Cloudflare API token with zone read, cache purge and zone settings permissions and connect it, so a site can run on your own Cloudflare CDN.

What connecting it does for you

Connecting your own Cloudflare account lets you put a site on your CDN instead of ours. The zone, the traffic and the bill are on your account, and you can still purge the cache and change the CDN's settings from inside your Zinn® dashboard — no switching between panels.

Before you start

A Cloudflare account. The free plan is enough to connect; features beyond it depend on your Cloudflare plan.

1. Create the key at Cloudflare

In the Cloudflare dashboard open My Profile → API Tokens and choose Create Token, then Create Custom Token. Give it a name, add the permissions below, and under Zone Resources choose the zones you want us to reach — all zones, or only the ones you name. Review it and press Create Token. Cloudflare shows the token once; copy it then.

Add these permissions:

  • Zone → Zone → Read
  • Zone → Cache Purge → Purge
  • Zone → Zone Settings → Edit

The older alternative. Instead of a token you can connect with your Global API Key and the email address you sign in with (My Profile → API Tokens → API Keys → Global API Key → View). Cloudflare recommends against it: the Global API Key carries every permission your login has, on every zone, and cannot be narrowed. Use a token if you can.

2. Connect it here

Open Integrations in your dashboard and choose Connect an account. Pick Your own CDN as the group and Cloudflare CDN as the account, fill in API token — or, for the older alternative, API key and Account email, and press Connect account.

We test what you paste before anything is saved. A key that does not work is never stored, and the answer says what was wrong with it. A key that works is kept encrypted in our secrets vault — never in our database — and is never shown again, not even to you.

Tick Use this account for DNS as well if the same Cloudflare account should also serve your domains' DNS; otherwise connect a DNS account separately.

What happens next

  • Open a site's CDN tab. Under Where this site is served from, this account
  • appears as a destination. Choose it and confirm; we build the site's configuration on your account, check it, and only then move the site across, so the site stays up during the move.

  • From the same tab you can purge the site's cache and change its CDN settings on your
  • account.

  • When you connect, we check what the key can do: list your zones or properties, read one in
  • detail, purge the cache, change settings and — where the vendor has them — geographic rules. The checklist beside the connection shows which of those we could confirm, so a missing permission is visible before you move a site onto the account.

  • Deploy a site to your own CDN account covers moving a site between accounts in detail.

If it does not connect

A permission shows as unconfirmed. Cloudflare does not always let a token list its own permissions. Edit the token in My Profile → API Tokens to add what is missing — the token value does not change.

Moving a site between two Cloudflare accounts. Each Cloudflare account has its own pair of nameservers, so the domain's nameservers change too. Your site keeps being served from the old account until they do.

It says the key was rejected. Almost always one of three things: a space or a line break copied with it, a key that has expired, or a key that was revoked or regenerated after you copied it. Create a fresh one and paste it again.

It connects, but something later fails. The key authenticates but lacks a permission the action needs. Create a new key with the permissions listed above, then disconnect the old connection and connect the new key.

Disconnecting

Open Integrations, find the account and press Disconnect. That deletes the stored key at once. Anything that was using it stops at its next action, and the screens that depended on it say so rather than failing quietly.

Disconnecting does not undo what was already done — records, deployments or settings we changed on your account stay as they are. If you think the key itself may have leaked, also revoke it at the vendor; disconnecting removes our copy, not theirs.

Este artículo aún no ha sido traducido a su idioma, por lo que está leyendo la versión en inglés.

Últimas entradas del blog

Lo que hemos estado escribiendo sobre alojamiento, SEO y gestión de sitios a escala.

SEO y Link Building desde la Capa de Alojamiento: Una Visión del Operador para 2026

Cómo el alojamiento web influye en la indexación y la equidad de enlaces en 2026: mantener las páginas indexadas, evaluar dominios antiguos antes de crear sobre ellos, construcción de enlaces sin rastro y una opinión honesta sobre lo que la infraestructura puede y no puede hacer por el SEO.

Leer la publicación

Haciendo que WordPress sea rápido y seguro: Una lista de verificación de rendimiento y plugins

Una lista de verificación práctica para un WordPress rápido y seguro: almacenamiento en caché a nivel de servidor, una caché de objetos por sitio, el puñado de plugins que vale la pena ejecutar, mantener la pila actualizada y las páginas de WooCommerce que nunca debes almacenar en caché.

Leer la publicación

Cómo elegir alojamiento web gestionado en 2026: Guía de compra

Lo que realmente diferencia a un buen alojamiento gestionado de un servidor barato con un panel de control —migraciones, copias de seguridad, aislamiento, caché real y escalado honesto— y cómo evaluarlo antes de comprometerte.

Leer la publicación

Leer el blog

¿Sigues con dudas?

El soporte técnico está incluido en todos los planes, el servicio de atención está disponible 24 horas al día y puede escribirnos en cualquiera de nuestros 58 idiomas; le responderemos en el suyo.

Contactar con soporte Todos los artículos