Despliega EmDash en Cloudflare Workers: D1, R2 y Tier Gratis

Puedes desplegar EmDash en Cloudflare Workers por 0 $/mes, si sabes qué bindings quitar y qué límites vigilar. EmDash es el CMS basado en Astro con licencia MIT de Cloudflare. La 1.0 salió a finales de septiembre de 2026, y Cloudflare corre su propio blog sobre él. Un despliegue lleva el sitio, el panel de administración en /_emdash/admin, una REST API, auth con passkeys, una librería de medios, publicación programada y backups JSON. D1 guarda el contenido, R2 guarda los medios.

El tier gratis es real, y tiene una arista dura: la plantilla de serie trae un binding LOADER para plugins de marketplace en sandbox, y Dynamic Workers está en beta abierta solo en Workers Paid (5 $/mes). Quita ese binding y un sitio plano corre a 0 $. Déjalo y pagas 5 $. Ese intercambio, más cada límite del plan gratis que te morderá, es lo que esta guía cubre de extremo a extremo: bindings, deploy, dominio, caching, medios, secrets, coste mensual real, y una checklist que demuestra que el deploy funciona.

Si aún estás decidiendo sobre el propio CMS, lee primero nuestra reseña de seis meses de EmDash CMS. EmDash también entra en nuestra lista de apps autoalojadas que corren enteramente en Cloudflare Workers. Mi propio emdashhq.com, un hub de tutoriales, temas y plugins de EmDash, corre sobre el stack exacto que esta guía despliega; sus números reales de dashboard están cerca del final.

Cuánto cuesta desplegar EmDash en Cloudflare Workers

Antes del cómo, la pregunta del dinero. EmDash en Cloudflare no es un producto, son siete servicios cosidos por bindings: Workers corre el código, D1 guarda contenido, R2 guarda medios, KV puede cachear resultados de queries, un cron trigger publica posts programados y escribe backups, un binding de Images hace transforms, y Email Sending entrega magic links. Cada uno tiene una asignación gratis y un suelo de pago.

Hay dos resultados honestos:

• 0 $/mes. Workers Free más D1 free más R2 free más la asignación gratis de Images. Esto es un CMS completo para un blog personal o un pequeño sitio folleto. No cuesta nada y nunca lo hará, mientras el tráfico y los medios se queden dentro de las asignaciones gratis de abajo. Una puerta no obvia: R2 no se activa hasta que la cuenta tiene una tarjeta de crédito o PayPal guardado como método de pago — nada se cobra dentro de la asignación gratis, pero el primer deploy falla hasta que existe.
• 5 $/mes. Workers Paid. Ese es el suelo en el momento en que quieres plugins de marketplace en sandbox (helpers SEO, handlers de formularios, lo que sea del registro de plugins). También compra D1 Time Travel de 30 días, 10 GB por base de datos D1, y margen real de CPU.

Dos números que conocer antes de empezar. Primero, el cron por defecto de la plantilla es * * * * *, cada minuto. Eso quema 1.440 invocaciones/día contra el presupuesto de 100.000 requests diarios del plan gratis antes de que aparezca un solo visitante. Bien para un sitio pequeño, pero es el 1,4% de tu asignación diaria gastada en scheduling. Segundo, el volumen de requests es la razón habitual por la que un sitio EmDash gratis empieza a dar errores, no el almacenamiento. La mayoría de bases de datos de contenido se quedan muy por debajo del tope de tamaño de D1; el techo de 100k requests/día es lo que los sitios en crecimiento golpean primero.

Las cuentas de coste y ops para este stack son la misma historia que cubrimos en el desglose de coste y ops de Astro vs WordPress: la línea de hosting baja a cero cuando el cómputo baja a cero, y lo que pagas en su lugar es atención a los límites.

EmDash en el tier gratis de Cloudflare: qué te dan por 0 $

En Workers Free obtienes el CMS completo. Panel de administración, REST API, auth con passkeys, librería de medios, publicación programada, backups JSON, transforms de imagen, auth compatible con magic links (necesita un setup de plugin, anotado abajo). A lo que renuncias es al marketplace de plugins: los plugins en sandbox necesitan Dynamic Workers, que es solo-pago. Los plugins de config nativa, los listados en plugins: [] en astro.config.mjs, siguen corriendo en-proceso en gratis.

El tier gratis basta si:

Necesitas Workers Paid (5 $/mes) si:

Gratis vs de pago: la tabla de límites que importa

Esta es la tabla a tener abierta mientras decides. Las cifras son de las propias páginas de precios y límites de Cloudflare a las fechas marcadas en cada fuente (precios de Workers actualizados 28 ago 2026; límites de Workers 5 sep 2026; límites de D1 21 abr 2026; precios de R2 7 ago 2026; precios de Images 8 jul 2026; límites de Email Service 25 sep 2026). Vuelve a comprobar las páginas antes de presupuestar, estos números se mueven.

Tres cosas que la tabla no dice en voz alta:

1. El tiempo CPU excluye la espera de I/O. El tiempo esperando a D1, KV o fetch no cuenta contra los 10 ms. El problema es la CPU que sí usas: el SSR de EmDash hace varias idas y vueltas a D1 por request y ensambla respuestas en código Worker. Esa es exactamente la carga que los docs te dicen que vigiles en el límite gratis. El caching (abajo) es la mitigación; subir de plan es la otra.
2. Las respuestas de admin nunca se cachean. EmDash envía Cache-Control: private, no-store en rutas de admin y API, así que el tráfico de editores no envenena tu edge cache. Significa que cada clic de admin es una invocación de Worker contra tu presupuesto diario.
3. Los hits de Workers Cache siguen contando como requests. En gratis, un hit de caché es más barato (sin CPU), pero no es gratis del contador de requests. Presupuesta en consecuencia.

La trampa de Dynamic Workers: los plugins en sandbox necesitan pago

Esta es la confusión recurrente en Reddit y en los foros, así que merece su propia sección. La plantilla EmDash viene con worker_loaders configurado por defecto. Dynamic Workers, la API Worker Loader que corre plugins en sandbox, está en beta abierta y disponible para todos los usuarios de pago de Workers. En una cuenta gratis, desplegar la plantilla por defecto falla o las instalaciones de plugins se niegan a funcionar. Si buscaste “cloudflare emdash free” y chocaste con un muro, casi siempre es este muro.

La división es limpia:

• Plan gratis: CMS completo, solo plugins de config nativa (plugins: [] en astro.config.mjs, corren en-proceso). Sin marketplace, sin registro, sin plugins en sandbox.
• Workers Paid (5 $/mes): los plugins en sandbox del registro se instalan en tu bucket R2 y corren como Dynamic Workers con comprobaciones de capacidad por plugin (content:read, email:send, etc.).

Una restricción más si vas a pago: los plugins en sandbox son solo-D1. El puente de plugins sandbox habla directamente con un binding D1, así que si planeabas adaptadores de base de datos exóticos con plugins en sandbox, no lo hagas.

Diagrama de decisión gratis vs de pago: la necesidad de plugins en sandbox lleva a Workers Free con LOADER quitado versus Workers Paid a cinco dólares al mes

Lo que necesitas antes de desplegar EmDash

Nada exótico, y nada fuera de Cloudflare. Sin VPS, sin Docker, sin cuenta S3 externa, sin proveedor de email de terceros requerido.

El desarrollo local no necesita ninguna de las piezas de Cloudflare. La ruta Node.js/SQLite con almacenamiento local() y el stub de email por consola corre en un portátil. Si aún no has construido un sitio en local, sigue primero el tutorial de EmDash CMS, luego vuelve aquí para el deploy.

Dos puntos de partida: plantilla EmDash o sitio Astro existente

O creas desde cero o portas lo que tienes. Ambos aterrizan en el mismo sitio: wrangler.jsonc con bindings nombrados, src/worker.ts, y una integración EmDash cableada a D1 y R2. Mi default para un sitio nuevo es plantilla-primero. Son menos piezas móviles y los nombres de binding ya coinciden.

npm create emdash@latest
# pick a Cloudflare template: blog, marketing, portfolio, starter, or blank
npm install
npx wrangler login
npm run build
npm run deploy

Un tercer punto de partida: el tema gratis Biolink

Si lo que quieres es una página link-in-bio en vez de un blog, sáltate el scaffolding por completo. Biolink es un tema EmDash gratis que mantengo exactamente para eso: cabecera de perfil, más de 30 iconos sociales, tarjetas de enlaces, listas de enlaces, tarjetas de proyectos, bloques de texto, imagen y embed, todo editado como bloques reordenables en el admin. Diez esquemas de color, modos claro/oscuro/sistema, theming por página, y sin plugins requeridos, lo que significa que corre en Workers Free sin quitar nada.

Dos rutas de deploy:

1. El botón Deploy to Cloudflare en el README del repo entrega el repo a Workers Builds, que te guía por un formulario y luego clona, buildea y despliega por ti. Lo que pide el formulario:

   • Un nombre de proyecto y una conexión a GitHub — autorizas GitHub, y Workers Builds crea un repositorio privado bajo tu cuenta desde el que buildea en cada push.
   • Una nueva base de datos D1 (nombre y ubicación) y un bucket R2 (pista de ubicación) — los defaults valen.
   • Una EMDASH_ENCRYPTION_KEY — el único campo que traes tú. Genérala primero desde cualquier checkout de EmDash con npx emdash secrets generate y pégala en el formulario.
   • Los comandos de build vienen prellenados (equivalente a npm run build + npm run deploy); la corrida tarda un minuto o dos con los logs en streaming en el dashboard.

   Dos cosas hacen tropezar en esta ruta. El primer deploy falla en R2 si el servicio de almacenamiento aún no está activo en la cuenta — activarlo pide la tarjeta de crédito o PayPal de los prerequisitos, luego le das a deploy otra vez. Y una vez termina el build, EMDASH_SITE_URL aún hay que fijarla antes del asistente de setup (el aviso de abajo cubre por qué).

2. CLI, si lo quieres primero en local:

npm create astro@latest -- my-links --template github:bitdoze/emdash-biolink-theme --no-ai
cd my-links
npm install
npx wrangler login
npm run deploy   # astro build && wrangler deploy

El primer deploy aprovisiona la base de datos D1 emdash-biolink y el bucket R2 emdash-biolink-media por nombre, igual que la ruta de plantilla de arriba. Renómbralos en wrangler.jsonc si quieres los tuyos propios. npm run dev funciona sin cuenta de Cloudflare, en workerd con emulación local de D1 y R2, y el asistente de setup siembra una colección Bio Pages más un perfil demo que puedes editar o reemplazar.

¿Cuánto cuesta correr un sitio Biolink desplegado? Este es su dashboard de D1 en 24 horas:

Métricas D1 de un sitio EmDash Biolink desplegado en 24 horas: 39k queries totales, 56k filas leídas, 3k filas escritas, 1,41 MB de almacenamiento en 69 tablas, todo en la región EEUR

El ritmo plano de ~400-queries-por-15-minutos es el cron de cada-minuto haciendo sus rondas: comprobaciones de publicación programada, mantenimiento, contabilidad de backups. Eso son ~39k queries D1 y 1.440 invocaciones de Worker al día con casi ningún tráfico de visitantes, exactamente el coste de fondo del que advierte la tabla de límites de arriba. Daño total en Workers Free: 0 $, y con 1,41 MB de almacenamiento usado el tope de tamaño de D1 no es algo en lo que este sitio vaya a pensar jamás.

Los bindings explicados: cableando EmDash a D1 y R2

Esta es la sección que el doc oficial de deploy recorre rápido y donde los deploys fallan en la práctica. Los adaptadores Cloudflare de EmDash se enlazan a recursos nombrados por cadena. Los nombres en wrangler.jsonc y los nombres en astro.config.mjs deben coincidir exactamente, u obtienes “D1 binding not found” en tiempo de request.

Diagrama de arquitectura de EmDash en Cloudflare Workers: navegador a edge cache a Worker, enlazado a D1, R2, KV, Images, Email Sending y un cron trigger

wrangler.jsonc: DB, MEDIA, LOADER y el cron de cada minuto

La config de la plantilla, anotada:

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "my-emdash-site",
  "main": "./src/worker.ts",
  "compatibility_date": "2026-02-24",
  "compatibility_flags": ["nodejs_compat"],
  "d1_databases": [
    { "binding": "DB", "database_name": "my-emdash-site" }
  ],
  "r2_buckets": [
    { "binding": "MEDIA", "bucket_name": "my-emdash-media" }
  ],
  "worker_loaders": [{ "binding": "LOADER" }],   // omit on Free plan
  "triggers": { "crons": ["* * * * *"] }
}

Qué hace cada pieza y dónde muerde:

• DB y MEDIA son nombres de contrato. Deben coincidir con d1({ binding: "DB" }) y r2({ binding: "MEDIA" }) en la config de integración de EmDash. Renombra un lado y obtienes un error de binding-not-found en el primer request.
• Wrangler crea la base de datos D1 y el bucket R2 en el primer deploy si esos nombres no existen. Mantén los nombres estables. Cambiar database_name después no mueve tu contenido, aprovisiona una base de datos nueva y vacía y la vieja se convierte en huérfana.
• triggers.crons es el default de cada-minuto. La publicación programada, las tareas de plugins, los backups JSON automáticos y el mantenimiento cabalgan sobre él. Ajústalo, pero ajústalo en dos sitios (siguiente subsección).
• Adiciones opcionales: "kv_namespaces": [{ "binding": "CACHE" }] para la caché de objetos, "send_email": [{ "name": "EMAIL" }] para magic links, "images" (normalmente auto-añadida por el adaptador), "routes" para un dominio personalizado, "placement" para placement dirigido.

La variante del plan gratis es una eliminación. Lado a lado:

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "my-emdash-site",
  "main": "./src/worker.ts",
  "compatibility_date": "2026-02-24",
  "compatibility_flags": ["nodejs_compat"],
  "d1_databases": [
    { "binding": "DB", "database_name": "my-emdash-site" }
  ],
  "r2_buckets": [
    { "binding": "MEDIA", "bucket_name": "my-emdash-media" }
  ],
  "triggers": { "crons": ["* * * * *"] }
}

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "my-emdash-site",
  "main": "./src/worker.ts",
  "compatibility_date": "2026-02-24",
  "compatibility_flags": ["nodejs_compat"],
  "d1_databases": [
    { "binding": "DB", "database_name": "my-emdash-site" }
  ],
  "r2_buckets": [
    { "binding": "MEDIA", "bucket_name": "my-emdash-media" }
  ],
  "worker_loaders": [{ "binding": "LOADER" }],
  "triggers": { "crons": ["* * * * *"] }
}

Para sitios de contenido que preferirían no correr sobre D1 en absoluto, la alternativa en el mundo Astro es Astro DB con una base de datos PostgreSQL en Bunny. Dentro de EmDash en Cloudflare, sin embargo, D1 es el camino de menor resistencia y el que el puente de plugins sandbox requiere.

Truco útil para la sección de placement más adelante: pnpm wrangler d1 info my-emdash-site imprime los detalles de la base D1 incluyendo su ubicación primaria. Querrás ese valor.

astro.config.mjs y src/worker.ts

La config de integración:

import { defineConfig } from "astro/config";
import cloudflare from "@astrojs/cloudflare";
import react from "@astrojs/react";
import emdash from "emdash/astro";
import { d1, r2, sandbox } from "@emdash-cms/cloudflare";

export default defineConfig({
  output: "server",
  adapter: cloudflare(),
  integrations: [
    react(), // required: admin UI is a React app
    emdash({
      database: d1({ binding: "DB" }),
      storage: r2({ binding: "MEDIA" }),
      sandboxRunner: sandbox(), // omit on Free plan
    }),
  ],
});

Y el entry del Worker:

import handler, { createScheduledHandler, PluginBridge } from "@emdash-cms/cloudflare/worker";

export { PluginBridge };
export default {
  ...handler,
  scheduled: createScheduledHandler(),
} satisfies ExportedHandler;

createScheduledHandler() es lo que corre la publicación programada, las tareas de plugins, los backups y el mantenimiento cuando dispara el cron. PluginBridge solo se necesita para plugins en sandbox, pero los docs recomiendan mantenerlo exportado; es inofensivo sin ellos.

Dos trampas en estos archivos:

1. Las rutas de importación derivan entre fuentes. El README de GitHub muestra import { d1 } from "emdash/db" mientras los docs de despliegue usan @emdash-cms/cloudflare. El proyecto se mueve rápido. Comprueba qué importa la plantilla generada y cita eso, no un post de blog (incluido este).
2. Si cambias la expresión cron, cámbiala en ambos sitios. triggers.crons en wrangler.jsonc y createScheduledHandler({ generalCron: "..." }) deben coincidir. Si difieren, el handler loguea e ignora el trigger inesperado. La publicación programada simplemente para, en silencio.

Primer deploy de EmDash con wrangler: login, build, envío

pnpm wrangler login
pnpm build
pnpm wrangler deploy

El primer deploy aprovisiona la base de datos D1 y el bucket R2 por nombre y devuelve una URL workers.dev inmediatamente. Ábrela. Deberías obtener una página renderizada (o el asistente de setup si la base de datos está vacía).

Demuestra que funcionó antes de seguir:

El fallo se ve como un 500 en la página pública (entonces wrangler tail y lee el mensaje) o un error de binding-faltante (entonces la comprobación de desajuste de nombres de arriba). La URL workers.dev es tu señal limpia de que la app funciona antes de que el DNS entre en escena. Mantenla viva mientras añades el dominio personalizado.

Migraciones, datos semilla y el primer request

EmDash por defecto usa modo de migración auto. En Cloudflare eso significa que el primer request al Worker desplegado aplica las migraciones de núcleo pendientes. El archivo semilla (.emdash/seed.json, con fallback a package.json#emdash.seed, luego seed/seed.json) se inlina en build time y solo aplica si la base de datos está vacía y el setup no está completo. Los deploys posteriores dejan el contenido en paz.

Para pipelines de CI que deban aplicar migraciones antes de que el código nuevo reciba tráfico, cambia a modo de migración explícito en vez de confiar en la auto-migración del primer request; la página “Manage core database migrations” de los docs cubre el setup del pipeline. Si una migración falla, pnpm wrangler tail, reproduce el request, y lee el mensaje subyacente. Los errores de migración rara vez son silenciosos, solo están enterrados en el stream.

Dominio personalizado, placement y caching

Una vez workers.dev está en verde, ponlo en tu dominio. En wrangler.jsonc:

{
  "routes": [{ "pattern": "www.example.com", "custom_domain": true }]
}

El dominio debe ser una zona Cloudflare activa en la misma cuenta que el Worker. El orden de operaciones importa: pon el Worker sirviendo en workers.dev primero, luego añade la ruta, despliega otra vez, y verifica ambas URLs. Mantener workers.dev vivo durante las pruebas de DNS te ayuda a distinguir un problema de routing de un problema de aplicación. Contexto de límites: 100 dominios personalizados por zona, 1.000 rutas por zona.

Diagrama de ruta de request y caching: el hit de Workers Cache se salta el Worker, el miss corre SSR contra D1 cerca del primario con Targeted Placement

Targeted Placement cerca de tu primario D1

El SSR de EmDash hace varias idas y vueltas a D1 por request. Corre el Worker en el edge del visitante y cada query paga un salto de red a dondequiera que esté el primario D1. Targeted Placement ancla la ejecución cerca de la base de datos en su lugar. Suena al revés, pero es el intercambio correcto para una app SSR pesada en base de datos: cuando el Worker pasa su tiempo esperando a la base de datos de una región, correrlo cerca del usuario solo añade saltos.

La config del doc de deploy de EmDash:

{
  "placement": {
    "mode": "targeted",
    "region": "weur" // exactly one selector: region, host, or hostname
  }
}

Elige el selector que coincida con la ubicación de tu primario D1 (pnpm wrangler d1 info my-emdash-site la imprime). Dos reglas duras de los docs: no actives réplicas de lectura D1 junto a Targeted Placement, y mantén el ajuste session de EmDash en el default "disabled" para que lecturas y escrituras golpeen el primario cercano.

Verifica con el header de respuesta cf-placement: remote-LHR versus local-EWR te dice dónde corrió el Worker.

Caché de objetos KV y Workers Cache (dos gotchas)

Dos cachés separadas. La gente las confunde; Cloudflare no.

La caché de objetos KV cachea resultados de queries de contenido y config para reducir la carga de lectura en D1:

import { kvCache } from "@emdash-cms/cloudflare";

emdash({
  database: d1({ binding: "DB" }),
  storage: r2({ binding: "MEDIA" }),
  objectCache: kvCache({ binding: "CACHE" }),
});

Añade la entrada "kv_namespaces" correspondiente enlazada como CACHE en wrangler.jsonc. En el plan gratis, fíjate en el tope de escrituras KV: 1.000 escrituras/día (las lecturas son 100k/día). Las escrituras de invalidación de caché de objetos en un día editorial intenso son lo que se come ese presupuesto. No afirmo que lo vayas a golpear; digo que el tope existe y la invalidación de caché es lo que lo consume.

Workers Cache se sienta delante del Worker por completo. Un hit ni siquiera invoca el Worker:

import { cacheCloudflare } from "@astrojs/cloudflare/cache";

export default defineConfig({
  adapter: cloudflare(),
  cache: { provider: cacheCloudflare() },
  routeRules: { "/": { maxAge: 300, swr: 86400 } },
});

La invalidación pasa por cache.purge():

import { cache } from "cloudflare:workers";

await cache.purge({ purgeEverything: true });
// or targeted: { tags: ["posts"] }

Los dos gotchas, ambos de los propios docs de despliegue de EmDash:

1. Caching heurístico. Las respuestas sin header Cache-Control igualmente se cachean (frescura heurística RFC 9111; un 200 sin header se trata como cacheable por un par de horas). Toda ruta personalizada necesita Cache-Control explícito. Cualquier cosa dependiente de sesión lleva private, no-store.
2. Los editores logueados ven la página cacheada. La caché no puede hacer bypass por cookies, así que un editor con sesión puede recibir la variante anónima cacheada: sin barra de edición visual, sin preview de borradores, hasta expiración o purge.

Nota de precios para presupuestar el plan gratis: los hits de Workers Cache se facturan como requests aunque sirvan desde caché (sin CPU cargada). Siguen comiéndose la asignación gratis de 100k/día.

Medios en R2: dominios públicos, la mina de backups/, facturación de Images

Por defecto los medios se sirven por la ruta de medios autenticada de EmDash en /_emdash/api/media/file/.... Sin bucket público necesario, y ese es el default seguro. Déjalo así hasta que tengas una razón para no hacerlo.

La aceleración opcional es un dominio personalizado del bucket como publicUrl:

storage: r2({ binding: "MEDIA", publicUrl: "https://media.example.com" })

Si usas un dominio público, conoce el trade-off: los medios por URL de bucket pasan por el endpoint de transform del adaptador que hace fetch por HTTP, mientras los medios de ruta interna leen directo del binding R2 sin fetch y siguen funcionando detrás de Cloudflare Access o global_fetch_strictly_public.

Luego está la sorpresa de facturación escondida en el binding Images. El adaptador @astrojs/cloudflare auto-añade el binding IMAGES en build time cuando el servicio de imágenes de runtime es cloudflare-binding. Para ver lo que un deploy realmente obtuvo, lee el dist/server/wrangler.json generado (o .wrangler/deploy/config.json), no tu wrangler.jsonc. Verifica el despliegue que obtuviste, no el que escribiste.

La facturación de transforms cuenta cada combinación única de imagen fuente y set de parámetros una vez por mes natural; las repeticiones dentro del mes son gratis. 500 imágenes por (thumbnail + hero) son 1.000 transforms únicos/mes, que cabe en gratis. 2.000 imágenes por 5 tamaños son 10.000, que se pasa.

Última advertencia de medios: los backups de base de datos contienen metadatos de medios, no los archivos almacenados. Los medios de R2 no están en tus backups de D1 ni en tus backups JSON. Haz backup del backend de almacenamiento aparte si los archivos importan. Este es el único hueco versus un setup con S3 donde ya tienes un pipeline de sync corriendo.

Email para magic links: un setup aparte

Los Workers de producción no tienen entrega de email por defecto. Los magic links, invitaciones y notificaciones devuelven 503 EMAIL_NOT_CONFIGURED hasta que un plugin de email está activo. Esto quemó a bastante gente antes de la 1.0 (issue #1431 de GitHub, “No production email provider on Cloudflare Workers”, cerrado vía #1433 para el hito 1.0). El arreglo es el plugin oficial cloudflareEmail sobre Cloudflare Email Sending: onboarding del dominio remitente, un binding send_email en wrangler.jsonc, luego activación bajo Extensions y Settings -> Email. Esa cadena tiene suficientes piezas móviles para tener su propio tutorial en esta serie en vez de una versión comprimida aquí.

Secrets y entornos de preview

Los secrets de plugins están cifrados en reposo, y la clave de cifrado es tuya de gestionar. Genera un valor, luego guárdalo como secret del Worker:

npx emdash secrets generate
pnpm wrangler secret put EMDASH_ENCRYPTION_KEY

Ponlo antes de guardar cualquier secret de plugin en el admin. Guarda una copia de la clave fuera de los backups de D1; si la pierdes, los secrets cifrados son irrecuperables. La rotación es en dos fases: añade la clave nueva primero, mantén las viejas separadas por comas, re-guarda cada secret de plugin, luego suelta las claves viejas.

Los secrets de preview van al env nombrado: pnpm wrangler secret put <NAME> --env preview.

Entornos de preview. Los entornos Wrangler nombrados no heredan bindings de la config de nivel superior. Cada binding debe repetirse bajo env.preview:

pnpm wrangler d1 create my-emdash-site-preview --binding DB --env preview --update-config
pnpm wrangler r2 bucket create my-emdash-media-preview --binding MEDIA --env preview --update-config
pnpm build
pnpm wrangler deploy --env preview

Repite los bindings opcionales (KV, email, loader) del mismo modo. Los secrets solo-de-preview usan --env preview. Dos reglas: nunca apuntes un binding de preview a D1 o R2 de producción, y recuerda que el primer request de preview aplica migraciones, igual que en producción. En el plan gratis, los recursos de preview cuentan contra las mismas cuotas (10 bases de datos D1 por cuenta caben prod más unas cuantas previews; el almacenamiento R2 se dobla con cada bucket de preview).

Coste mensual real: tres ejemplos trabajados

1. Blog personal o sitio folleto pequeño: 0 $/mes. Workers Free, una base de datos D1 que se queda de tamaño metadatos (ni cerca de 500 MB salvo que importes un archivo WordPress con años de revisiones), medios R2 bajo 10 GB, caché de objetos KV, unos miles de transforms de imagen al mes. El cron de cada-minuto cuesta 1.440 requests/día de tus 100k. Un sitio pequeño con caching delante no notará el resto.

2. Sitio pequeño o medio con plugins: 5 $/mes. Workers Paid te da plugins en sandbox (SEO, formularios, lo que sea del registro), bases D1 de 10 GB, Time Travel de 30 días, margen de escrituras KV, y un límite de CPU por defecto de 30 segundos. La mayoría de sitios en esta clase ni se acercan a los 10M requests y 30M CPU-ms incluidos.

3. 5 $/mes más overages: los cables trampa. Images pasados 5.000 transforms únicos (0,50 $ por 1.000: 500 imágenes fuente a 2 tamaños se queda gratis, 2.000 a 5 tamaños corre unos 2,50 $/mes). Escrituras KV pasado 1M/mes (5 $/M, solo si la invalidación de caché de objetos churrasca mucho). Lecturas D1 pasados 25B/mes (0,001 $/M, un número que no alcanzarás en un sitio de contenido).

La victoria de ops versus la ruta de servidor: sin servidor que parchear, sin pipeline de backup a S3 que vigilar (EmDash escribe backups JSON a R2 en el cron), y D1 Time Travel reemplaza los rituales de point-in-time-restore. El caveat es el de la sección de medios: los medios R2 no están en esos backups de base de datos. Si ya corres backups S3 en otro sitio, el sync de medios es el único hueco que cerrar.

Los números reales de un sitio vivo: emdashhq.com

emdashhq.com es mi propio hub de EmDash (los tutoriales, temas y plugins para este CMS, incluido el tema Biolink de arriba) corriendo sobre este stack exacto: Workers, D1, R2, dominio personalizado, Workers Cache delante. Como los ejemplos trabajados de arriba son estimaciones, así se ve un despliegue real en las últimas 24 horas.

Métricas de Cloudflare Workers para emdashhq.com en 24 horas: 863 invocaciones, 0 errores, ~50 ms de tiempo CPU mediano, 608 ms de duración mediana de request, 59,95% de hit rate de Workers Cache API, 90,43% de hit rate de caché de assets

Lee el dashboard así:

• 863 invocaciones, 0 errores. Un sitio de contenido de bajo tráfico. Incluso a 10x esto, el tope gratis de 100k requests/día está lejos.
• Tiempo CPU mediano ~50 ms. Este es el número que importa para elegir plan: por encima de la línea de 10 ms del plan gratis, así que un sitio con esta forma necesita Workers Paid o caching mucho más agresivo. El ensamblado SSR es trabajo de CPU real, exactamente lo que la tabla de límites advertía.
• 59,95% de hit rate de Workers Cache API, 90,43% de hit rate de caché de assets. La caché absorbe la mayoría de repeticiones; las invocaciones que quedan son tráfico de admin, misses de caché y el cron.
• Duración de request ~600 ms mediana contra ~50 ms de CPU. La mayoría del reloj de pared es espera a D1 y R2, por eso Targeted Placement cerca del primario D1 (EEUR, ver abajo) importa más que limar código.

Y el lado de base de datos del mismo sitio:

Métricas D1 de la base de datos emdashhq en 24 horas: 14k queries totales, 62k filas leídas, 160 filas escritas, 1,82 MB de almacenamiento en 73 tablas, región Europa del Este

Dos conclusiones. Primero, ~14k queries contra 863 invocaciones son aproximadamente 16 idas y vueltas D1 por invocación de Worker, ticks de cron incluidos: la afirmación de “varias idas y vueltas D1 por request” no es teórica. Segundo, 1,82 MB en 73 tablas. El esquema de EmDash es ancho pero los datos son diminutos, y las lecturas superan a las escrituras 400 a 1 en un sitio de contenido. El tamaño de D1 y los límites de escritura son lo último que golpearás; el conteo de requests y la CPU son lo primero.

Troubleshooting: qué se rompe en EmDash en Cloudflare Workers

Síntoma, causa, arreglo. Los primeros cuatro cubren la mayoría de fallos de noche-de-deploy.

Checklist de verificación pre-vuelo

Corre esto antes de dar el deploy por hecho. Es el “Verify the deployment” de los docs más las comprobaciones de operador que los docs asumen que ya conoces.

Si quieres una ruta de rollback antes de necesitarla: pnpm wrangler rollback restaura la versión de despliegue anterior. Para teardown, pnpm wrangler delete elimina el Worker, y pnpm wrangler d1 delete / pnpm wrangler r2 bucket delete eliminan los almacenes de datos (irreversible; exporta primero si hay contenido que te importe).

EmDash en Cloudflare Workers vs un VPS de 5 euros

Paso la mayor parte de mi vida laboral en flotas de servidores, y mi default para proyectos autoalojados es un VPS barato corriendo un PaaS autoalojado. Así que así se comparan los dos.

EmDash en Cloudflare gana en: cero servidores que parchear, economía de scale-to-zero, D1 Time Travel para recuperación a punto-en-tiempo, y todo en una cuenta (sin proveedor de email, sin proveedor de S3, sin malabares de DNS). Para un sitio de contenido en solitario que debería costar nada, este es el default correcto.

La ruta VPS gana en: acceso shell cuando algo va mal, flexibilidad de cron más allá del modelo Workers, sin acoplamiento a proveedor, un precio de máquina plano que incluye toda la CPU que el kernel te dé, y la capacidad de correr el resto de tu stack en la misma máquina. Para ese lado del intercambio, mira cómo desplegar Astro en un VPS con CloudPanel y nuestra comparación de opciones PaaS autoalojadas Coolify vs Dokploy vs Kamal 2. Mi propio default es aproximadamente un VPS de 5 euros al mes de Hetzner Cloud corriendo Dokploy, con backups compatibles-S3 para cualquier cosa que importe.

Regla general: sitio de contenido en solitario que debería costar cero, se queda dentro de un dominio, y no necesita jobs de fondo más allá de un cron de publicación -> Workers. Cualquier cosa que necesite otros servicios, trabajo longevo, o libertad de Cloudflare específicamente -> el VPS. Si mantienes un homelab y quieres exposición de nivel-Cloudflare sin Cloudflare, Pangolin es una alternativa autoalojada a Cloudflare Tunnels.

FAQ: desplegando EmDash en Cloudflare

Cierre

Despliega EmDash en Cloudflare Workers esta noche y no cuesta nada si quitas el binding LOADER, o 5 $/mes si quieres el marketplace de plugins. Los bindings son todo el juego: DB a D1, MEDIA a R2, CACHE opcional a KV, un cron que debe coincidir en dos sitios, y un bucket de medios que nunca debe exponer backups/. Corre la checklist pre-vuelo antes de dar el deploy por hecho.

Esa es la parte 4 de la serie EmDash CMS: la ruta de despliegue en Cloudflare, sus límites, y su precio.