Despliegue

Al terminar esta página tendrás el sitio corriendo en Cloudflare contra la D1 y el R2 remotos, con el /admin accesible y el correo saliendo de verdad.

Son tres cosas, y una de ellas tiene un orden que no se puede invertir.

El orden importa

pnpm cms db:apply --remote
pnpm build && npx wrangler deploy

Las migraciones remotas van antes del deploy. Al revés, el Worker nuevo arranca contra el esquema viejo: consulta columnas que todavía no existen y cada lectura de esa colección responde 500 hasta que aplicas. La ventana dura lo que tardes en darte cuenta.

db:apply --remote pide confirmación antes de tocar nada, nombrando el binding:

Esto aplica las migraciones a la base de datos "DB" en PRODUCCIÓN. ¿Continuar?

El secreto de sesión

.dev.vars es solo local: wrangler no lo sube en el deploy y el fichero está en tu .gitignore. En producción, BETTER_AUTH_SECRET se guarda como secreto del Worker:

npx wrangler secret put BETTER_AUTH_SECRET

El comando lo pide por la entrada estándar y lo cifra en la cuenta de Cloudflare; no queda en ningún fichero del repositorio. Puede ser el mismo valor que usas en local o uno nuevo — cambiarlo invalida todas las sesiones abiertas, que es exactamente lo que quieres si sospechas que se filtró.

Sin ese secreto el Worker despliega, pero la autenticación no funciona. Los detalles, en Autenticación.

Qué cambia respecto a local

D1 y R2 son otros. La base y el bucket con los que trabaja wrangler dev son copias locales que viven en .wrangler/, no los recursos que creaste con wrangler d1 create y wrangler r2 bucket create. El contenido que escribiste probando no viaja: la instalación remota arranca vacía y /admin te enseña otra vez el asistente de configuración, con su primera cuenta y sus ajustes del sitio.

Por eso db:apply tiene dos modos: sin flag toca la copia local, con --remote la de verdad.
El correo sale de verdad. En local, wrangler dev simula el envío y vuelca el mensaje a un fichero temporal cuya ruta imprime; no hace falta dominio ni plan de pago. Desplegado no hay simulación que valga, así que los tres requisitos de plataforma tienen que estar cumplidos —plan Workers de pago, dominio con DNS de Cloudflare dado de alta en Email Sending, y un from de ese dominio— o el envío falla.

El flag "remote": true del binding send_email no es para producción: es lo que hace que tu máquina deje de simular y mande correo real desde wrangler dev, con esos mismos tres requisitos ya cumplidos. Sirve para ver cómo queda el mensaje en clientes reales; déjalo fuera mientras desarrolles.
La URL pública cambia. El ajuste siteUrl que guardaste desde local apunta a localhost:4321, y es de ahí de donde salen los enlaces de verificación y restablecimiento de los correos. En la instalación remota lo pone el asistente; si lo cambias después, se edita desde /admin/settings sin desplegar.

Si algo falla

Los fallos de un primer despliegue —nodejs_compat que falta, migraciones que wrangler no encuentra, MISSING_EMAIL en la primera sesión— están recogidos por síntoma en Solución de problemas.