- Octelium é uma plataforma open source de próxima geração, self-hosted, com suporte integrado a VPN de acesso remoto, ZTNA, gateway de API/IA e mais
- Com self-hosting e tenant único, oferece acesso seguro baseado em identidade e na camada de aplicação (camada 7) para todos os recursos internos e públicos
- Inclui recursos que atendem às exigências modernas de segurança, como acesso sem segredos (
secret-less), controle baseado em políticas granulares, gerenciamento centralizado e auditoria
- Oferece vantagens competitivas e pode substituir várias soluções comerciais/open source existentes, como Kubernetes, OpenVPN, Tailscale e Cloudflare Access
- Adota um modelo open source e estabelece sua base de negócios com suporte a recursos comerciais e licenciamento, com foco em oferecer self-hosting com funcionalidade completa
Importância e visão geral do projeto Octelium
- O Octelium é uma plataforma unificada de acesso seguro Zero Trust, open source e self-hosted de próxima geração, capaz de substituir soluções comerciais como Teleport, Cloudflare, Tailscale e Ngrok.
- Em comparação com soluções open source/comerciais existentes, sua grande vantagem é permitir hospedar tudo por conta própria sem comprometer funcionalidades, ficando livre de custos adicionais e de dependência de fornecedor.
O que é o Octelium
- Octelium é uma plataforma unificada de gerenciamento de acesso baseada em identidade e em algoritmos de camada 7
- É uma alternativa a VPNs modernas de acesso remoto (como OpenVPN Access Server, Twingate e Tailscale), ao mesmo tempo em que atende a vários papéis, como ZTNA, BeyondCorp (Google BeyondCorp, Cloudflare Access, Teleport etc.), ngrok (proxy reverso), gateway de API/IA, infraestrutura PaaS própria, substituto para ingress do Kubernetes e infraestrutura de Homelab
- Para acesso de usuários (pessoas e workloads), organizações e aplicações, suporta tanto o modo cliente baseado em túneis WireGuard/QUIC quanto o acesso via navegador sem cliente no modelo BeyondCorp
- Seu núcleo está em policy-as-code, segurança detalhada baseada em contexto e identidade, e autenticação e autorização sem segredos
Principais casos de uso
- VPN moderna de acesso remoto: baseada em WireGuard/QUIC, com segurança dinâmica, orientada por identidade e em camada de aplicação
- Configuração unificada de acesso ZTNA/BeyondCorp
- Túnel seguro/proxy reverso self-hosted (alternativa a ngrok e Cloudflare Tunnel)
- PaaS self-hosted (deploy e escalonamento de apps em contêineres e hospedagem pública anônima)
- Gateway de API (alternativa a Kong Gateway e Apigee)
- Gateway de IA (conexão com provedores de LLM e controle baseado em identidade)
- Acesso unificado a APIs SaaS sem segredos
- Infraestrutura de gateway para MCP/A2A (padrões de contexto de modelo e comunicação entre agentes)
- Substituto avançado para ingress/load balancer do Kubernetes
- Homelab (gerenciamento remoto seguro e unificado de recursos pessoais, IoT, cloud etc.)
Principais recursos
Arquitetura moderna e unificada
- Controle orientado por identidade e na camada de aplicação para todos os recursos (internos/atrás de NAT e públicos) e todos os usuários (pessoas/workloads)
- Oferece tanto acesso remoto baseado em VPN quanto acesso sem cliente no modelo BeyondCorp
- Executa sobre Kubernetes, com escalabilidade horizontal e alta disponibilidade embutidas
Acesso dinâmico sem segredos (secret-less)
- Suporta acesso seguro a vários apps/BDs, como APIs HTTP/gRPC, web apps, SSH, Kubernetes e PostgreSQL/MySQL, sem precisar gerenciar ou compartilhar chaves secretas
- Também permite acesso com mTLS sem compartilhar PKI/certificados
Controle de acesso com consciência de contexto, baseado em identidade e camada 7
- Sistema de políticas (ABAC) central, modular e componível embutido
- Suporte a linguagens de política como CEL e OPA, permitindo controle refinado por requisição
Roteamento/configuração dinâmicos
- Permite roteamento condicional com diferentes contextos superiores, contas e condições para o mesmo recurso, com base em políticas
Autenticação contínua e forte
- Integração com IdPs padrão, como OpenID Connect e SAML2.0
- Workloads podem se autenticar sem segredos com tokens OIDC
- Suporte a níveis de garantia NIST, MFA e proteção contra phishing (como Passkey e Yubikey)
Visibilidade profunda e auditoria na camada de aplicação
- Integração com OpenTelemetry, com registro em tempo real de todas as requisições e envio para coletores OTLP externos
SSH serverless e deploy de apps em contêineres
- Permite acesso SSH até mesmo a contêineres, dispositivos IoT e hosts sem SSH, sem exigir privilégios de root
- Suporta deploy, escalonamento e acesso seguro a apps em contêineres, de forma semelhante a um PaaS
Gerenciamento centralizado, declarativo e programável
- Gerenciamento declarativo, como no Kubernetes, permitindo reproduzir o estado do cluster com um único comando ou via código
- Operação amigável para DevOps/GitOps via CLI
octeliumctl e API gRPC
Sem necessidade de mudanças na rede e com solução para problemas clássicos de VPN
- Os recursos upstream não precisam sequer saber que o Octelium existe, e é possível operar serviços com segurança atrás de NAT sem abrir portas
- Automação de configurações como IP privado dual-stack exclusivo e DNS privado
Totalmente open source, self-hosted e sem lock-in de fornecedor
- Código-fonte completo disponível, sem limitações artificiais de recursos na versão comercial nem vendor lock-in
- Suporta configurações escaláveis, de mini clusters com nó único até grandes ambientes em cloud
Licença e suporte
- O código do cliente é Apache 2.0, e o cluster é AGPLv3
- Há licença comercial e suporte enterprise, e as contribuições externas são atualmente limitadas
- Suporte da comunidade por documentação oficial, Discord, Slack, e-mail, Reddit etc.
Resumo dos principais pontos do FAQ
- Atualmente está em Public Beta, após um longo período de desenvolvimento interno antes da abertura do código
- É liderado por um único desenvolvedor (George Badawi), operando de forma independente, sem VC ou capital externo
- Pode atuar como VPN, mas sua direção principal é uma arquitetura ZTA baseada em proxy com reconhecimento de identidade
- Não há restrições "que não parecem open source" nem imposição comercial; o objetivo do design é oferecer self-hosting com funcionalidade completa
- O modelo de negócios deriva de suporte técnico, licenciamento comercial e recursos adicionais enterprise (por exemplo, integração com SIEM, backend Vault e EDR)
1 comentários
Comentários do Hacker News
Para quem teve dificuldade de entender o que o Octelium faz, compartilho o lugar onde encontrei a explicação mais clara: o link Como o Octelium funciona - documentação oficial é o mais fácil de entender. Em vez de confundir listando todos os recursos possíveis do Octelium, ele começa pelos conceitos centrais e explica de forma gradual, o que é bem atraente. Os principais elementos são um gateway semelhante a uma VPN que entende protocolos avançados e consegue tomar decisões de segurança granulares com base no conteúdo, além de uma camada de configuração de cluster construída sobre Kubernetes. A combinação desses dois componentes forma algo como uma "nuvem pessoal". Ele oferece muitos recursos, como uma grande plataforma de nuvem, mas é difícil decidir por onde começar a usar. Parece um sistema muito interessante, com potencial de uso em homelabs pessoais, pequenas empresas tentando reduzir custos de nuvem, PaaS customizado e muito mais.
O TailScale me atende bem, mas sinto falta da existência de concorrentes. Um IPO é esperado, e quando entrar nessa fase, se não houver concorrência, acho bem possível que os preços subam rapidamente.
Dá para resumir como uma malha programável de túneis de rede.
Na minha visão, há alguns problemas, e por isso os usuários inevitavelmente ficam céticos. A ausência de histórico de desenvolvimento, um primeiro commit enorme e inexplicável, pouca informação pública, a impressão de que não parece ser uma empresa real, marketing dizendo resolver tudo e segurança sem comprovação — tudo isso reduz a confiança. Nessa situação, seriam necessárias mais informações para saber se é tecnologia realmente própria ou se foi construída sobre tecnologias existentes suficientemente confiáveis. Para lançar isso como negócio, é preciso transmitir credibilidade. Por outro lado, se for um projeto pessoal, fingir ser um negócio pode acabar parecendo falso/golpe/sinal de alerta. É difícil ser positivo sobre um desenvolvedor solo de repente lançar um produto para competir com grandes empresas. É importante destacar a segurança de forma clara. Se é difícil explicar o propósito do software até em uma frase, isso já indica uma batalha complicada. Listar ainda mais recursos não é a solução. Pelo contrário, passa uma sensação de "instala logo sem questionar", o que reduz a vontade de testar. Foi apontado que isso pode acabar prejudicando o sucesso do projeto.
É um ótimo feedback. Entendo a legitimidade da crítica, já que o Octelium foi deliberadamente projetado para fazer várias coisas ao mesmo tempo. O Octelium é uma plataforma unificada/genérica de acesso zero trust que pode ser usada em vários casos entre humano-carga de trabalho e carga de trabalho-carga de trabalho (há vários exemplos detalhados na documentação). Por isso, pode ser confuso do ponto de vista de um usuário iniciante. O motivo de o primeiro commit ter aparecido de repente é que, embora o desenvolvimento venha desde o início de 2020, quando decidi abrir o código optei por começar com um repositório público limpo, sem commits antigos, por risco de vazamento de informações pessoais. Nos últimos 5 anos, fiz quase 9.000 commits manualmente, e no começo era apenas uma VPN WireGuard simples para acesso remoto, mas desde então mudou completamente para a arquitetura, os recursos e a complexidade atuais.
É preciso ter mais generosidade com desenvolvedores open source. Ninguém conhece o contexto nem a motivação do OP; pode até ser só por diversão. Não precisa se justificar. Isso é open source e software livre. Sobre a crítica de não conseguir explicar em uma frase para o usuário, dá para descrever de forma relativamente simples, como tailscale, cloudflare access ou ngrok. Se você não precisa desse tipo de produto, então também não precisa deste.
Olhei o Octelium recentemente, e parece que um cluster Kubernetes é obrigatório na instalação. Se isso for verdade, a barreira de entrada é alta demais. Queremos conectar nós a uma rede overlay, não adicionar dependências de outra infraestrutura como k8s. É estranho fazer essa escolha, especialmente porque a expectativa seria ter o mínimo possível de dependências internas de serviço, ou nenhuma. Se a SDN precisa existir sobre um cluster, talvez esse seja o público-alvo, mas fico curioso se é só isso. Espero que a integração com k8s seja opcional, e não um pré-requisito obrigatório ou a única forma de implantação. Se alguém tiver material sobre usar o Octelium sem k8s, agradeço.
octeliumctl applye todos os serviços são implantados, gerenciados, escalados e removidos automaticamente. Não é necessário trabalho manual como abrir portas de firewall. Assim como o Kubernetes gerencia containers, o Octelium orquestra automaticamente serviços, proxies etc. da mesma forma. Também não é preciso lidar com gestão complexa como quantidade de nós ou rede CRI. O cluster cobre todos os nós e pode ser gerenciado de forma declarativa/programável. Para operar o Octelium, não é necessário conhecimento profundo de Kubernetes; exceto por tarefas específicas como escalar o próprio cluster k8s ou configurar certificados TLS, basta lidar com o Octelium em si. Para mais detalhes, recomendo a documentação oficial.O excesso de buzzwords me gera imediatamente uma grande desconfiança. Mesmo olhando a página do GitHub, ainda não entendo exatamente o que o produto faz.
No geral, já existem muitos produtos parecidos, como Tinc, Hamachi, ZeroTier, Nebula, Tailscale, Netbird etc. Cada um tem seus pontos fortes e fracos, mas na prática acho que a diferenciação real entre eles é pequena. O recurso que eu realmente queria, pessoalmente, é um "farol" zero trust. ZeroTier e Tailscale dão ao serviço permissão para adicionar nós à minha conta/rede. O que eu quero é self-hosting completo e uma arquitetura em que o lighthouse não faça parte da rede, servindo apenas para observar os nós. Vou procurar mais informações sobre isso.
Lendo a documentação, parece que muita gente está deixando passar o valor real do Octelium. Se ele realmente funcionar como a documentação descreve, pode ser uma joia ainda não descoberta. O que as empresas querem é sair da segurança tradicional baseada em perímetro e chegar ao conceito apresentado pelo Google überProxy/BeyondCorp (e diluído por várias buzzwords): uma separação limpa entre sistemas de produção, ambiente interno corporativo e internet externa, uma UX o mais transparente possível para os funcionários, gestão clara das permissões do tráfego que atravessa os perímetros e autenticação forte de identidade para todos os clientes. Fora do Google, há muitas limitações por causa da diversidade de protocolos. Proxies conscientes de protocolo conseguem apenas decisões e logs mais grosseiros, mas quando também suportam inferência de tipos, fica possível um controle de permissão muito mais refinado por requisição (ou seja, todas as condições de cada requisição ficam expostas ao policy engine). A documentação é longa e o marketing não é muito polido, mas esse problema em si é tão complexo que ninguém conseguiu resolvê-lo perfeitamente. O Teleport foi um dos primeiros a avançar nisso com OSS e comercialização, e o StrongDM também está fazendo tentativas interessantes. Também gostaria que a Hashicorp investisse mais nessa direção (opinião pessoal).
O Octelium pode substituir os produtos mencionados acima, mas sua proposta e forma de uso são mais amplas e claramente orientadas a zero trust. É mais do que uma simples ferramenta de VPN/acesso remoto. Eu realmente gostaria que você lesse a documentação para entender a intenção, a arquitetura e os recursos. Hoje em dia todo produto anuncia "zero trust", mas poucos realmente implementam o ZTA verdadeiro definido pelo NIST (ou seja, proxies com consciência de L7, policy decision point, controle de acesso granular por requisição com políticas como código, identidade centralizada, integração com informações de ferramentas externas de SIEM/SSO/Threat intelligence etc.). Na prática, os produtos comerciais classificados como ZTA "de verdade" incluem Cloudflare Access, Teleport, Google BeyondCorp, StrongDM, Zscaler e alguns outros. Na verdade, as empresas têm abusado tanto desse termo que o conceito de "zero trust de verdade" acabou diluído.
Veja o modo cathedral do sanctum. É totalmente self-hosted, e os nós fazem apenas o papel de discovery. Depois que o túnel é estabelecido, o nó cathedral não participa mais, exceto na distribuição de black key ou quando um peer está atrás de NAT. Também existe o reliquary. Eu mesmo uso em produção. sanctum, reliquary
Você pode ver uma lista maior de projetos relacionados em awesome-tunneling.
Entendo que inserir a palavra-chave "AI" é por motivos de SEO. É como colocar "Reddit" no título de uma matéria. Mesmo que o conteúdo seja bom, esse tipo de coisa não passa uma impressão positiva. Os diagramas de API gateway e AI gateway também são quase idênticos. blog da tailscale: AI-normal
Estou procurando ativamente uma alternativa open source ao Tailscale. Mas o README é longo demais; seria melhor mostrar de forma condensada apenas a visão geral do projeto e os links para a documentação.
A maior vantagem do Tailscale é a facilidade das conexões P2P. O Octelium, em contraste, parece usar uma estrutura de roteador centralizado; queria confirmar se é isso mesmo.
O Octelium não é uma VPN P2P, e sim uma arquitetura zero trust. Claro, ele também pode atuar como uma VPN de acesso remoto baseada em WireGuard/QUIC, mas estruturalmente está muito mais próximo de Cloudflare Access e Teleport. Controle de acesso baseado em L7, acesso sem secrets (injeção sem distribuição direta de chaves, tokens, API keys etc.), configuração e roteamento dinâmicos, visibilidade e auditoria em tempo real com base em OpenTelemetry — tudo isso é essencialmente diferente de uma VPN P2P. Uma arquitetura ZTNA/BeyondCorp de verdade (excluindo service mesh) tem limitações fundamentais se implementada no formato de VPN P2P. Para controle de acesso e visibilidade por requisição, um proxy com consciência de L7 é indispensável.
Só como observação, o Tailscale também às vezes encaminha pacotes por meio de roteadores centralizados. Explicação dos tipos de conexão do Tailscale
Não entendo por que a instalação de um cluster k3s estaria embutida no aplicativo. Parece que seria mais claro algo fácil de adicionar à infraestrutura existente/uma CRD simples para expor serviços. O conceito em si, de um Cloudflare Access/Teleport open source, é legal, mas como a maioria acaba sendo customização sobre k8s, eu teria mais interesse se o foco fosse nas funções centradas em acesso.
octeliumctl applyou API gRPC, e o resto pode ser esquecido. Houve uma época em que os recursos eram CRDs, mas como havia recursos demais — usuários, sessões, serviços, namespaces (alguns independentes dos namespaces do k8s), políticas, dispositivos, credenciais etc. — e o volume de dados cresceu, o backendetcdacabou ficando instável. Por isso foi adotado um backend Postgres separado.Já existem projetos muito parecidos lançados por aí.
Fico me perguntando se isso é um substituto para gestão de acesso em nível de grande empresa (botnet corporativa). Se eu fosse uma grande empresa, provavelmente iria querer software de uma grande empresa e um pacote de suporte, por estabilidade; não sei se um projeto open source de um desenvolvedor solo conseguiria resolver esse problema.