This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Blog

Updates and announcements for Nebula Commander.

Follow the GitHub repo for development news.

State of Nebula Commander Development (v0.4.0)

Exit nodes finally shipped, every color in the app is now user-configurable, and the whole UI finally looks like one product — a look at everything since v0.3.0.

It’s been a little over two weeks since the v0.3.0 update, where we listed exit nodes as the one big thing still missing and called out a still-inconsistent UI as ongoing work. Neither of those is true anymore. This one covers v0.3.0 through v0.4.0.

What’s new since v0.3.0

Subnet routers and exit nodes are here, built on Nebula’s own unsafe_routes. Turn any node into a subnet router (advertise a LAN behind it, Tailscale---advertise-routes-style) or an exit node (route all of another node’s traffic, Tailscale---advertise-exit-node-style). Routes are opt-in per consumer — advertising one never silently exposes it network-wide — and configurable from either side: a gateway’s “Used by” picker, or, new in this release, a simple Use Subnet Router/Use Exit Node dropdown on any other node that wants to consume one, without opening the gateway’s own settings at all. On Linux nodes running ncclient, the whole thing is automatic: local subnet discovery, IP forwarding, and nftables NAT rules, no host access needed. Everything else (Windows, macOS, Docker-deployed ncclient, bare nebula) gets the right config generated for it, with a full doc on the manual host-side steps. Getting the Nebula semantics right here took two fix-forward releases early on — via is mandatory on every unsafe_routes entry and the gateway’s own certificate needs a -subnets claim, or nebula refuses to start at all.

Every color in the app is now yours to change. The new Appearance page lets each user customize buttons, node status colors, type/OS badges, the group access diagram, and — new this release — the page background and a shared “container” background used by the sidebar, navbar, and every card, independently for light and dark mode. Every picker shows the hex code next to the swatch. You can also name and save color combinations as presets and switch between them later, a small personal theme library that’s private to your account. None of this is shared or admin-controlled — it’s a per-user preference, like the dark-mode toggle it lives next to.

The UI finally looks like one product. Nodes, Networks, and Groups moved to a consistent square-card grid layout earlier in the cycle; this release brings the Home dashboard and the admin Users page in line with the same pattern, replacing a full-width card list and a plain table respectively. Users’ three separate view/edit-role/delete dialogs also collapsed into one details panel with an inline edit toggle, matching how Nodes and Groups already worked. And on the Nodes page specifically, the fields you touch constantly (platform, group, lighthouse/relay, the new subnet-router/exit-node pickers) stay visible, while the ones you set once and forget (logging, punchy/NAT tuning, the gateway-side route configuration) are tucked under an Advanced disclosure.

A few real bugs got found and fixed along the way. Badges on a node’s card could grow tall enough on a narrow phone screen to cover the hostname and IP underneath them — fixed by keeping that text pinned above everything else, regardless of how many badges wrap. Wrapping the app in a themeable component surfaced a subtler one: the library’s own internal dark-mode tracking could drift out of sync with our toggle after a single light/dark switch and then silently override it on every later page load — fixed by keeping both in sync on every toggle, not just at first load. And a SQLite id-reuse edge case that could crash network creation after a network had ever been deleted outside the normal flow is cleaned up automatically on startup now.

The About screen tells you what you’re actually running. Frontend and backend version are both shown there now — the backend version was already available over the API, the frontend now gets the same release tag baked in at build time.

Current status

Nebula Commander’s core — networks, nodes, certificate lifecycle, firewall groups, Magic DNS, subnet routers and exit nodes, per-account theming, audit logging, invitations, multi-user management — is mature and running in production, and the Web UI is now visually consistent across all of it. The device client story hasn’t changed since v0.3.0: CLI, Windows service, Docker, NixOS, and first-class mobile support.

What’s still open: automatic host-level route/NAT setup for subnet routers and exit nodes on Windows and Docker-deployed nodes (Linux nodes running ncclient already get this for free) remains manual, and client hardening continues as real-world deployments surface edge cases.

See About: Status for the full implemented/planned breakdown.

How to get involved

Thanks for following along with Nebula Commander.

State of Nebula Commander Development (v0.3.0)

Nebula Commander has grown up since our last update: mobile support, lighthouse-based reachability monitoring, Nebula v2 certs, and a NixOS module for the device client, not just the server.

It’s been a little over six months since our last state-of-development post, when we described Nebula Commander as being in “early development” with a client that was “still evolving.” Since then the project has moved through v0.2.12 all the way to v0.3.0, and the picture has changed enough that it’s worth a proper update.

What’s new since February

The client is no longer the weak link. The Windows client was rearchitected around a real background service (NebulaCommanderService, running as LocalSystem) with a thin, always-unelevated tray app on top — no UAC prompts, ever, for enrolling, starting Nebula, or applying DNS. It ships three ways now: a standalone CLI, the Windows MSI (CLI + tray + service), and a Docker image with an s6-overlay supervisor for lighthouse deployments.

Mobile is a first-class platform, not an afterthought. iOS and Android nodes (via the official Nebula app from defined.net) get their own platform field, their own status handling, and a dedicated config-download flow in the Web UI — no ncclient required, since there’s nowhere to run it on a phone. Split-horizon DNS follows each platform’s actual capabilities: automatic on iOS (NEDNSSettings.matchDomains is genuinely domain-scoped), an explicit opt-in on Android (whose VpnService DNS API has no such scoping).

Certificates moved to Nebula v2, with P256 available as an opt-in curve alongside the original Curve25519, and a real correctness fix: editing a node’s group in the Web UI now automatically re-signs its certificate in place — no re-enrollment, no IP churn — since a Nebula cert bakes its group in at signing time and the two used to silently drift apart.

You can now tell when a node actually went dark. A lighthouse can ping the other nodes on its network and report reachability back on its own heartbeat; the server validates that report against the lighthouse’s real network membership (so a node can’t spoof status for peers it has no relationship to) and surfaces it on the Nodes dashboard alongside each node’s own check-in state — genuine node-offline detection, not just “haven’t heard from it in a while.”

Security got a dedicated pass. All 56 open Dependabot alerts and all 64 code-scanning alerts (CodeQL + Bandit) are closed, including a real PowerShell-injection bug in the Windows DNS-apply code. The dev-token bootstrap endpoint no longer works by default on a standalone (no-IdP) deployment — you opt in explicitly now. The JWT secret fails closed the same way the encryption key always has: leave it at the placeholder default, and the server refuses to boot. Reauthentication (step-up auth) now covers node deletion and certificate revocation, not just network deletion.

NixOS gets the client, not just the server. services.nebula-commander picked up production-auth options it was missing (OIDC, publicUrl, CORS, session security), and there’s a genuinely new services.ncclient module for running the device client declaratively — built, tested against a real NixOS system build, and documented in Server Installation: NixOS.

Current status

Nebula Commander is no longer “early development.” The core control plane — networks, nodes, certificate lifecycle (including automatic re-signing), firewall groups, Magic DNS, audit logging, invitations, multi-user management — is mature and running in production. The Web UI covers all of it. The device client is no longer the caveat it was in February: CLI, Windows service, Docker, and now NixOS, plus first-class mobile support.

What’s still open: exit nodes (full-tunnel routing via Nebula’s unsafe_routes) remain unimplemented, and client hardening continues as real-world deployments surface edge cases — most recently a Docker persistence bug where a container recreation could silently lose a node’s identity even though its device token survived, found and fixed by watching a real production lighthouse.

See About: Status for the full implemented/planned breakdown.

How to get involved

Thanks for following along with Nebula Commander.

State of Nebula Commander Development (February 2025)

A snapshot of what’s implemented, what’s in progress, and how you can run or contribute to Nebula Commander.

Nebula Commander is a self-hosted control plane for Nebula overlay networks. This post summarizes where the project stands as of February 2026 and how you can try it or contribute.

What’s in place

Backend (Python/FastAPI)
The API supports the core workflows: networks (create, delete), nodes (CRUD, IP allocation, certificates), groups and inbound firewall rules, and OIDC-based access with roles (system-admin, network-owner, user). You can run it with Docker, on NixOS via the systemd module, or locally with a venv and uvicorn.

Web UI (React)
The dashboard lets you manage networks, groups, and nodes; create or sign certificates; generate enrollment codes for the device client; and download ncclient binaries from your own server. Log in via OIDC (e.g. Keycloak) or, in development, with a dev token when DEBUG=true.

Device client (ncclient)
The experimental client enrolls with a one-time code, then polls the server for config and certificates and can run or restart Nebula when config changes. Available as a CLI and a Windows tray app; installable via pip install nebula-commander or from our releases.

Deployment
We document Docker (recommended) and NixOS installation, plus environment and OIDC configuration. The docs site you’re reading is the project’s main documentation.

Current status

The project is in early development. Core APIs and UI are implemented and usable for running your own Nebula networks with a central server. ncclient is still evolving (CLI and Windows tray; more platforms and packaging may follow). For production-like setups, we recommend using the Web UI and API to manage networks and nodes, then deploying config and certs manually and running Nebula yourself until ncclient stabilizes.

How to get involved

  • Run it – Follow Getting started and Server Installation, then use the Web UI to create a network and nodes.
  • Contribute – Code and issues live on GitHub. See Development for local setup, GitHub Actions, manual builds, and API overview.
  • Stay updated – Check the blog and the repo for announcements. We’ll post when we hit milestones (e.g. ncclient stability, new features, or release tagging).
  • Join us on Matrix - Join the Nebula Commander Matrix Space for discussions, support, and the latest development conversations.

Thanks for your interest in Nebula Commander.