Nebula 3: an operator-gated pentest workbench where AI assists but never executes

The problem Nebula targets is context loss, not missing scan coverage

Most penetration testing toolchains are good at producing output and bad at keeping it. A scan writes to one directory, a manual shell session lives in scrollback, notes end up in a separate editor, and the report gets assembled days later from memory. The README frames Nebula around exactly this: bringing terminal, code, browser, assistant, files, notes, missions, findings and reports into one desktop surface so that useful output can be preserved as evidence and carried into findings without losing context. The stated flow is intent, assistance, approval, execution, evidence. That ordering is the product thesis. The audience is a working operator running an authorized engagement, not a developer looking for a library to embed. Nebula ships as a desktop application with a bundled Core sidecar, and the README repeats the authorization warning in its own block: use it only on systems and networks you own or are explicitly authorized to test.

Authority is enforced by an approval gate, not by prompt instructions

The interesting design decision is where the human sits. According to the README, scope enforcement, approval pauses, hard budgets and isolated OCI execution all sit between AI assistance and the systems under test. That is a different architecture from an agent loop that calls tools directly and asks for forgiveness afterwards. Four separate controls are named: scope enforcement constrains what is in bounds, approval pauses require a human decision before something runs, hard budgets cap consumption, and OCI isolation keeps execution inside a container. The README also states that a model provider is optional, and that the human terminal, evidence workflow, notes, findings and reports remain available without one. That claim is worth taking literally. It means the AI is a convenience layer over a tool that is supposed to be usable on its own, which is a reasonable hedge against model availability, cost and data-handling objections during a client engagement. The trail side is content-addressed artifacts, append-only events, execution provenance and integrity-manifested exports. Append-only events matter here because they make the record of what was approved and executed harder to quietly rewrite.

Installing the preview means trusting an APT key and a container image download

The preferred install path is the signed Nebula APT repository. The README gives the archive key fingerprint as 1D90 1EB3 4C8C 1065 F118 680D 1C5C 924C B4B5 823D and instructs you to verify it before adding the channel. The commands are curl the keyring, pipe it through gpg --show-keys --fingerprint to inspect, then gpg --dearmor into /usr/share/keyrings/nebula-archive-keyring.gpg. The sources line is deb [arch=amd64 signed-by=/usr/share/keyrings/nebula-archive-keyring.gpg] https://berylliumsec.github.io/nebula-apt prerelease main, written to /etc/apt/sources.list.d/nebula.list. Then sudo apt install nebula and run nebula. Note the arch=amd64 pin: this is the x86_64 constraint showing up in the package configuration, not just in prose. Two alternatives are documented. A downloaded DEB can be verified with sha256sum --check --ignore-missing SHA256SUMS-linux-x64.txt and installed with sudo apt install ./Nebula-3.0.0-alpha.5-linux-x86_64.deb. An AppImage can be checksummed, chmod +x, and run directly with no system-wide install, using a signed direct-update channel. After launch, the README suggests nebula-core doctor --json to inspect the bundled Core and local runtime boundary. Docker or Podman is required for terminal and automation features, and first launch may download, prepare and verify the official Kali image, which the README says can take several minutes. That is a real setup cost on a fresh machine and it happens before the tool is useful.

Running from source pulls in four toolchains before you see a window

The source path is documented and heavy. Python 3.11 to 3.13, Poetry 2.1.3, Node.js 20 with npm, the stable Rust toolchain, and the Tauri prerequisites for your operating system. Then git clone, cd nebula, poetry install --with dev, poetry run playwright install chromium, npm --prefix ui ci, and npm --prefix ui run dev:desktop. The README explains why Playwright is there: the browser renders JavaScript-driven URL knowledge sources, and signed Linux installers bundle the locked Chromium headless runtime while a source checkout needs the explicit install step. Nebula can also use an existing system Chrome or Chromium. For pre-merge work there is a second path: npm --prefix ui run build followed by poetry run nebula-core ui, which lets Core choose an available loopback port. The stated checks are python scripts/nebula3_version.py check, poetry run pytest -q tests/v3, npm --prefix ui test, and npm --prefix ui run build. If you only want to use Nebula, the source route is the wrong choice; it exists for people changing it.

The release matrix is narrow and the version numbering is honest about it

The current release candidate is Nebula 3.0.0-alpha.5 for Linux x86_64, and the README states plainly that macOS, Windows and Linux arm64 installers are not part of the current release matrix. It also warns not to use pip install nebula-ai to install Nebula 3, which is a useful guard against a plausible mistake given the Python packaging. There is a second trap in the release history: 2.0.1b1 and 2.0.1b2 were published in July 2026, shortly before the 3.0.0 alpha line, so searching a package index or release list can surface a 2.x beta that is not the current preview. The README's own rule is that a build exists only when a nebula-v3.* entry and its native artifacts appear on GitHub Releases. That is a stricter definition than most projects use and it means an empty or partial release page is a signal, not an accident. The prerelease APT channel is described as intentional while Nebula 3 is in preview, with future updates remaining under administrator control through the normal APT workflow. For a tool that will be pointed at client infrastructure, running an alpha means the operator owns the risk of a regression mid-engagement.

Migrating from Nebula 2 is an import, not an in-place upgrade

Nebula 2 engagement data does not get upgraded in place. The documented procedure is to quit Nebula 2, preserve a backup of the engagement directory, and import without modifying the source using nebula-core import-2x with the path to the nebula-2-engagement directory. The README then says to verify the imported project and its evidence before deleting the original data, and points at docs/MIGRATING-2-TO-3.md for the complete integrity and recovery procedure. The word verify is doing real work in that sentence. Because the import does not modify the source, the old directory is the fallback if the imported evidence does not reconcile, and deleting it early removes that option. Anyone with live 2.x engagement data should treat the migration document as required reading rather than optional, and should not schedule the cutover in the middle of an active engagement.

Where Nebula is the wrong tool, and what it is not replacing

Nebula is a Linux desktop workbench, so a team standardised on macOS laptops or Windows endpoints cannot deploy it today, and that is a hard boundary rather than a configuration problem. The container dependency is the second constraint: terminal and automation features need Docker or Podman, which rules it out on hardened hosts where no container runtime is permitted, and the first-launch Kali image preparation adds a network and disk cost that a locked-down environment may not tolerate. The third case is scope. If your requirement is unattended, high-volume scanning across many hosts, a desktop application with an approval pause in the loop is the wrong shape; the approval gate that makes Nebula defensible on a single authorized engagement is exactly what makes it slow at fleet scale. As a comparison, a plain shell plus tmux plus a notes directory covers the terminal and note-taking parts with no container requirement and no model dependency, and it works on any architecture. What it does not give you is the append-only event record, execution provenance and integrity-manifested exports that Nebula builds around the flow from approval to evidence. That difference is the whole purchase decision: you are choosing a recorded, gated process over an ad hoc one, and paying for it in platform support and setup time.

Licence, update cost and what to check before you commit

Nebula is BSD-2-Clause, a permissive licence that allows modification and redistribution with the copyright notice and disclaimer retained. That is a low-friction choice for internal security teams, and it means the practical cost of adopting Nebula is not licensing but maintenance. Updates arrive through APT on the prerelease channel, so keeping current means accepting a moving alpha rather than a fixed version, and the README's advice to back up engagement data and review release notes and checksums before use applies to every update, not just the first install. The AppImage path uses a separate signed direct-update channel, so a mixed fleet would have two update mechanisms to track. There is no published statement in the supplied material about a support window, an LTS track, or how long the prerelease channel will run before a stable 3.0 release, so anyone planning a multi-month deployment should ask the maintainers directly rather than assume. The concrete checks before committing are the ones the project already documents: verify the APT fingerprint, run nebula-core doctor --json and read the Core and local runtime boundary output, confirm Docker or Podman is present and that first-launch image preparation completes on your network, and rehearse the import-2x path against a copy of a real engagement directory before you touch production data.

Editorial conclusion

Adopt Nebula 3 if your engagement work already runs on Debian, Ubuntu or Kali x86_64 with Docker or Podman present, and you want the AI layer to stay advisory while you keep the approval gate. Do not adopt it if you need macOS, Windows or arm64 today, or if you cannot accept a prerelease channel for client work. Before committing, run nebula-core doctor --json on the target machine, confirm the Core and local runtime boundary reports clean, and verify the APT archive key fingerprint 1D90 1EB3 4C8C 1065 F118 680D 1C5C 924C B4B5 823D against the published keyring.

Official sources

1. berylliumsec/nebula on GitHub
2. License: BSD-2-Clause
3. Project website
4. README
5. Releases