Oxker

A TUI for viewing and controlling Docker containers, honestly reviewed. No marketing, just what it is.

TL;DR

• What it is: A terminal user interface (TUI) built in Rust for viewing and controlling Docker containers — keyboard-driven, no web server, no browser required [README].
• Who it’s for: Sysadmins and developers who live in the terminal and want Docker management without spinning up a web UI or remembering a long docker ps --format incantation. Not a tool for non-technical founders.
• Cost: $0. MIT-licensed, single binary, no SaaS tier, no commercial edition, no upsell [README].
• Key strength: Zero runtime dependencies beyond the Docker socket. Install one binary, run it, get a full container overview. For someone already SSH’d into a server, this is the fastest path to inspecting running containers [README].
• Key weakness: Terminal-only. If you need a web UI, multi-user access, or role-based permissions, Oxker does none of that. It’s a local inspection and control tool, not an administration platform [README][1][5].

---

What is Oxker

Oxker is a single-binary TUI application for Docker. You run oxker in a terminal and get a live, keyboard-navigable view of all containers on the host: their status, CPU/memory usage, image, ports, and logs. You can start, stop, restart, and exec into containers without leaving the interface.

It’s built in Rust using ratatui (the TUI framework) and bollard (an async Docker API library). That combination matters: Rust gives you a self-contained binary with no runtime dependencies, ratatui gives you a responsive terminal interface, and bollard means it talks directly to the Docker API rather than shelling out to the Docker CLI [README].

The project is a one-person effort by mrjackwills. As of this review it sits at 1,571 GitHub stars and 47 forks — small compared to Portainer’s enterprise scale, but healthy for a focused TUI tool [README]. There have been 1,107 commits and 50 releases, which signals consistent maintenance rather than an abandoned side project [README].

What it is not: a web application, a multi-host management platform, a deployment tool, or a Portainer competitor in any meaningful sense. It’s closer to htop for Docker than it is to a container management platform. Comparing it to Portainer is like comparing vim to VS Code — they solve different problems for different people.

---

Why people choose it

The sources available for this review are AlternativeTo pages for competing tools where community members listed Oxker as an alternative [1][2][3][4][5]. That’s a specific signal: people who evaluated Portainer, Yacht, Dokemon, Dockman, and Komo.do and found them heavier than what they needed ended up pointing to Oxker as the lighter option.

The pattern that emerges: Oxker is what you reach for when you want zero infrastructure overhead for Docker inspection. Every other tool in the comparison set requires running a persistent web server, a database, or a daemon. Portainer is a full web application with its own container and data volumes [5]. Yacht is a Flask app that needs to be deployed and maintained [4]. Dockman manages Docker Compose files through a web UI [2]. Komo.do is a multi-server deployment platform written in Rust but designed for fleets [3]. Dokemon had a web GUI but its domain is down and the project appears abandoned as of early 2026 [1].

Oxker asks for nothing except the Docker socket. You mount /var/run/docker.sock (read-only if you want), run the binary or container, and it works. That’s genuinely appealing to the kind of person who thinks a web server for inspecting containers is overkill — and a real security consideration, since every persistent web UI is an attack surface.

The Rust-and-ratatui combination also shows up in comparisons. Several alternatives in this space are TypeScript/Node.js apps (Dokemon, Dockman, Yacht) [1][2][4]. A Rust binary that compiles to ~10MB is meaningfully different from running a Node.js server for container inspection.

---

Features

From the README directly — these are confirmed features, not marketing claims:

Container management:

• Live list of all containers with status, CPU, memory, image, and port information [README]
• Start, stop, restart, pause, unpause, and remove containers via keyboard commands [README]
• Exec into a selected container (uses Docker API by default; --use-cli flag to use the Docker binary instead) [README]
• Container inspect mode (i key) — shows detailed container configuration [README]

Log viewing:

• Real-time log streaming per selected container [README]
• Log search mode (# key) [README]
• Raw log mode (-r flag) or colorized logs (-c flag) [README]
• Toggle timestamps on/off (-t flag) [README]
• Export logs to file with s key — saves to $HOME/[container_name]_[timestamp].log or a custom directory [README]
• Adjustable log panel height (- / = keys) and toggle visibility (\ key) [README]

Navigation and filtering:

• Keyboard-driven: tab/shift+tab for panels, arrow keys or vim-style j/k for scrolling [README]
• Filter mode (F1 or /) to search containers by name [README]
• Sort by any column using 1-9 number keys; 0 to clear sort [README]
• Mouse support (optional, toggle with m; when disabled, text can be selected for copy) [README]
• Horizontal scrolling for wide text (←/→) [README]

Configuration:

• Config file support: config.toml, config.json, or config.jsonc — persists settings across sessions [README]
• Custom Docker socket/host via --host flag or $DOCKER_HOST environment variable [README]
• Timezone override for log timestamps (--timezone flag) [README]
• Configurable update interval for Docker polling (-d flag, default 1000ms) [README]

What’s missing (compared to web UI alternatives):

• No web interface — terminal only [README]
• No multi-host management [README]
• No user authentication or role-based access [README]
• No Docker Compose-aware stack management [README]
• No image management, registry pulls, or volume management [README]

---

Pricing: there isn’t any

Oxker has no SaaS tier, no commercial edition, and no pricing page. It’s MIT-licensed software that costs nothing to run [README]. The only cost is the time it takes to install it, which is measured in seconds.

For comparison, since this site exists to help people escape SaaS costs:

• Portainer Business Edition: free for up to 3 nodes, then commercial pricing for larger deployments [5]
• Yacht: MIT-licensed, but requires deploying and maintaining a Flask web application [4]
• Dockman: AGPL-3.0, web UI, requires deployment [2]
• Portainer Community Edition: free, web UI, requires its own Docker container [5]

If you’re already SSH’d into a server and want to inspect containers, Oxker costs $0 and takes 30 seconds to install. If you need a persistent web dashboard that multiple people can access, Oxker is the wrong tool regardless of price.

---

Deployment reality check

Install options, all of which work as advertised [README]:

One-liner on any Linux x86_64:

wget https://www.github.com/mrjackwills/oxker/releases/latest/download/oxker_linux_x86_64.tar.gz && \
tar xzvf oxker_linux_x86_64.tar.gz oxker && \
install -Dm 755 oxker -t "${HOME}/.local/bin" && \
rm oxker_linux_x86_64.tar.gz oxker

Via Cargo (if you have Rust installed):

cargo install oxker

Via Docker (no local install needed):

docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock:ro --pull=always ghcr.io/mrjackwills/oxker

Via Homebrew (macOS):

brew install oxker

Via Nix, AUR — both supported [README].

The Docker image supports linux/amd64, linux/arm64, and linux/arm/v6 — covering the Raspberry Pi use case that shows up constantly in homelab circles [README].

What can go sideways:

• Running Oxker itself inside Docker to manage other Docker containers is slightly recursive. You mount the Docker socket read-only (docker.sock:ro) which prevents Oxker from making write operations. For full control (stop/start containers), you need to drop the :ro or run the binary natively. The README shows the read-only mount as the default Docker run command [README].
• Exec into containers (e key) is not available on Windows [README].
• The --use-cli flag for exec requires the Docker CLI binary to be present — if you’re in an environment where only the socket is available, this flag won’t work [README].
• No persistent config by default — settings reset on exit unless you create a config file [README].

Realistic setup time for a developer: under 2 minutes. Seriously. For a non-technical founder unfamiliar with terminals: Oxker is not for you, and that’s fine.

---

Pros and cons

Pros

• Zero infrastructure overhead. No web server, no database, no persistent daemon. One binary that reads the Docker socket and renders a TUI [README].
• MIT license. Use it, fork it, embed it, ship it in your own tooling. No commercial restrictions [README].
• Multi-architecture support. Pre-built for x86_64, ARM64, and ARMv6 — works on Raspberry Pi without compiling from source [README].
• Multiple install paths. Cargo, Docker, Homebrew, Nix, AUR, pre-built binary, install script. Whatever your environment, there’s a path [README].
• Keyboard-driven with vim bindings. j/k scrolling alongside arrow keys is the kind of small thing that matters if you’re in the terminal all day [README].
• Log search built in. Most minimal Docker tools skip this. Oxker has a dedicated search mode for container logs [README].
• Exec support. You can shell into a container directly from the TUI — no context-switching to another terminal window [README].
• Actively maintained. 1,107 commits and 50 releases from a solo developer is a good track record [README].
• Read-only mode. Mount the Docker socket as :ro if you want a view-only interface with no risk of accidental container stops [README].

Cons

• Terminal only. If you need a web UI — for remote access via browser, for sharing with teammates, for viewing on mobile — Oxker is the wrong tool [README][5].
• No multi-host support. You can connect to a remote Docker socket via --host, but there’s no fleet view or multiple-server management [README].
• No Docker Compose awareness. Oxker sees containers, not stacks. If you have a 5-container Compose setup, you manage them individually, not as a group [README]. Dockman and Portainer both handle this better [2][5].
• No image or volume management. Can’t pull images, clean up volumes, or manage networks from within Oxker [README].
• Solo maintainer. One person project. Not a criticism — the maintenance record is solid — but worth noting if you’re evaluating long-term reliability for production workflows.
• No authentication. Doesn’t apply since it’s a local TUI, but this is why you can’t expose it to a team.
• Small community. 1,571 stars and 47 forks. If you hit an edge case, you’re likely opening an issue rather than finding an existing answer [README].

---

Who should use this / who shouldn’t

Use Oxker if:

• You’re a developer or sysadmin who spends time in terminals and finds docker ps + docker logs + docker stats tabs annoying to manage separately.
• You want a quick way to inspect containers on a remote server over SSH without deploying a web UI.
• You’re on a Raspberry Pi or low-memory ARM device where running a web application for container management feels wasteful.
• You want read-only visibility into production containers without the security footprint of a web server.
• You already know what you’re doing with Docker and just want a better interface for routine inspection tasks.

Skip it if:

• You’re a non-technical founder. The terminal is the entire interface. There is no GUI. If docker exec is foreign, this tool will not help you [README].
• You need to share container management with a team. Oxker has no authentication, no web interface, and no multi-user concept [README][5].
• You manage containers across multiple servers and want a single dashboard. Use Portainer or Komo.do instead [3][5].
• You need Docker Compose stack management — start/stop entire stacks, view service dependency graphs. Use Portainer or Dockman [2][5].
• You want to pull images, manage volumes, or configure networks. Oxker doesn’t touch any of that [README].

---

Alternatives worth considering

Based on the AlternativeTo comparisons where Oxker appears [1][2][3][4][5]:

• Portainer — the obvious choice if you want a web UI. Feature-complete Docker and Kubernetes management, active enterprise support, Community Edition is free. Requires running a persistent container. 48,000+ GitHub stars [5].
• Yacht — MIT-licensed web UI with template-based 1-click deployments. Simpler than Portainer, focus on homelabs. Currently being rewritten (was Flask, moving to Flask + Vue). Less actively maintained [4].
• Dockman — AGPL-3.0 web UI focused specifically on Docker Compose file management. Good if Compose stacks are your primary workflow [2].
• Komo.do — GPL-3.0, written in Rust, built for deploying and managing software across multiple servers. 10,886 stars. Significantly more complex than Oxker — closer to a self-hosted Heroku [3].
• Dokemon — MIT-licensed web UI that appeared promising but the domain is down and the project hasn’t been updated in 2 years. Avoid [1].
• Lazydocker — the closest direct competitor to Oxker in the TUI space. Also a terminal UI for Docker, written in Go. More widely known (25,000+ stars), slightly different feature set. Worth comparing directly if you’re in this space.
• ctop — older, simpler TUI focused purely on container resource monitoring. Less feature-complete than Oxker but extremely minimal.

The honest shortlist for the TUI niche: Oxker vs Lazydocker. Both are terminal-only, both are free, both handle inspection and basic control. Oxker is Rust, Lazydocker is Go. If you have strong feelings about language or want to audit the code, that distinction matters. Otherwise, try both — install takes under a minute each.

---

Bottom line

Oxker does one thing: gives you a usable terminal interface for Docker containers. It does that thing well, with solid keyboard ergonomics, built-in log search, exec support, and multi-arch binaries. The MIT license and zero-infrastructure footprint make it the lowest-friction option when you need quick Docker inspection on a remote host.

The limitations are structural, not bugs: no web UI, no multi-host, no team features. For a solo developer or sysadmin who wants a better docker ps, it’s a clean choice. For a non-technical founder trying to escape SaaS bills on their startup stack, this review probably isn’t about a tool you’d use directly — but it might describe exactly what the person you’d hire to manage your infrastructure is already running.

---

Sources

1. AlternativeTo — Dokemon (container management GUI alternatives page, community-sourced). https://alternativeto.net/software/dokemon/about/
2. AlternativeTo — Dockman (Docker Compose manager alternatives page). https://alternativeto.net/software/dockman/about/
3. AlternativeTo — Komo.do (multi-server deploy tool alternatives page). https://alternativeto.net/software/komo-do/about/
4. AlternativeTo — Yacht (Docker web UI alternatives page). https://alternativeto.net/software/yacht/about/
5. AlternativeTo — Portainer (container management platform alternatives and reviews page, 4 reviews). https://alternativeto.net/software/portainer/about/

Primary sources:

• GitHub repository and README: https://github.com/mrjackwills/oxker (1,571 stars, MIT license, mrjackwills)
• crates.io package: https://crates.io/crates/oxker
• Docker Hub image: https://hub.docker.com/r/mrjackwills/oxker
• GitHub Container Registry: https://ghcr.io/mrjackwills/oxker