Skip to main content

​
Requirements

Install and start Docker first. The Engine’s service user must be able to access its socket. The installer checks Docker but does not install it.
The installer also requires curl, tar, and openssl. Git deployment and the template store require git on the Engine machine. Released bundles contain the CLI, Engine, and pinned Caddy binary; Python is not required. GPUs are optional. CPU applications, databases, external AI bindings, and CPU Ollama serving work without one. NVIDIA inference requires a working driver and NVIDIA Container Toolkit on Linux or WSL2. macOS containers do not receive NVIDIA GPU access. AMD support is experimental and opt-in.

​
Install

The installer uses /opt/nerdit, registers nerdit.service, and runs the Engine as the user who invoked sudo. Run subsequent CLI commands as that user.
If the installer asks you to add ~/.nerdit/bin to PATH, follow that instruction and open a new shell. The service starts automatically:
The local dashboard is at http://127.0.0.1:9321/. The proxy is initially disabled.
Run nerdit as the recorded service user. sudo nerdit doctor generally reads root’s configuration and may return 401. The Linux system install only needs sudo for installation, service management, upgrades, and removal.

​
Connect to the App

The installer currently served by get.nerdit.ai installs and starts the Engine, then asks you to link separately. A local Engine works without an account link. To connect your App account, run as the Engine’s service user:
Approve the displayed request in your browser and follow the CLI’s restart instruction. A successful installation alone does not prove that the account link exists. For unattended linking after installation, read a pre-auth key from a file created through the App and restricted to the intended service user:
The key reaches the CLI through stdin, not a command argument. Do not print it, put it in shell history, or use tracing around credential handling. The public installer does not currently accept enrollment flags such as --key-file or --no-link; use the separate CLI linking step.

​
Files and service management

State normally lives in the service user’s ~/.nerdit, separately from versioned code. Configuration may select another data directory. Preserve the existing service user and data directory when upgrading or recovering.

​
Verify and upgrade a release

The installer verifies an ECDSA P-256 signature over SHA256SUMS using its embedded release key, then checks the selected archive’s checksum before extraction. Review published release notes and checksums when pinning a release. A checksum and key downloaded from the same untrusted location do not independently establish trust.
Use sudo nerdit update for a Linux system installation; run the verification commands afterward as the service user. Upgrades preserve configuration and state. Application containers keep running while the Engine restarts and reconciles them. There is no automatic updater. To select the verified published release explicitly:
The same command can downgrade code. Take a backup first and check state/schema compatibility; an older executable is not a data rollback. An unpinned update refuses a lower release version. A fresh pinned Linux system installation uses sudo NERDIT_VERSION=0.5.5 sh on the installer side of the pipe.

​
Remove Nerdit

Default uninstall removes the Engine’s data, secrets, logs, managed containers, application images, and locally saved trust files. Back up data and keys before proceeding. --keep-data preserves Engine state but still removes managed containers and installed code.
Use sudo for both commands on a Linux system installation. Inspect the dry-run’s resolved data directory. Without --keep-data, uninstall is destructive. --yes skips confirmation; --purge-images also removes base images pulled for models, databases, and runtimes. Uninstall stops the Engine and verifies that its data lock is free before removal. If it cannot establish that the Engine stopped, it aborts rather than remove state beneath a live process. Uninstall does not remove the CA from the operating system’s trust store automatically. Run nerdit untrust before removing the package, or follow the manual trust-removal commands printed by uninstall. Remove that CA from other client machines too when retiring it. Continue with the quickstart, or use development setup when working from source. Do not run nerdit init over an installer-managed configuration.