- Octelium es una plataforma de próxima generación, open source y self-hosted, que integra VPN de acceso remoto, ZTNA, gateway de API/IA y más
- Con self-hosting y single-tenant, ofrece acceso seguro basado en identidad y en capa de aplicación (capa 7) para todos los recursos internos y públicos
- Incluye funciones que cumplen con los requisitos modernos de seguridad, como acceso sin secretos (secret-less), control granular basado en políticas, administración centralizada y auditoría
- Frente a soluciones existentes como Kubernetes, OpenVPN, Tailscale, Cloudflare Access y otras, ofrece ventajas competitivas y puede reemplazarlas
- Adopta un modelo open source y construye su base de negocio con soporte de funciones comerciales y licenciamiento, con enfoque en ofrecer self-hosting con funcionalidad completa
Importancia y visión general del proyecto Octelium
- Octelium es una plataforma unificada de acceso seguro Zero Trust, open source y self-hosted de próxima generación que puede reemplazar soluciones comerciales como Teleport, Cloudflare, Tailscale y Ngrok.
- Frente a soluciones open source o comerciales existentes, su gran ventaja es que puede alojarse completamente por cuenta propia sin sacrificar funcionalidades, evitando costos adicionales y dependencia del proveedor.
Qué es Octelium
- Octelium es una plataforma unificada de gestión de acceso que aplica algoritmos basados en identidad y capa 7
- Es una alternativa a las VPN modernas de acceso remoto (como OpenVPN Access Server, Twingate y Tailscale), y al mismo tiempo cubre funciones como ZTNA, BeyondCorp (Google BeyondCorp, Cloudflare Access, Teleport, etc.), ngrok (proxy inverso), gateway de API/IA, infraestructura PaaS autogestionada, reemplazo de ingress de Kubernetes e infraestructura Homelab
- Para el acceso de usuarios (personas y workloads), organizaciones y aplicaciones, admite tanto un enfoque cliente basado en túneles WireGuard/QUIC como acceso sin cliente desde navegador al estilo BeyondCorp
- Sus pilares son policy-as-code, seguridad detallada basada en contexto e identidad, y autenticación y autorización sin secretos
Casos de uso principales
- VPN moderna de acceso remoto: basada en WireGuard/QUIC, con seguridad dinámica, consciente de identidad y de capa de aplicación
- Configuración unificada de acceso ZTNA/BeyondCorp
- Túneles seguros/proxy inverso self-hosted (alternativa a ngrok y Cloudflare Tunnel)
- PaaS self-hosted (despliegue y escalado de apps en contenedores, hosting público anónimo)
- Gateway de API (alternativa a Kong Gateway y Apigee)
- Gateway de IA (conexión con proveedores de LLM y control basado en identidad)
- Acceso unificado y sin secretos a APIs SaaS
- Infraestructura de gateway para MCP/A2A (estándares de contexto de modelo y comunicación entre agentes)
- Reemplazo avanzado de ingress/load balancer de Kubernetes
- Homelab (administración remota segura y unificada de recursos personales, IoT, nube, etc.)
Características principales
Arquitectura moderna unificada
- Control consciente de identidad y por capa de aplicación para todos los recursos (internos/detrás de NAT y públicos) y todos los usuarios (personas/workloads)
- Ofrece tanto acceso remoto basado en VPN como acceso sin cliente al estilo BeyondCorp
- Funciona sobre Kubernetes, con escalado horizontal y alta disponibilidad integrados
Acceso dinámico sin secretos (secret-less)
- Permite acceso seguro a múltiples apps y bases de datos como HTTP/gRPC API, web apps, SSH, Kubernetes y PostgreSQL/MySQL sin necesidad de gestionar ni compartir claves secretas
- También permite acceso con mTLS sin compartir PKI ni certificados
Control de acceso consciente de contexto, basado en identidad y de capa 7
- Integra un sistema central, modular y componible de políticas (ABAC)
- Soporta lenguajes de políticas como CEL y OPA, con control granular por solicitud
Enrutamiento/configuración dinámicos
- Permite contextos superiores, cuentas y enrutamiento condicional distintos para un mismo recurso según políticas
Autenticación continua y robusta
- Integración con IdP estándar como OpenID Connect y SAML2.0
- Los workloads pueden autenticarse sin secretos mediante tokens OIDC
- Soporta niveles de autenticación NIST, MFA y protección contra phishing (Passkey, Yubikey, etc.)
Visibilidad profunda y auditoría en capa de aplicación
- Integración con OpenTelemetry, con registro en tiempo real de todas las solicitudes y envío a recolectores OTLP externos
SSH serverless y despliegue de apps en contenedores
- Permite acceso SSH incluso a contenedores, dispositivos IoT y hosts sin SSH, sin requerir privilegios root
- Soporta despliegue, escalado y acceso seguro a apps en contenedores al estilo PaaS
Administración centralizada, declarativa y programable
- Se administra de forma declarativa como Kubernetes, y el estado del clúster puede reproducirse con un solo comando o código
- Operación amigable con DevOps/GitOps mediante la CLI
octeliumctl y la API gRPC
Sin cambios de red y solución a problemas crónicos de las VPN
- Los recursos upstream no necesitan saber que Octelium existe, y los servicios pueden operar de forma segura detrás de NAT sin abrir puertos
- Automatiza configuraciones como IP privada dual-stack y DNS privado
Completamente open source, self-hosted y sin vendor lock-in
- Código fuente completo disponible, sin restricciones de funciones en la versión comercial ni vendor lock-in
- Soporta configuraciones escalables desde mini clústeres de un solo nodo hasta grandes entornos en la nube
Licencia y soporte
- El código fuente del cliente usa Apache 2.0 y el clúster AGPLv3
- Hay licencia comercial y soporte enterprise; las contribuciones externas están actualmente limitadas
- Soporte comunitario mediante documentación oficial, Discord, Slack, correo electrónico, Reddit y más
Resumen de puntos clave del FAQ
- Actualmente está en etapa de Public Beta y pasó a open source después de un largo desarrollo interno
- Está liderado por un solo desarrollador (George Badawi) y opera de forma independiente, sin VC ni capital externo
- Puede funcionar como VPN, pero su orientación fundamental es una ZTA basada en proxy y consciente de identidad
- No impone restricciones “poco open source” ni obliga al uso comercial; su objetivo de diseño es ofrecer self-hosting con funcionalidad completa
- Su modelo de negocio deriva de soporte técnico, licencias comerciales y funciones adicionales enterprise (por ejemplo, integración con SIEM, backend de Vault y EDR)
1 comentarios
Comentarios en Hacker News
Para quienes tienen dificultades para entender qué hace Octelium, comparto el lugar donde encontré la explicación más clara: el enlace a Cómo funciona Octelium - documentación oficial es el más fácil de comprender. En lugar de generar confusión listando todas las funciones posibles de Octelium, resulta atractivo que empiece por los conceptos clave y los explique de forma gradual. Sus funciones principales son una puerta de enlace tipo VPN capaz de tomar decisiones de seguridad granulares basadas en contenido al entender protocolos avanzados, y una capa de configuración de clúster construida sobre Kubernetes. La combinación de ambas forma algo parecido a una "nube personal". Ofrece muchísimas capacidades, como una gran plataforma de nube, pero cuesta decidir por dónde empezar a usarlo. Parece un sistema genial con potencial para muchos usos: homelabs personales, pequeñas empresas que buscan reducir costos de nube, PaaS personalizados, etc.
Tailscale me parece satisfactorio, pero siento la necesidad de que existan competidores. Se espera una IPO, y cuando llegue a esa etapa, si no hay competencia, veo muy probable que los precios suban con fuerza.
Se puede resumir como una especie de tejido programable de túneles de red.
Desde mi punto de vista, hay varios problemas y por eso es inevitable que los usuarios lo miren con escepticismo. La falta de historial de desarrollo, un primer commit enorme y de origen desconocido, poca información pública, una empresa que no parece realmente existir, marketing que afirma resolverlo todo y seguridad sin pruebas: todo eso reduce la confianza. En esta situación, hace falta más información para saber si realmente es tecnología propia o si está construido sobre tecnología existente suficientemente confiable. Si quieren lanzarlo como negocio, necesitan establecer credibilidad. En cambio, si es un proyecto personal, aconsejaría que aparentar ser un negocio puede verse más bien como algo falso, estafa o señal de alerta. Me cuesta ser positivo ante la idea de que un desarrollador solitario de repente publique un producto para competir con empresas grandes. Es importante destacar claramente la seguridad. Si es difícil explicar en una sola frase cuál es el propósito del software, se viene una batalla complicada. La respuesta no es enumerar más funciones. Más bien transmite una sensación de "instálame a la fuerza", lo que termina quitando las ganas de probarlo. Señalo que esto probablemente obstaculice el éxito del proyecto.
Es una excelente retroalimentación. Entiendo la validez de la crítica, dado que Octelium fue diseñado deliberadamente para cumplir muchas funciones a la vez. Octelium es una plataforma unificada y de propósito general de acceso zero-trust que puede usarse en múltiples casos entre humano-carga de trabajo y carga de trabajo-carga de trabajo (la documentación tiene ejemplos detallados de varios casos). Por eso puede resultar confuso para alguien nuevo. El primer commit apareció de golpe porque, en realidad, lo vengo desarrollando desde principios de 2020, pero al decidir publicar el código, empecé un repositorio público limpio y sin commits iniciales por el riesgo de filtrar información privada. En los últimos 5 años hice casi 9,000 commits manuales, y al principio era un VPN remoto simple con WireGuard, pero desde entonces cambió por completo hasta llegar a la arquitectura, funciones y complejidad actuales.
Hace falta ser generosos con los desarrolladores de código abierto. Nadie conoce el contexto ni la motivación del OP; podría estar haciéndolo por diversión. No necesita justificarse. Esto es open source y software libre. Sobre la crítica de que no se puede describir en una sola frase: se puede explicar de forma relativamente simple, como tailscale, cloudflare access o ngrok. Si no necesitas productos de ese tipo, entonces tampoco necesitas este.
Revisé Octelium hace poco y parece que requiere un clúster de Kubernetes para instalarse. Si eso es cierto, la barrera de entrada es demasiado alta. Queremos conectar nodos a una red superpuesta, no agregar dependencias de otra infraestructura como k8s. Me resulta extraño que se elija eso cuando lo deseable sería tener dependencias internas mínimas o nulas. Si el objetivo es necesitar SDN sobre un clúster, entonces tal vez ese sea el público objetivo, pero me pregunto si es solo eso. Espero que la integración con k8s sea opcional y no un requisito indispensable ni la única forma de despliegue. Si alguien tiene material sobre cómo usar Octelium sin k8s, me gustaría verlo.
octeliumctl applytodos los servicios se despliegan, administran, escalan y eliminan automáticamente. No hace falta trabajo manual como abrir puertos en el firewall. Igual que Kubernetes administra contenedores, Octelium coordina automáticamente servicios, proxies, etc. Tampoco hay que ocuparse de complejidades como la cantidad de nodos o el networking del CRI. El clúster abarca todos los nodos y permite gestionarlos de forma declarativa y programática. Para operar Octelium no hace falta un conocimiento profundo de Kubernetes; salvo tareas específicas como escalar el propio clúster de k8s o configurar certificados TLS, basta con manejar Octelium. Recomiendo consultar la documentación oficial para más detalles.Me genera una desconfianza enorme e inmediata que suelte demasiadas palabras de moda. Incluso viendo la página de GitHub, no queda claro qué hace concretamente el producto.
En general ya hay demasiados productos similares: Tinc, Hamachi, ZeroTier, Nebula, Tailscale, Netbird, etc. Cada uno tiene sus pros y sus contras, pero en la práctica creo que las diferencias reales son mínimas. Lo que personalmente de verdad quiero es un "lighthouse" zero-trust. En Zerotier y Tailscale, el servicio tiene autorización para agregar nodos a mi cuenta o red. Lo que quiero es self-hosting completo y una estructura en la que el lighthouse no forme parte de la red, sino que solo monitoree los nodos. Tendré que buscar más información al respecto.
Después de leer la documentación, creo que mucha gente está pasando por alto el verdadero valor de Octelium. Si realmente funciona como dice la documentación, podría ser una joya aún no descubierta. Lo que las empresas quieren es salir del modelo tradicional de seguridad basada en perímetro y acercarse a la idea planteada por Google überProxy/BeyondCorp (y que luego fue diluida por toda clase de buzzwords): una separación limpia entre sistemas de producción, la red interna corporativa e internet externa; una UX lo más transparente posible para el personal interno; una gestión clara de permisos sobre el tráfico que cruza esos límites; y una autenticación de identidad sólida para todos los clientes. Fuera de Google hay muchas limitaciones por la diversidad de protocolos. Los proxies conscientes del protocolo solo permiten decisiones y logging de grano grueso, pero cuando incluso soportan inferencia de tipos, se vuelve posible un control de permisos mucho más fino por solicitud (es decir, exponer al motor de políticas las condiciones de cada solicitud). La documentación es extensa y el marketing no es muy pulido, pero el problema en sí es tan complejo que nadie lo ha resuelto por completo. Teleport fue de los primeros en avanzar tanto en OSS como en comercialización, y StrongDM también está haciendo intentos interesantes. Ojalá Hashicorp invirtiera más en esto (opinión personal).
Octelium puede reemplazar a los productos mencionados arriba, pero su objetivo y su forma de uso son más amplios y claramente orientados a zero-trust. Va mucho más allá de una simple herramienta de VPN/acceso remoto. De verdad me gustaría que leyeran la documentación para entender su intención, arquitectura y capacidades. Hoy en día todos los productos se anuncian como "zero-trust", pero en realidad son pocos los que cumplen con lo que NIST define como una ZTA real (es decir, proxies conscientes de L7, policy decision point, control de acceso granular por solicitud basado en código de políticas, identidad centralizada, integración de información de herramientas externas de SIEM/SSO/Threat intelligence, etc.). De hecho, los productos comerciales que podrían clasificarse como ZTA "real" incluyen Cloudflare Access, Teleport, Google BeyondCorp, StrongDM, Zscaler, entre otros. Más bien, la tendencia es que las empresas abusen del término y diluyan el concepto de "zero-trust" real.
Te recomiendo revisar el modo cathedral de sanctum. Es completamente self-hosted, y el nodo solo cumple una función de discovery. Una vez que se establece el túnel, el nodo cathedral ya no interviene, salvo en casos excepcionales como la distribución de black keys o cuando un peer está detrás de NAT. También está reliquary. Yo los opero directamente. sanctum, reliquary
Puedes ver una lista de más proyectos relacionados en awesome-tunneling
Entiendo que insertar la palabra clave "AI" es por motivos de SEO. Es como poner "Reddit" en el título de un artículo. Aunque el contenido sea bueno, este tipo de enfoque no deja una buena impresión. Además, los diagramas de API gateway y AI gateway son casi iguales. blog de tailscale: AI-normal
Estoy buscando activamente una alternativa open source a Tailscale. Pero el README es demasiado largo, así que estaría bien que mostrara de forma condensada solo una visión general del proyecto y enlaces a la documentación.
La mayor ventaja de Tailscale es la facilidad de conexión P2P. Octelium, en cambio, parece usar una estructura de router centralizado; me gustaría saber si eso es correcto.
Octelium no es un VPN P2P, sino una arquitectura zero-trust. Claro que también puede funcionar como un VPN de acceso remoto basado en WireGuard/QUIC, pero estructuralmente está mucho más cerca de Cloudflare Access o Teleport. El control de acceso basado en L7, el acceso sin secretos (inyectando distintas claves/tokens/API keys sin tener que desplegarlas directamente), la configuración y el enrutamiento dinámicos, y la visibilidad y auditoría en tiempo real basadas en OpenTelemetry hacen que sea esencialmente distinto de un VPN P2P. En una arquitectura seria de ZTNA/BeyondCorp (dejando fuera el service mesh), implementar esto como un VPN P2P tiene limitaciones fundamentales. Para obtener control de acceso y visibilidad por solicitud, necesariamente hace falta un proxy consciente de L7.
Como referencia, incluso Tailscale a veces hace pasar los paquetes por un router centralizado. Explicación de los tipos de conexión de Tailscale
No entiendo por qué la instalación del clúster k3s está integrada en la app. Me parecería más claro poder añadirlo fácilmente a infraestructura existente o exponer servicios mediante un CRD simple. El concepto mismo de un Cloudflare Access/Teleport open source es genial, pero como la mayoría termina siendo personalización sobre k8s, me interesaría más si se enfocara en funciones centradas en acceso.
octeliumctl applyo la API gRPC, y se puede olvidar del resto de la administración. Hubo una época en que los recursos eran CRD, pero había demasiados recursos —usuarios, sesiones, servicios, namespaces (algunos separados de los namespaces de k8s), políticas, dispositivos, credenciales, etc.— y el volumen de datos volvía inestable el backend de etcd. Al final se adoptó un backend separado con Postgres.Ya hay demasiados proyectos parecidos publicados.
Me pregunto si esto es un reemplazo para la gestión de acceso a escala de grandes empresas (botnet corporativa). Si yo fuera una gran empresa, querría software empresarial y un paquete de soporte por estabilidad; no estoy seguro de que un proyecto open source de un solo desarrollador pueda resolver ese problema.