Skip to content

Full-stack, one team

Nominal

ARGV

Developer Tooling

Open source

argv-docker-manager

The dev containers this team runs, managed from the terminal

argv-docker-manager

v0.3.0-1 [x86_64-linux]
Rust TUI
argv-docker-manager TUI running 3 active container stacks with live activity events
Overview

Dev environment stacks, unified in one screen

Engineering teams running local development environments frequently manage multiple Docker Compose services—databases, message brokers, caching tiers, and admin consoles. In practice, services get started ad-hoc across scattered directories, forgotten in background processes, and lost across machine reboots.

argv-docker-manager is a high-performance terminal UI written in Rust. It isolates each development service into its own clean directory under containers/, automatically discovering stacks, providing single-keystroke container control, live stream telemetry, and opt-in boot persistence without requiring global Docker daemon changes.

System Profile

Primary PurposeLocal Dev Container TUI
Core ArchitectureRatatui + Tokio Async Engine
Discovery Sourcecontainers/* (Plain Compose YAML)
Boot ManagementSystemd User Unit + Local TOML
Interface

Structured panes for high-frequency workflows

The TUI layout splits daily operations into dedicated concurrent surfaces, keeping service status visible and log streams immediately accessible.

Services Fleet Column

Navigation

Lists all discovered projects under containers/* with live status tags (RUNNING / STOPPED). Pressing s starts or stops a stack asynchronously without stalling the UI.

Activity & Events Telemetry

Stream View

Inspects container lifecycle events, pull progress, and network bindings in real time. Pressing l switches the active pane between live engine events and full container stdout/stderr output with auto-scrolling.

Daemon Sentinel & Diagnostics

Status Rail

Continuous readiness polling for the Docker socket, CLI binary, and Compose plugins. Pressing d reveals daemon diagnostic metrics and active systemd auto-start rules.

Initial Discovery State

argv-docker-manager initial scan showing discovered container stacks
Controls

Complete terminal navigation at your keys

Every action is mapped to single-stroke keyboard shortcuts. All keybindings can be configured in keybinds.toml.

Vim-Inspired Navigation

Standard directional movements follow standard terminal ergonomics (j / k or arrow keys), preventing hand repositioning during coding sessions.

Configuration: keybinds.toml

[keybinds]
toggle_service = "s"
toggle_autorestart = "a"
switch_tab = "t"
filter_fuzzy = "/"
daemon_menu = "d"
exit_app = "q"

Active Shortcut Reference

KeyActionDescription
j / kNavigate ListMove cursor selection up and down across discovered service stacks
sStart / StopExecute docker compose up -d or down asynchronously for selected stack
aToggle Auto-StartPersist boot restoration flag in local .argv-docker-manager-autorestart.toml
lToggle ActivitySwitch activity stream between live container output and engine events
/Fuzzy FilterFilter services and container names with instant fuzzy search matching
dDaemon SentinelOpen Docker engine diagnostics and systemd boot service status modal
qClean ExitRestore terminal screen buffer and exit without terminating background containers
Architecture

Decoupled event loop and asynchronous runtime

Terminal rendering and background container tasks run on separate execution contexts, ensuring the user interface never stutters during Docker daemon operations.

Dedicated Terminal UI Thread

Powered by ratatui and crossterm, the main loop handles input polling and 60fps frame buffer rendering directly to the terminal alternate screen buffer.

Non-Blocking Tokio Async Runtime

Docker Compose child processes, daemon health checks, and log stream readers execute as asynchronous background tasks. Communication flows across unbounded crossbeam channels.

Zero-Config Project Discovery

On startup, the scanner scans containers/*/compose.yaml, parsing service names, exposed ports, and volume targets without requiring a central database.

Thread & Data Pipeline Topology

Terminal Thread (Crossterm + Ratatui)
Key Events • Frame Buffer • Screen Sizing
↑↓ [tokio::sync::mpsc channel]
Async Runtime (Tokio Engine)
Process Spawner • Log Tailers • Docker Engine API Client
↑↓ [Unix Domain Socket / Stdio Pipes]
DOCKER ENGINE
Containers • Networks • Logs
LOCAL STATE
containers/* • .toml config
Persistence

Selective boot recovery without global overhead

Standard Docker setups rely on global restart: always policies, spawning unused databases and saturating memory after every system reboot. argv-docker-manager uses granular per-project opt-in recovery.

Per-Project Granularity

Opt-In

Pressing a toggles the auto-restart flag for an individual service stack. Only stacks explicitly marked for auto-restart are launched at boot.

Systemd User Unit Integration

Daemon

The included installer generates argv-docker-manager-autorestart.service as a user systemd service. It boots without root privileges, waits for Docker socket availability, and launches your selected stacks in parallel.

Configuration & Unit Specification

.argv-docker-manager-autorestart.toml
[autorestart]
enabled_projects = [
    "mysql",
    "redis"
]
systemd/user/argv-docker-manager-autorestart.service
[Unit]
Description=ARGV Docker Manager Auto-restart Service
After=docker.service docker.socket

[Service]
Type=oneshot
ExecStart=/home/user/.cargo/bin/argv-docker-manager --boot-restore
RemainAfterExit=yes

[Install]
WantedBy=default.target
Decisions

Architectural calls and evaluated alternatives

Every architectural decision recorded with the alternative it explicitly ruled out.

Directory-as-Project Discovery

DEC-01
Chosen Path:Plain compose YAML files in containers/*
Alternative Ruled Out:Central SQLite database or proprietary manifest
Adding a new service is as simple as creating a directory with a standard compose.yaml. Zero lock-in.

Per-Host Ignored State

DEC-02
Chosen Path:Local .argv-docker-manager-autorestart.toml
Alternative Ruled Out:Global Docker daemon container labels
Different development workstations require different active services on boot without dirtying git working trees.

Zero-Dependency Fallback

DEC-03
Chosen Path:fd + fzf + tmux scripted workflow
Alternative Ruled Out:Rust toolchain requirement on all target machines
Allows headless servers and minimal developer environments to manage the same stacks without compiling Rust.

Native Async Engine

DEC-04
Chosen Path:Tokio subprocess piping with channels
Alternative Ruled Out:Synchronous blocking CLI calls
Long-running container starts or log bursts never block the 60fps Ratatui terminal rendering thread.
Specification

Technical specification and bundled services

Ships out of the box with ready-to-run container stacks, backed by minimal system resource footprint.

Included Default Services (containers/*)

adminerPort 8080
Lightweight single-file database management utilityLatest
mailpitPort 8025 / 1025
Local email testing and SMTP capture serverLatest
mysqlPort 3306
MySQL relational engine with persistent local volume mounts8.4 LTS
phpmyadminPort 8081
Web UI database management connected to MySQL networkLatest
postgresPort 5432
PostgreSQL relational engine with health checks configured16.2
redisPort 6379
In-memory data store for caching and pub/sub testing7.2 Alpine

argv-docker-manager / manifest

runtime.languageRust 2024 Edition (Nightly/Stable)
runtime.engineratatui + crossterm
runtime.asynctokio (multi-threaded work-stealing)
container.orchestrationDocker Engine API & Docker Compose v2
system.boot_daemonargv-docker-manager-autorestart.service (systemd user unit)
system.fallback_clifd + fzf + tmux (zero-compile path)
metrics.memory_rss< 12 MB steady state
metrics.startup_time< 4 ms cold start
license.spdxGPL-3.0-only
Status

Battle-tested in daily engineering workflows

Maintained as an active open-source project and used across internal developer workstations every day.

Active Dogfooding

The ARGV engineering team runs all internal database migrations, cache testing, and local microservices through argv-docker-manager, catching real-world edge cases before releases.

Automated Release Lifecycle

Releases follow semantic versioning with conventional commits parsed automatically by git-cliff. Container additions undergo automated CI linting and compose syntax validation.

Project Lifecycle State

Development StageActive / Production Daily
DistributionCargo Crates & GitHub Source
Roadmap TargetRemote SSH Docker Contexts
LicenseGPL-3.0