Show HN: Octelium – FOSS Alternative to Teleport, Cloudflare, Tailscale, Ngrok

Original Article ↗ Hacker News Discussion ↗

What Octelium Is (per the thread)

  • Described as a self-hosted, FOSS “zero trust secure access platform” rather than a simple VPN.
  • Core ideas:
    • WireGuard/QUIC-based tunnels plus layer‑7, identity-aware proxies.
    • Fine‑grained, context-aware ABAC policies at the application layer (HTTP, SSH, DB, etc.).
    • Acts as ZTNA/BeyondCorp system, remote access VPN, API/AI/MCP gateway, and self‑hosted ngrok‑style tunnel.
    • Built as a distributed platform running on Kubernetes; Octelium manages identity-aware proxies somewhat like Kubernetes manages containers.

Confusion Over Scope and Messaging

  • Many readers say the README and HN description are dense, repetitive, and heavy with jargon/buzzwords (“zero trust”, “secretless”, “next‑gen”, etc.).
  • Multiple people report they still don’t know “what it does” after scanning the README.
  • Suggestions:
    • Start with 1–2 plain sentences explaining the core problem it solves (e.g., “centralized access control to all internal services”) and defer details to docs.
    • Explain concrete use cases from simple → advanced, with minimal acronyms.
    • Define all terms and compare to concrete things like VPNs, API gateways, Pomerium, Teleport, Cloudflare Access.
  • Others counter that the terminology is accurate for ZTNA; the real issue is layering and audience fit, not “marketing speak.”

Architecture vs Tailscale / Mesh VPNs

  • Clarified that Octelium is not a peer‑to‑peer mesh like Tailscale/ZeroTier; it’s more akin to Cloudflare Access/Teleport/StrongDM.
  • Focus is not exposing subnets or devices, but mediating access to specific resources and even sub-resources (e.g., HTTP paths) through L7 policies.
  • Uses Kubernetes nodes as gateways and service hosts; services are represented by identity-aware proxies with stable IPs/hostnames.
  • Some question performance/complexity vs simple WireGuard meshes; others see it as addressing a different (enterprise ZTNA) problem.

Kubernetes Dependency & Operational Model

  • Requires Kubernetes (or k3s) today; Octelium treats the cluster as its substrate but stores its own resources in Postgres, not as CRDs.
  • Some see Kubernetes as an overheavy dependency for “just” secure access or homelabs and would prefer a lighter deployment (e.g., single Docker container).
  • Others are concerned that Octelium appears to partially “replace” conventional Kubernetes workflows, raising questions about compatibility with existing CI/CD, RBAC, and monitoring.

Security, Trust, and Solo‑Dev Concerns

  • Skepticism about trusting a broad, security‑critical system from a solo developer with a short public history and “does everything” marketing.
  • Concern over secrets being stored in plaintext by default; author says this is deliberate (like Kubernetes) and provides gRPC hooks for plugging in external secret backends (Vault, KMS, etc.).
  • Some commenters go as far as raising “state actor/scam” vibes; others push back, arguing the code is fully open source and such accusations are unhelpful.

Feedback on Positioning and Product Strategy

  • Strong advice to:
    • Emphasize problems solved (centralizing authZ/audit, replacing fragmented VPN + per‑app auth stacks) instead of listing competing products.
    • Pick a primary audience (enterprise security vs HN/homelab crowd) and tune language accordingly.
    • Provide before/after architecture diagrams and migration stories for a realistic company.
    • Consider an easier “homelab edition” and/or a SaaS offering built on the toolkit.

Overall Reception

  • Mixed but engaged:
    • Enthusiastic interest from people seeking a FOSS alternative to Teleport/Cloudflare/StrongDM and from those who read the deeper docs, which some call “extremely detailed and well‑organized.”
    • Significant pushback on buzzwordy framing, breadth of scope, Kubernetes requirement, and the difficulty of understanding the value at a glance.