CEREVA CEREVA
Iniciar conversación
Infraestructura 6 min

Infraestructura soberana: construyendo un stack self-hosted moderno

Un análisis técnico sobre cómo combinar infraestructura local, túneles seguros, DNS administrado y servicios autogestionados para crear una base tecnológica escalable.

Linux Docker Cloudflare Self-hosted

La infraestructura como ventaja estratégica

Para muchas empresas pequeñas y medianas, la infraestructura tecnológica suele resolverse de dos formas: contratar servicios SaaS aislados o depender completamente de proveedores cloud. Ambas opciones funcionan, pero también pueden generar costos crecientes, dependencia operativa y poca visibilidad sobre dónde viven los datos.

En CEREVA, partimos de una idea distinta: no todo tiene que vivir en una nube pública para ser moderno. Con una arquitectura bien diseñada, un servidor propio puede convertirse en el núcleo de una operación digital segura, flexible y escalable.

Nuestra infraestructura combina GNU/Linux, Docker, Cloudflare Tunnels, Tailscale, DNS administrado, automatización y servicios autogestionados para operar aplicaciones internas, herramientas de productividad, almacenamiento privado y plataformas empresariales.

Separar dominios para separar responsabilidades

Una de las decisiones más importantes fue dividir la presencia digital en dos capas:

  • Dominio comercial: sitio web, marca, SEO y correo corporativo.
  • Dominio operativo: servicios internos, automatizaciones, plataformas privadas y herramientas técnicas.

Esta separación permite que la identidad pública de la empresa se mantenga limpia, estable y profesional, mientras que la infraestructura operativa puede evolucionar sin afectar el correo, el posicionamiento o la experiencia de clientes externos.

Por ejemplo, el sitio corporativo puede vivir en un dominio principal como cereva.com.mx, mientras que servicios como automatización, nube privada, vaults, sistemas internos o laboratorios pueden vivir en subdominios técnicos bajo otra zona DNS.

Cloudflare como frontera de seguridad

En lugar de exponer puertos directamente al internet público, usamos Cloudflare Tunnels como capa de publicación segura. Esto permite conectar aplicaciones internas con dominios públicos sin abrir el servidor directamente hacia internet.

La arquitectura funciona bajo un principio simple: el servidor no necesita estar expuesto; solo establece una conexión saliente hacia Cloudflare. Desde ahí, Cloudflare se encarga de enrutar el tráfico hacia los servicios correspondientes.

Capas Principales de la Arquitectura

Publicación

Cloudflare Tunnels

Permite exponer aplicaciones web sin abrir puertos directamente en el router o firewall.

Acceso privado

Tailscale

Crea una red mesh segura para administración remota, SSH y acceso interno entre dispositivos autorizados.

Orquestación

Docker + CasaOS

Facilita el despliegue y administración de microservicios desde una capa visual y contenedores aislados.

Resolución local

Pi-hole

Centraliza DNS interno, mejora control de red y permite filtrar tráfico no deseado dentro de la LAN.

Servicios autogestionados con propósito

El objetivo no es instalar herramientas por instalarlas. Cada servicio cumple una función dentro del ecosistema operativo.

Nextcloud permite centralizar archivos y documentación interna bajo control propio.
Vaultwarden resuelve la gestión segura de credenciales.
n8n funciona como motor de automatización para flujos de trabajo.
Aplicaciones internas como sistemas de gestión, APIs y herramientas RAG viven sobre la misma base de infraestructura.

La ventaja real aparece cuando estos servicios dejan de ser piezas aisladas y comienzan a conectarse entre sí.

Un formulario en la web puede detonar un flujo en n8n.
Un archivo puede almacenarse en la nube privada.
Una API interna puede alimentar un dashboard.
Un sistema RAG puede analizar documentación técnica y apoyar decisiones operativas.

Costos controlados y crecimiento gradual

Una arquitectura de este tipo permite comenzar con hardware accesible y crecer por etapas. No es necesario pagar desde el inicio por servicios cloud sobredimensionados si la carga real todavía es baja o moderada.

Un servidor con procesador moderno, SSD para sistema, almacenamiento masivo y memoria suficiente puede operar múltiples servicios empresariales con buen rendimiento si el diseño es correcto.

1 nodo

base operativa inicial

Un solo servidor Linux puede alojar aplicaciones, automatizaciones, almacenamiento privado y herramientas internas antes de escalar a una arquitectura distribuida.

Conforme aumentan los usuarios, los datos o la criticidad del negocio, la infraestructura puede evolucionar:

  1. Separar bases de datos en un nodo dedicado.
  2. Mover respaldos a almacenamiento externo.
  3. Añadir monitoreo y alertas.
  4. Replicar servicios críticos.
  5. Migrar cargas específicas a nube pública cuando tenga sentido económico o técnico.

Seguridad desde el diseño

La soberanía de datos no sirve de mucho si la infraestructura no está protegida. Por eso, el stack debe considerar seguridad desde el inicio:

  • Acceso administrativo solo por VPN o red privada.
  • HTTPS obligatorio para servicios públicos.
  • DNS bien configurado.
  • Políticas de autenticación fuertes.
  • Backups externos.
  • Separación entre servicios públicos, privados e internos.
  • Revisión periódica de actualizaciones y contenedores.

En este modelo, Cloudflare protege la entrada pública, Tailscale protege la administración privada y Docker ayuda a mantener servicios aislados y reproducibles.

Una base para productos futuros

La mayor ventaja de este enfoque es que no solo resuelve necesidades actuales. También crea una plataforma sobre la cual construir nuevos productos.

Sobre esta infraestructura pueden vivir:

  • Sitios corporativos.
  • APIs empresariales.
  • Sistemas de gestión.
  • Dashboards internos.
  • Automatizaciones.
  • Herramientas de inteligencia artificial.
  • Portales para clientes.
  • Ambientes de prueba y laboratorios técnicos.

Esta base convierte la infraestructura en un activo estratégico. Cada nuevo servicio no empieza desde cero, sino que se despliega sobre una capa ya preparada de red, dominios, seguridad y operación.

Conclusión

Una arquitectura self-hosted moderna no compite contra la nube pública; la complementa. La decisión correcta no es “todo local” o “todo cloud”, sino entender qué debe controlarse internamente, qué puede externalizarse y qué necesita escalar bajo demanda.

Para CEREVA, esta estrategia permite operar con bajo costo, alto control y una curva de crecimiento gradual. La infraestructura deja de ser un gasto invisible y se convierte en una plataforma propia para construir, automatizar y escalar soluciones tecnológicas reales.