A fast, Linux-first desktop client for the Docker Engine API.

A lightweight alternative to Docker Desktop — it manages the engine you already run, without the resource overhead.

Download · Features · Safety · Build from source

---

What it is

docknox is a desktop GUI for a Docker Engine you already have installed and running. It talks to the engine over its public, documented HTTP API — the local Unix socket by default, or a context you point it at — and gives you a dense, fast view over containers, images, volumes, networks and Compose projects.

It is a management client, not a runtime. docknox does not bundle, install, start or replace dockerd. If the socket is unreachable, it says so plainly and waits; it never tries to take the engine's job.

The engine is the single source of truth. Nothing is cached as truth — the UI reacts to the docker events stream and re-reads.

Screenshots

_{Containers — live status, per-row CPU and memory, published ports, Compose grouping.}

_{The detail panel — with logs, live stats and an interactive terminal one tab away. Environment variables are listed by name only; values never reach the interface.}

Features

Containers

• Live list with status, health, per-row CPU and memory, published ports and Compose grouping
• Start · stop · restart · pause · resume · kill · remove · rename
• Streaming logs with follow, stderr marking, line counts and jump-to-latest
• Interactive exec terminal (xterm.js), which picks a shell that actually exists in the image
• Live resource stats — CPU, memory, network and block IO
• Port, mount and environment overview; published ports open in your browser in one click
• Filter by name, image or id; filter by state; sort by any column, including live load
• Prune stopped containers, with the targets enumerated first

Images

• List with tags, digests, size and in-use count
• Pull with live per-layer progress
• Tag, inspect, view build history, remove
• Prune dangling or unused images

Volumes

• List, create, inspect, remove
• See which containers use a volume before you touch it
• Prune anonymous or unused volumes

Networks

• List, create, inspect, remove
• Connect and disconnect containers
• Built-in and internal networks marked; prune unused

Compose

• Projects discovered from engine labels — no file hunting, no daemon of our own
• Per-service status, grouped as a first-class unit
• Start · stop · restart the project, down, and down + volumes as two deliberately distinct actions

System & connection

• Engine info, version, architecture, storage driver, cgroup version, rootless state
• Disk usage breakdown and a global prune composed from the per-resource rules
• Live event stream
• Connection state always visible; local, rootless and remote engines are visually distinct, so a remote host is never mistaken for your laptop

Stack wizard

Build a multi-service stack from a bundled catalogue of common services, or search Docker Hub, then review it before anything is created.

Safety — the DangerGuard

Access to the Docker socket is effectively root on the host. A GUI that fires destructive operations on a single click is dangerous. docknox's whole design premise is making that power convenient without making data loss accidental.

Every destructive operation is a proposal, not a call. A service hands the guard a plan plus the closure that would execute it; only a confirmed, single-use token can run that closure. There is no path around it.

• Everything data-losing goes through it — container remove, volume remove, image remove and prune, network remove, system prune, Compose down --volumes, kill.
• Confirmations are specific. They name what will be affected, how many, and whether data is actually destroyed. Batch and prune operations enumerate their targets before running.
• "Destroys data" is used precisely, so it keeps meaning. Volumes always. Untagged images yes; tagged images no — a pull restores them. Networks never.
• Guard rails, not nags. Start, stop, restart, pause, logs and inspect are frictionless. Over-prompting trains people to click through, which defeats the point.
• No hidden background mutations. docknox never auto-prunes, auto-pulls or auto-updates anything. It does what you asked, and nothing else.

Security architecture

Boundary	How it is held
Renderer	No Node integration, contextIsolation and sandbox on, strict CSP. It never opens the socket, spawns a process, or reaches the network.
Preload	A minimal, explicitly whitelisted, typed contextBridge surface. No raw ipcRenderer escapes.
IPC	Every payload validated with Zod at the boundary; unknown channels and shapes are rejected.
Engine access	The main process is the single owner of the Docker client. Nothing else opens a socket.
Streams	Logs, stats, events and exec run in a utilityProcess worker over a transferred MessagePort, so chatty IO never crosses the main thread — and are reference-counted and torn down on unmount.
Secrets	Container environments routinely hold credentials. Values are never sent to the renderer — only names are. Nothing sensitive is logged.
Navigation	The window cannot navigate to arbitrary URLs; external links are handed to the system browser.

Raw Engine API JSON never reaches the renderer. Services map it to shared view models, so the UI cannot depend on the shape of an API version.

Install

Grab the build for your platform from the latest release.

Platform	Download
Linux	.AppImage (portable), .deb (Debian/Ubuntu), .rpm (Fedora/RHEL/openSUSE) — x64 and arm64
macOS	.dmg — Apple Silicon and Intel
Windows	.exe installer, or a portable .zip — x64 and arm64

Every release ships a SHA256SUMS.txt; verify with sha256sum -c SHA256SUMS.txt.

Linux

# AppImage — no installation
chmod +x docknox-*-linux-x86_64.AppImage
./docknox-*-linux-x86_64.AppImage

# Debian / Ubuntu
sudo apt install ./docknox-*-linux-amd64.deb

# Fedora / RHEL / openSUSE
sudo rpm -i docknox-*-linux-x86_64.rpm

macOS — unsigned build

Builds are ad-hoc signed, not notarised (there is no paid Apple Developer certificate behind this project). macOS will refuse the first launch. To clear the quarantine flag:

xattr -dr com.apple.quarantine /Applications/docknox.app

Only run this for software you actually meant to download.

Windows — unsigned build

The installer is not code-signed, so SmartScreen will warn on first run: More info → Run anyway.

Note on platform support. Linux is the priority target and where docknox is developed and tested. The macOS and Windows builds are produced by the same CI pipeline and are best-effort — the Engine API is the same, but they get less real-world mileage.

Requirements

• A running Docker Engine you can reach — the default /var/run/docker.sock, a rootless socket, or a configured context. docknox does not install or start one.
• If docker ps works in your terminal, docknox will connect.

Being able to talk to the Docker socket is equivalent to root on the host. If you are weighing adding your user to the docker group, know that this grants root-equivalent access to the machine — a rootless Docker setup is the safer arrangement, and docknox supports it and labels it in the UI.

Build from source

git clone https://github.com/Noxisan/docknox.git
cd docknox
npm install

npm run dev          # HMR for the renderer, reload for main/preload
npm run typecheck    # must be clean
npm run lint
npm run test         # 522 tests
npm run build        # -> out/

npm run dist:linux   # -> release/
npm run dist:mac
npm run dist:win

Node 20 LTS or newer. Cross-platform packaging is done in CI, not locally — a tag matching v* builds and publishes every artefact.

Architecture

┌──────────────────────────────────────────────────────────────┐
│  RENDERER (React 19)                                          │
│  UI only. No Node. Never touches the Docker socket.           │
└──────────────▲────────────────────────────────────┬───────────┘
               │  contextBridge (typed, Zod-validated)
┌──────────────┴────────────────────────────────────▼───────────┐
│  PRELOAD — minimal whitelisted API. No raw ipcRenderer.       │
└──────────────▲────────────────────────────────────┬───────────┘
               │  IPC (validated channels)
┌──────────────┴────────────────────────────────────▼───────────┐
│  MAIN — lifecycle, settings, connection manager,              │
│  domain services, DangerGuard. Sole owner of the socket.      │
└──────────────▲────────────────────────────────────┬───────────┘
               │  MessagePort
┌──────────────┴────────────────────────────────────▼───────────┐
│  STREAM WORKER (utilityProcess) — logs, stats, events, exec.  │
└───────────────────────────────────────────────────────────────┘

Each area of Docker is an isolated main-side service with a shared shape, mapping raw Engine API responses to view models defined once in src/shared. Services are the only code that touches the Docker client, and every one is covered by fixture-based tests.

Tech stack

Electron 42 · TypeScript 6 (strict, exactOptionalPropertyTypes) · React 19 · electron-vite · Tailwind 4 with CSS-variable theme tokens · Zustand · Zod at every IPC boundary · i18next · dockerode · xterm.js · Vitest

Design

Dark-first, deep blue, deliberately quiet. Colour is reserved almost entirely for status — emerald for running, amber for paused, red for genuine failure, and muted neutral for a cleanly exited container, because a stopped container is not an error. Lists are compact and scannable; live values update in place without layout shift.

The interface is fully keyboard navigable, meets WCAG AA contrast in both themes, respects prefers-reduced-motion, and is mirror-safe for RTL locales. It ships in English and German.

Contributing

Issues and pull requests are welcome.

• Branches follow Gitflow — main (releases), develop (integration), feature/*
• Commits follow Conventional Commits
• npm run typecheck, npm run lint and npm run test must be clean
• New Docker capability belongs in an isolated main-side service with fixtures, and anything destructive must pass through the DangerGuard with an accurate confirmation

License

MIT © Noxisan

---

_{docknox is an independent, open-source client for the Docker Engine API. It is not affiliated with, endorsed by, or sponsored by Docker, Inc. It contains no Docker Desktop or Docker, Inc. proprietary code and does not bundle the Docker Engine. "Docker" is a trademark of Docker, Inc.}