Crear Páginas Web con Lógica de NegocioBeta

0%
Bloque Ejecutivo

Módulo 06

Despliegue: de tu computador a producción

1.5hVercelGitHubDNSResend

Variables de entorno, checklist de seguridad, deploy en Vercel, dominio propio con HTTPS y la prueba de fuego del ciclo completo en producción.

Recursos descargables

Checklist de Lanzamiento a Producción

Los 35 puntos del día del lanzamiento en 8 bloques — código, variables, base de datos, pagos, auth, dominio, crons y post-lanzamiento — más el ciclo de humo final

Markdown
En este módulo
01
Variables de entorno: un código, dos mundos Cómo el mismo proyecto corre en tu máquina y en producción sin tocar una línea

ReservaYa funciona perfecto… en localhost:3000, con llaves sandbox y la tarjeta de prueba 4242. Pero Julián no puede cobrar anticipos reales desde tu computador. Falta el último salto: que la app viva en internet, con dominio propio, candado verde y las llaves de verdad.

La diferencia entre desarrollo y producción no debería ser el código — solo la configuración. De eso se encargan las variables de entorno.

1.1. El inventario de secretos de ReservaYa

Todo lo que construiste depende de estas variables. En producción tendrán otros valores — mismas llaves de casa, distinta cerradura:

VariableEn desarrolloEn producción
NEXT_PUBLIC_SUPABASE_URLProyecto de pruebasProyecto productivo (ideal: separado)
NEXT_PUBLIC_SUPABASE_ANON_KEYanon de pruebasanon productiva
SUPABASE_SERVICE_ROLE_KEYservice_role de pruebas⚠ La más peligrosa: salta RLS. Solo servidor.
NEXT_PUBLIC_WOMPI_PUBLIC_KEYpub_test_…pub_prod_…
WOMPI_INTEGRITY_SECRET / WOMPI_EVENTS_SECRETde sandboxde producción (requiere cuenta aprobada)
RESEND_API_KEYremitente de pruebadominio verificado
WHATSAPP_TOKEN / WHATSAPP_PHONE_IDnúmero de prueba de Metanúmero del negocio
CRON_SECRETcualquier stringstring aleatorio largo (openssl rand -hex 32)
NEXT_PUBLIC_APP_URLhttp://localhost:3000https://donbarbas.co
Las URLs no se escriben en el código

En los módulos anteriores escribimos http://localhost:3000 directo en redirect-url y emailRedirectTo. Antes de desplegar, reemplázalas por process.env.NEXT_PUBLIC_APP_URL. Buscar localhost en todo el proyecto (Ctrl+Shift+F) es parte del checklist de lanzamiento.

02
Seguridad básica antes de lanzar La revisión de 30 minutos que evita el desastre de la semana 1

No necesitas ser experto en seguridad para lanzar con dignidad: necesitas verificar que las defensas que ya construiste están activas. Este es el repaso, capa por capa:

  • Checklist de seguridad pre-lanzamiento
  • RLS activo en todas las tablas — dashboard de Supabase sin alertas rojas en Database → Tables
  • Toda Server Action valida con Zod y verifica sesión/rol antes de tocar datos
  • Ningún secreto con prefijo NEXT_PUBLIC_ salvo los diseñados para ser públicos (URL y anon de Supabase, llave pública de Wompi)
  • .env.local fuera del repositorio — revisa el historial de git, no solo el estado actual
  • Webhook verifica firma + idempotencia + monto (módulo 4)
  • Rutas de cron protegidas con CRON_SECRET (módulo 5)
  • Mensajes de error genéricos — nada de stack traces ni "el email no existe" hacia el usuario
  • Backups activados — Supabase hace backup diario automático; verifica que tu plan lo incluye

2.1. Cabeceras de seguridad en 10 líneas

Next.js permite añadir cabeceras HTTP que endurecen la app contra ataques comunes (clickjacking, sniffing de tipos):

// next.config.ts — cabeceras de seguridad básicas
const nextConfig = {
  async headers() {
    return [{
      source: "/(.*)",
      headers: [
        { key: "X-Frame-Options", value: "DENY" },            // nadie te mete en un iframe
        { key: "X-Content-Type-Options", value: "nosniff" },   // no adivinar tipos de archivo
        { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
      ],
    }];
  },
};

export default nextConfig;
⚙ ¿Y el rate limiting?

Limitar peticiones por IP (para que un bot no haga 10.000 reservas por minuto) se resuelve con Vercel Firewall (plan Pro) o con @upstash/ratelimit + Redis gratuito en el middleware. Para el lanzamiento de un negocio local, las restricciones unique de la base de datos y el anticipo obligatorio ya frenan el abuso más probable; agrega rate limiting cuando tengas tráfico real.

03
Deploy en Vercel paso a paso De git push a URL pública en 10 minutos

Vercel (los creadores de Next.js) despliega directo desde GitHub: cada git push a main publica una versión nueva. El plan Hobby es gratuito y suficiente para ReservaYa.

  1. Importa el repositorio

    En vercel.comAdd New → Project, autoriza GitHub y selecciona reservaya. Vercel detecta Next.js solo; no cambies nada del build.

  2. Carga las variables de entorno

    En Settings → Environment Variables pega el inventario de la sección 1 con los valores de producción. Marca SUPABASE_SERVICE_ROLE_KEY y demás secretos como Sensitive.

  3. Primer deploy

    Clic en Deploy. En ~2 minutos tienes https://reservaya.vercel.app funcionando con HTTPS incluido.

  4. Actualiza las URLs en los servicios externos

    El mundo exterior aún apunta a tu túnel de desarrollo. Cambia:

    • Wompi → Eventos: URL del webhook a https://reservaya.vercel.app/api/webhooks/wompi
    • Supabase → Authentication → URL Configuration: Site URL y Redirect URLs con el dominio nuevo
    • NEXT_PUBLIC_APP_URL en Vercel con el dominio final
  5. Prueba el ciclo completo en producción

    Registro → reserva → pago sandbox → webhook → email de confirmación. Solo cuando este ciclo funciona en la URL pública, solicita a Wompi las llaves productivas.

Cada push a main es un deploy

Vercel también crea una URL de preview por cada rama: puedes probar cambios grandes en una URL temporal sin tocar la app que usan los clientes de Julián. Es el flujo profesional, gratis.

04
Dominio propio y HTTPS donbarbas.co con candado verde — la señal de confianza que tus clientes esperan

Nadie escribe su tarjeta en reservaya.vercel.app. El dominio propio no es vanidad: es la señal de confianza mínima para cobrar en línea.

4.1. Comprar y conectar el dominio

  1. Compra el dominio

    En Namecheap, Cloudflare Registrar o GoDaddy: donbarbas.co (~USD $10–30/año según extensión). Los .co, .mx, .com.ar locales generan más confianza que un .xyz barato.

  2. Agrégalo en Vercel

    Settings → Domains → Add. Vercel te da los registros DNS exactos: un A apuntando a su IP para donbarbas.co y un CNAME para www.

  3. Configura el DNS en el registrador

    Copia esos registros en el panel DNS de donde compraste el dominio. La propagación tarda de minutos a algunas horas.

  4. HTTPS automático

    Vercel emite y renueva el certificado SSL (Let's Encrypt) solo. Cuando el dominio resuelva, el candado ya está ahí — no hay que comprar ni instalar certificados.

  5. Verifica el dominio de email

    En Resend agrega los registros TXT (SPF y DKIM) al mismo DNS para enviar desde citas@donbarbas.co. Sin esto, tus confirmaciones caen a spam.

¿Por qué HTTPS no es negociable?

HTTPS cifra todo lo que viaja entre el navegador y tu servidor: contraseñas, teléfonos, referencias de pago. Sin él, cualquier persona en la misma red WiFi puede leer los datos de tus clientes. Además Wompi y las demás pasarelas exigen HTTPS para los webhooks y las URLs de redirección — sin candado no hay pagos.

✗ Errores comunes al lanzar
  • Desplegar con las llaves sandbox y "después las cambio". Solución: checklist de lanzamiento con el inventario completo de variables. Un cliente pagando a un sandbox es una venta perdida silenciosa.
  • Olvidar actualizar la URL del webhook en Wompi. Solución: los pagos se aprueban pero las citas nunca se confirman — el bug más confuso de depurar. La URL del webhook es parte del deploy, no un extra.
  • Usar el mismo proyecto de Supabase para pruebas y producción. Solución: el plan gratuito da 2 proyectos: uno para desarrollo, otro productivo. Tus experimentos no deben poder borrar citas reales.
  • Lanzar y no mirar nunca los logs. Solución: Vercel → Logs y Supabase → Logs son tu tablero de salud. Revisa la primera semana a diario: ahí aparecen los errores que ningún cliente te va a reportar.
✏ Ejercicio: el plan de lanzamiento de tu proyecto

Toma el negocio que modelaste en los módulos anteriores (tienda, restaurante o consultorio) y escribe su plan de lanzamiento:

  1. Inventario de variables: lista cada servicio externo que usa y qué variables de entorno necesita en producción.
  2. Las 3 URLs que hay que actualizar al pasar de localhost a dominio real (webhook, redirects de auth, redirect de pago). ¿En qué panel se cambia cada una?
  3. Elige el dominio: escribe 3 opciones con extensión local de tu país y verifica disponibilidad y precio en un registrador.
  4. Define tu ritual post-lanzamiento: qué logs revisas, con qué frecuencia, y cuál es tu plan si un pago se aprueba sin confirmar el pedido.

El checklist de lanzamiento completo (35 puntos) está en los recursos descargables del módulo.

4.2. Mini-proyecto final: ReservaYa en vivo

🏁
ReservaYa · Entrega final

El cierre del curso: ReservaYa desplegado en Vercel con dominio propio y HTTPS, variables de producción cargadas, webhook de Wompi apuntando al dominio real, emails saliendo desde el dominio verificado y el ciclo completo probado de punta a punta: un cliente se registra, reserva, paga el anticipo, recibe su email de confirmación y su recordatorio de WhatsApp — sin que Julián toque nada. Esa es una aplicación web con lógica de negocio.

4.3. ¿Qué sigue después del curso?

Producto
Hazlo tuyo
Adapta ReservaYa a un negocio real de tu ciudad: canchas, spa, consultorios, restaurantes. El modelo de datos cambia; la arquitectura no.
Negocio
Véndelo como servicio
Lo que construiste es lo que agencias cobran USD $2.000–5.000 por implementar. Ya sabes hacerlo de punta a punta.
Técnica
Profundiza
Siguientes escalones: tests automatizados, observabilidad (Sentry), colas de trabajos, y multi-tenancy para servir varios negocios con una sola app.
✓ Lo que aprendiste en este módulo
  • El código no cambia entre entornos; la configuración sí. Variables de entorno separan desarrollo de producción, y los secretos jamás llevan NEXT_PUBLIC_.
  • La seguridad de lanzamiento es un checklist, no magia: RLS activo, validación en servidor, webhooks firmados, crons protegidos, backups y logs.
  • Deploy = push: Vercel publica desde GitHub con HTTPS automático; el trabajo real es actualizar las URLs en Wompi, Supabase y Resend.
  • Completaste el ciclo: de una landing estática a una aplicación en producción que registra, reserva, cobra y notifica sola. Eso es lógica de negocio en la web.