De Local a Producción - Arquitectura Segura Paso a Paso

En local todo funciona. Base de datos en tu máquina, secrets en un .env y el servidor levantando con npm run dev.

El salto a producción es donde la mayoría de los problemas aparecen.

Esta guía es el recorrido completo: desde elegir dónde alojar hasta tener monitoreo activo y saber cómo hacer rollback si algo sale mal.

Paso 1: Elige tu plataforma de deploy

No hay una respuesta única. Depende de tu stack, tu equipo y tu presupuesto.

Vercel

Mejor para: Aplicaciones Next.js, frontend heavy o APIs serverless.

Qué te da:

Deploy automático desde GitHub en cada push
CDN global incluido
Preview deployments por rama
Serverless functions sin configuración

Limitaciones:

No ideal para procesos de larga duración (más de 10 segundos en plan gratuito)
Si tu app tiene workers o cron jobs pesados, necesitarás otra solución para eso
La BD no está incluida (necesitas Neon, PlanetScale, Supabase, etc.)

Precio: Gratis hasta cierto límite de bandwidth; $20/mes el plan Pro.

Railway

Mejor para: Apps full-stack con base de datos, workers, o cualquier proceso que necesite un servidor siempre activo.

Qué te da:

Deploy de cualquier Dockerfile o proyecto Node/Python/Go
PostgreSQL, MySQL, Redis incluidos en el mismo proyecto
Cron jobs nativos
Environments (staging, producción) bien diferenciados

Limitaciones:

Sin CDN global (necesitas Cloudflare si tu app es geográficamente dispersa)
Menos "mágico" que Vercel para Next.js

Precio: Desde $5/mes por servicio. Para una app + BD: ~$15-25/mes.

AWS / DigitalOcean

Mejor para: Apps con requisitos específicos de compliance, control total o costes muy altos en PaaS.

Lo malo: La curva de aprendizaje es mucho más alta. Si eres un equipo de 1-3 personas, probablemente no vale la pena ahora mismo. Empieza con Railway o Vercel y migra cuando lo necesites.

Paso 2: Variables de entorno correctas

Ya lo hemos visto en otros artículos, pero es tan crítico que lo repito:

# .env.local (local, nunca en Git)
DATABASE_URL=postgresql://user:pass@localhost/mydb_dev
STRIPE_KEY=sk_test_xxx
JWT_SECRET=dev-secret-insecure

# Producción (en Vercel/Railway dashboard)
DATABASE_URL=postgresql://user:pass@prod-host/mydb_prod
STRIPE_KEY=sk_live_xxx
JWT_SECRET=f8a3d9c2b1e4a7f6...  # Al menos 32 caracteres aleatorios

Regla básica: Dev y producción NUNCA comparten las mismas claves.

Genera el JWT secret así:

node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"

Paso 3: Base de datos en producción

Usa un servicio gestionado

No montes tu propia instancia de PostgreSQL si puedes evitarlo. Los servicios gestionados incluyen:

Backups automáticos
Actualizaciones de seguridad
Failover automático

Opciones: | Servicio | Stack | Plan gratuito | Backup | |----------|-------|---------------|--------| | Neon | PostgreSQL | Sí | Diario | | Supabase | PostgreSQL | Sí | Diario | | PlanetScale | MySQL | No (fue eliminado) | Diario | | Railway Postgres | PostgreSQL | No | Configurable |

Configura backups antes de ir a producción

No después. Antes.

Si usas Supabase:

# Backup manual
pg_dump -h your-host -U postgres -d your-db > backup-$(date +%Y%m%d).sql

Si usas Railway, habilita los snapshots automáticos desde el dashboard.

Cuánto guardar: Mínimo 7 días rolling de backups.

Usuario de BD con permisos mínimos

La app nunca debería conectarse como superusuario:

-- Crea un usuario con solo los permisos necesarios
CREATE USER app_user WITH PASSWORD 'secure-password';
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_user;
GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO app_user;

-- NO le des DROP, CREATE, TRUNCATE, etc.

Paso 4: Secretos y configuración de seguridad

Además de las variables de entorno, hay headers HTTP que deberías tener activos:

// next.config.js
const securityHeaders = [
  {
    key: 'X-DNS-Prefetch-Control',
    value: 'on'
  },
  {
    key: 'Strict-Transport-Security',
    value: 'max-age=63072000; includeSubDomains; preload'
  },
  {
    key: 'X-Frame-Options',
    value: 'SAMEORIGIN'
  },
  {
    key: 'X-Content-Type-Options',
    value: 'nosniff'
  },
  {
    key: 'Referrer-Policy',
    value: 'strict-origin-when-cross-origin'
  }
];

module.exports = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: securityHeaders,
      },
    ];
  },
};

Paso 5: Monitoreo de errores

Si no sabes que algo falla, no puedes arreglarlo. El monitoreo no es opcional.

Sentry (recomendado para empezar)

npm install @sentry/nextjs
npx @sentry/wizard@latest -i nextjs

Sentry captura:

Errores no capturados
Performance traces
Stack traces con contexto de usuario

Plan gratuito: 5,000 errores/mes. Suficiente para empezar.

Configura alertas

No sirve de nada tener Sentry si tardas 3 días en ver un error. Configura alertas por email o Slack para errores nuevos:

En Sentry: Alerts → Create Alert → Issue Alert → "A new issue is created" → Notify via email.

Paso 6: Logging

Los logs te dicen qué pasó cuando algo falla. Sin logs, depurar en producción es adivinar.

Vercel Logs

Vercel guardia logs de las últimas 24 horas en el plan gratuito. Para más:

// Usa console.log con estructura
console.log(JSON.stringify({
  event: 'user_signup',
  userId: user.id,
  timestamp: new Date().toISOString()
}));

Para Railway/Fly.io

Considera añadir Axiom, Logtail o Papertrail. Axiom tiene plan gratuito generoso.

Paso 7: Proceso de rollback

Antes de lanzar, define cómo vuelves atrás si algo sale mal.

En Vercel

Vercel guarda todos los deployments. Si el último falla:

Ve a tu proyecto → Deployments
Busca el último deployment estable
Haz clic en los tres puntos → "Promote to Production"

Tiempo: menos de 60 segundos.

En Railway

Railway también guarda el historial. En el dashboard:

Ve a tu servicio → Deployments
Selecciona el deployment anterior
"Rollback to this deployment"

Rollback de base de datos

Este es el más delicado. Si desplegaste una migración que corrompió datos:

# Conecta a la BD de producción
psql $DATABASE_URL

# Revierte la última migración
# Con Prisma:
npx prisma migrate resolve --rolled-back "nombre-de-la-migracion"

Regla de oro para migraciones: Nunca borres columnas en producción en el mismo deploy que eliminas el código que las usa. Hazlo en dos pasos separados, con al menos 24 horas de diferencia.

Paso 8: Checklist antes de lanzar

[ ] Variables de entorno diferentes en dev y producción
[ ] Base de datos gestionada con backups automáticos
[ ] Usuario de BD con permisos mínimos
[ ] Sentry (o similar) configurado y testeado
[ ] Security headers activos
[ ] Logs estructurados
[ ] Proceso de rollback documentado y probado
[ ] Deploy manual de prueba en un preview environment

Arquitectura mínima recomendada

Para una app SaaS con 0-1000 usuarios:

[Usuarios]
    ↓
[Vercel / Railway]     ← Deploy automático desde GitHub
    ↓
[Sentry]               ← Errores
    ↓
[Neon / Supabase]      ← Base de datos con backups
    ↓
[Cloudflare]           ← CDN + protección DDoS (gratis)

Coste mensual aproximado: $0-30/mes hasta los primeros 500 usuarios activos.

Resumen

El salto de local a producción asusta porque hay mucho que puede salir mal. Pero si sigues estos pasos en orden, reduces los riesgos al mínimo:

Elige plataforma según tu stack (Vercel para Next.js, Railway para full-stack)
Variables de entorno separadas para cada entorno
BD gestionada con backups desde el día 1
Sentry activo antes de lanzar
Proceso de rollback definido y documentado

Si necesitas ayuda con alguno de estos pasos, agenda una llamada.

Referencias

[1] Vercel. (2024). Deployments Overview. https://vercel.com/docs/concepts/deployments/overview

[2] Railway. (2024). Environments. https://docs.railway.app/reference/environments

[3] OWASP. (2024). Configuration and Deployment Management. https://cheatsheetseries.owasp.org/cheatsheets/Configuration_Guide.html