Stack Vexakon · Hetzner + Coolify + N8N + PostgreSQL + Qdrant

Este artículo describe en detalle el stack que Vexakon usa para todos los proyectos productivos. La decisión de no usar plataformas no-code ni hyperscalers de EE.UU. es deliberada y tiene tres motores: cumplimiento RGPD sin teatro, control total de costes, y entrega del proyecto al cliente sin lock-in.

Mapa general

[usuario]
   │
   ▼
[Widget chat web]          ◄──►  [N8N queue mode 2.x]  ◄──►  [Qdrant 1.12 + Cohere rerank]
   │                                    │
   ▼                                    ▼
[Retell AI · voz]                  [GPT-4o · OpenAI]
   │                                    │
   └─────────────►  [PostgreSQL 16 · Redis 7 · Hetzner Falkenstein DC14]

Cada caja es soberana en el sentido fuerte: ningún elemento del flujo de datos está atado a un SaaS opaco que pueda cambiar precios, condiciones o residencia geográfica sin notificación. Las únicas dependencias externas reales son los modelos de lenguaje (OpenAI, Anthropic), el TTS/STT (ElevenLabs, Deepgram) y la orquestación de voz (Retell). Los DPAs con todos ellos son verificables y se firman a nombre del cliente, no de Vexakon.

Capa de infraestructura

Servidor: Hetzner Cloud CX33 en Falkenstein DC14

• 4 vCPU AMD, 8 GB RAM, 80 GB SSD NVMe.
• Coste: 6,80 €/mes con backups automáticos (1,80 €/mes adicionales).
• Ubicación: Falkenstein, Alemania. Garantía contractual de residencia UE.
• IPv4 pública estática + IPv6 /64.
• Alternativa para crecimiento: CX42 (4 vCPU, 16 GB RAM) por 17,40 €/mes.

Razones para no usar AWS / GCP / Azure:

1. Coste: el equivalente t3.medium en AWS Frankfurt ronda los 30 €/mes; sumando EBS, snapshots y data transfer, la factura mensual sube a 50-80 €. Hetzner cuesta 8,60 €/mes con backup incluido.
2. Residencia regulatoria: AWS / GCP / Azure obligan a acuerdos SCC + análisis de transferencia internacional incluso para regiones "europeas" porque la matriz tiene domicilio en EE.UU. (FISA 702). Hetzner es alemana 100 %; ese análisis no aplica.
3. Operación: snapshots, redimensiones y rescate por API. Sin interfaces inflables, sin opciones que cobran por click.

PaaS: Coolify v4 self-hosted

Coolify es un PaaS self-hosted que sustituye a Heroku, Vercel y Railway. Despliega aplicaciones Docker desde Git con CI/CD, dominios SSL automáticos via Let's Encrypt, y observabilidad básica.

Decisión arquitectónica: cada cliente tiene su propio "Project" en Coolify (cliente-[slug]) con sus servicios aislados (web, N8N, RAG, monitoring). Los servicios compartidos (PostgreSQL primario, Redis, Qdrant) viven en un Project común con permisos por base de datos.

CDN/DNS/SSL: Cloudflare en Full Strict + WAF

• DNS gestionado en Cloudflare Free.
• TLS originado en Cloudflare con certificado válido hasta el origen (Full Strict).
• WAF gratuito con reglas OWASP Top 10.
• Páginas estáticas (vexakon.com) vía Cloudflare Workers + adapter @opennextjs/cloudflare para Next.js 16.

Coste neto: 0 €/mes en plan Free, sin límite duro de bandwidth para tráfico legítimo.

Capa de datos

PostgreSQL 16 con encrypted volumes

Una base de datos por cliente: cli_[slug]_prod. Backups diarios al Storage Box BX11 cifrados con age. Restore test mensual obligatorio (lo audita el subagente security-auditor).

Schemas principales por cliente:

• consents (privacy-first: email_hash SHA-256, ip_truncated con últimos 2 octetos a 0).
• conversations (logs de IA con disclosure timestamp).
• tenants (información del cliente y configuración).

Redis 7 con appendonly y allkeys-lru

Cache, rate limiting y queue store de N8N. La política allkeys-lru evita que la cola de N8N consuma toda la memoria si llega un pico inesperado.

Qdrant 1.12 con una collection por cliente

[slug]_kb. Embeddings con text-embedding-3-small de OpenAI (1536 dims). Re-ranking con Cohere rerank-v3.5 para precisión boost.

Tres parámetros que cambiamos por defecto:

• hnsw_config.m: 16 (default) → 32 para mejor recall en boutique con < 100k vectores.
• optimizers_config.indexing_threshold: 20 000 (default) → 5 000 para indexar antes en colecciones pequeñas.
• quantization_config: scalar int8 cuando la collection supera 200k vectores (reducción 4× memoria con < 1 % pérdida de precisión).

Capa de orquestación

N8N Community 2.x en queue mode

worker_main ejecuta workflows largos; el proceso principal solo recibe webhooks y dispara. Esto evita que un workflow de 30 s bloquee la recepción de un webhook urgente.

Estructura por cliente:

• Workflow de ingesta (webhook → validación → routing).
• Workflow de RAG (consulta Qdrant + rerank Cohere + LLM + cita).
• Workflow de notificación (email transaccional via Resend, alertas Telegram).
• Workflow de mantenimiento (backups, cleanup, retención RGPD).

Versiones: 2.0+ obligatorio. NUNCA 0.211.0 a 1.121.0 (vulnerabilidad crítica).

Retell AI para voz

Retell es la elección por defecto para asistentes telefónicos. Vapi se reserva para casos hyper-custom donde necesitamos control low-level sobre el VAD (voice activity detection) o transferencias en caliente complejas.

Capa de modelos

Dimensionamiento y objetivos de rendimiento

El entorno de referencia (Hetzner CX33: 4 vCPU AMD, 8 GB RAM) está dimensionado para los siguientes objetivos de rendimiento. Son cifras de diseño y de pruebas del stack en banco, no medias de carga de clientes en producción; publicaremos métricas verificadas cuando haya volumen real que medir.

Las cifras de latencia y throughput son medidas internas con pgbench adaptado y scripts de carga sintética. Las cifras de uptime salen de Uptime Kuma con monitor cada 60 segundos. Las cifras de MTTR vienen del tracker de incidentes en Notion. Si el cliente quiere validar in situ, Vexakon entrega el dashboard de Metabase con vistas en tiempo real.

Backup, restore y plan de recuperación

La política de backups Vexakon tiene tres capas de protección, cada una con frecuencia y destino diferentes para cubrir distintos escenarios de fallo. Esto vale para cualquier cliente nuevo desde el día 1 sin coste adicional al SOW.

Test de restore mensual ejecutado por el subagente security-auditor. El test extrae el backup más reciente, lo restaura en un sandbox, ejecuta una query smoke contra cada base y reporta tiempo total. Los logs del test se encadenan al audit log SHA-256 del cliente para evidencia regulatoria.

Procedimiento de recuperación ante desastre documentado en SOP del cliente. Tres escenarios típicos:

1. Corrupción de tabla Postgres: restore selectivo de la tabla afectada en menos de 30 minutos. Resto del sistema continúa.
2. Compromiso de servidor: rotación inmediata de credenciales, snapshot de servidor para forensia, despliegue limpio en CX33 nuevo desde Coolify, restore de backups. RTO objetivo 4 horas.
3. Pérdida total de Hetzner Falkenstein (escenario catastrófico): activación del plan de continuidad con replicación remota. RTO objetivo 24 horas.

Estas cifras se documentan en el SOW del cliente y son contractualmente vinculantes en el SLA.

Seguridad en capas

La seguridad del stack se construye en capas independientes que se refuerzan mutuamente. Si una capa falla, las otras contienen el incidente. Las cinco capas activas en cada cluster Vexakon:

1. Cloudflare delante: WAF gratuito con reglas OWASP Top 10, rate limiting por IP, bot management. Filtra el 90 % del tráfico malicioso antes de tocar el servidor.
2. Firewall Hetzner: a nivel de cuenta, bloqueando puertos no autorizados desde la red pública.
3. fail2ban en el host: ban de IPs con intentos de SSH fallidos, configuración Mozilla Modern.
4. SSH key-only sin password: autenticación con clave Ed25519, root login deshabilitado.
5. Secretos vía 1Password con op run: credenciales nunca tocan el filesystem del servidor; se inyectan en runtime y se eliminan al terminar el proceso.

A esto se añade en aplicación: cifrado TLS 1.3 en tránsito, cifrado de columnas sensibles con pgcrypto, control de accesos por rol en Postgres, auditoría de cada acceso administrativo.

Observabilidad continua

Tres herramientas en producción monitorizan el sistema 24/7. Ninguna requiere licencia ni cuota mensual adicional al stack base.

• Uptime Kuma (auto-hosteado en CX33): monitoriza HTTP de las 17 rutas principales con frecuencia 60 segundos. Alertas vía Telegram al bot vexakon_ops_bot con rate limit 1 mensaje/5 segundos para evitar avalanchas.
• N8N audit instance: workflow propio que ejecuta diariamente n8n_audit_instance de la API y reporta vulnerabilidades, workflows obsoletos y cambios de configuración no aprobados.
• Logs estructurados centralizados: cada servicio escribe en formato JSON a stdout, recolectados por Coolify con retención 30 días y rotación automática.

Para clientes que requieren observabilidad reforzada (sectores regulados), Vexakon despliega adicionalmente un Loki + Grafana en el mismo cluster, sin que pase el coste mensual de los 25 €/mes que cobraría un servicio externo equivalente.

Comparativa con alternativas

Tres alternativas que un comprador exigente compararía antes de firmar con Vexakon. Comparativa dimensionada para un uso boutique típico (1-3 clientes, 5-15 workflows N8N, 50k vectores Qdrant).

Los precios incluyen lo equivalente a un cluster productivo con disponibilidad básica. Para auto-hospedar N8N en Heroku o Vercel hace falta una capa de servicios añadidos cuyo precio sube por encima de los 200 €/mes.

Capa de operación

• Notas y SOPs: Notion Plus.
• Secretos: 1Password Business + op run para inyectar en runtime.
• Facturación: Quipu Autónomo (Verifactu compliant).
• CRM: Attio Growth.
• Prospección: Apollo.io Basic.
• Pagos: Stripe.
• Firma: Signaturit.
• Alertas: Telegram bot vexakon_ops_bot con rate limit interno 1 mensaje/5s.

Coste real al mes (mayo 2026)

Las APIs externas pagadas (OpenAI, Deepgram, ElevenLabs, Retell) escalan con el uso del cliente y se facturan en su nombre cuando es el cliente quien firma el contrato directo, o se incluyen en la cuota mensual cuando es Vexakon quien intermedia.

Plan de continuidad

Vexakon entrega al cliente:

• Repositorio Git con todo el código y los workflows.
• Snapshots cifrados de las bases de datos.
• Documentación operativa (CLAUDE.md, SOPs, decisions log).
• Credenciales rotadas y migradas al 1Password del cliente.
• DPAs firmados con cada subprocesador a nombre del cliente.

Cualquier ingeniero con experiencia en el stack puede recoger el proyecto sin rehacer trabajo. Es la política de "no lock-in" que se documenta en cada SOW y se verifica en el go-live.

Repositorio de referencia público

Vexakon mantiene un repositorio OSS de referencia con un docker-compose mínimo del stack: https://github.com/vexakon/stack-example. Sirve para que cualquiera (cliente prospecto, ingeniero curioso, auditor) pueda levantar localmente la arquitectura en menos de cinco minutos y validar las afirmaciones técnicas de este artículo. Licencia MIT. El repositorio incluye:

• docker-compose.yml con N8N queue mode + Postgres 16 + Redis 7 + Qdrant 1.12.
• coolify-config/ con plantillas de configuración Coolify.
• n8n-workflows/ con tres workflows de ejemplo (cualificación lead, RAG simple, alerta Telegram).
• docs/deployment.md con paso a paso para un VPS Hetzner CX33.
• docs/monitoring.md con configuración Uptime Kuma + Loki opcional.
• docs/troubleshooting.md con incidentes documentados y resoluciones.

La transparencia del repo es deliberada: en sectores donde la confianza es el activo central (despachos, clínicas, finanzas), enseñar la cocina vale más que firmar diez NDAs.

Lecciones de migración entre clientes

Vexakon ha migrado el stack completo entre dos clusters más de quince veces durante 2025-2026, principalmente por escalado vertical (de CX23 a CX33) y por one-shot de pruebas en staging. Las cinco lecciones operativas que han ahorrado tiempo y errores:

1. Snapshot Hetzner antes de cualquier apt upgrade. Coste cero, ahorra 4 horas de rollback ante kernel panic post-upgrade.
2. Backup explícito de docker volume antes de coolify update. Coolify no toca volúmenes pero un docker prune accidental sí.
3. Credenciales Postgres rotadas en 1Password tras pg_dump para migración: evita que la contraseña antigua quede expuesta en logs intermedios.
4. Test de restore en sandbox con datos sintéticos antes de reemplazar el primario. Diez minutos extra de prueba ahorran días de pánico.
5. Documentar cada decisión de configuración en el DECISIONS_LOG del cliente, encadenado al audit log SHA-256. La memoria humana falla; el log no.

Estas cinco prácticas son parte del playbook estándar Vexakon. Páginas por vertical y localidad: clínicas dentales en Valencia, despachos jurídicos en Alicante y hoteles boutique en Dénia.

Preguntas frecuentes

(Generadas como FAQPage schema desde el frontmatter de este artículo.)