This document describes how to build and run the pvetui application using Docker or Podman containers.
Container usage is best for development, testing, and reproducible local environments.
For normal day-to-day usage, prefer native installation from releases, package managers, or go install as documented in the main README.md.
-
Set up environment:
make dev-setup # Edit .env with your Proxmox configuration -
Build and run:
make docker-build make docker-run
-
Set up environment:
make dev-setup # Edit .env with your Proxmox configuration -
Build and run:
make podman-build make podman-run
-
Set up environment:
cp .env.example .env # Edit .env with your Proxmox configuration -
Start application: The
docker compose runcommand is the recommended way to start the TUI application. It handles interactive sessions correctly and cleans up the container on exit when used with--rm.docker compose run --rm pvetui
The application can be configured using environment variables. Copy .env.example to .env and configure:
# Required: Proxmox server details
PVETUI_ADDR=https://your-proxmox-server:8006
PVETUI_USER=root
PVETUI_PASSWORD=your-password
PVETUI_REALM=pam
# Alternative: Use API tokens (recommended for production)
# PVETUI_TOKEN_ID=your-token-id
# PVETUI_TOKEN_SECRET=your-token-secret
# Optional: Application settings
PVETUI_DEBUG=false
PVETUI_CACHE_DIR=/app/cache
PVETUI_API_PATH=/api2/json
PVETUI_INSECURE=false
PVETUI_SSH_USER=rootThe container uses the following volume mount for persistence:
./cache:/app/cache- Application cache data (including logs)
The container is built to match your host user's UID/GID, eliminating permission issues with mounted volumes. The build scripts automatically detect your user ID and create a matching user inside the container.
# Build with default settings
make docker-build
# Build with custom version and registry
VERSION=v1.0.0 REGISTRY=myregistry.com make docker-build
# Build manually
./scripts/docker-build.sh# Build with default settings
make podman-build
# Build with custom version and registry
VERSION=v1.0.0 REGISTRY=myregistry.com make podman-build
# Build manually
./scripts/podman-build.sh# Run with make
make docker-run
# Run manually
./scripts/docker-run.sh
# Run with custom arguments
./scripts/docker-run.sh --debug --config /app/configs/custom.yml# Run with make
make podman-run
# Run manually
./scripts/podman-run.sh
# Run with custom arguments
./scripts/podman-run.sh --debug --config /app/configs/custom.yml# Run the service interactively (recommended)
docker compose run --rm pvetui
# If you need to run in the background (not typical for a TUI):
# docker-compose up -d
# docker-compose attach pvetui
# Stop and remove background containers and networks
docker-compose down
# View logs (if running detached)
docker-compose logs -fSince this is a Terminal User Interface (TUI) application, special considerations are needed:
The container must be run with settings that allocate a pseudo-TTY and keep standard input open. docker compose run handles this automatically for interactive sessions.
The application will adapt to the terminal size of the host. Resize events are properly forwarded to the container.
All keyboard input is forwarded to the containerized application, including special key combinations.
The VNC feature will work in containers by opening VNC consoles in the host's browser, since the container shares the host's network for outbound connections.
The container runs as a user that matches your host user's UID/GID, providing:
- No permission issues with mounted volumes
- Secure non-root execution
- Seamless file ownership
When using Podman on SELinux-enabled systems, volume mounts include the :Z flag for proper labeling.
The container doesn't expose any ports by default. Network access is only needed for outbound connections to the Proxmox server.
-
TLS Certificate Issues:
# Add to .env for testing (not recommended for production) PVETUI_INSECURE=true -
Container Won't Start:
# Check logs docker logs pvetui # or podman logs pvetui
-
Environment Variable Issues: Make sure you're using the correct variable names from
config.go:PVETUI_USER(notPVETUI_USERNAME)PVETUI_DEBUG(notDEBUG)PVETUI_CACHE_DIR(notCACHE_DIR)
Enable debug mode by setting PVETUI_DEBUG=true in your .env file:
PVETUI_DEBUG=trueThis will provide verbose logging to help diagnose issues.
The Docker image includes a health check that verifies the application process is running:
# Check container health
docker ps
# Look for "healthy" status# Build and test
make build
make test
# Build container and run tests
make docker-build
make docker-test# Build for multiple platforms
make release-build
# This creates binaries in dist/ for:
# - Linux (amd64, arm64)
# - macOS (amd64, arm64)
# - Windows (amd64)The provided Dockerfile uses multi-stage builds for optimal image size:
- Builder stage: Uses
golang:1.24.2-alpineto compile the application - Runtime stage: Uses
alpine:latestwith only the compiled binary
The Dockerfile uses build arguments to create a user matching your host user's UID/GID.
Run make help to see all available targets:
make helpKey targets:
docker-build- Build Docker imagedocker-run- Run Docker containerpodman-build- Build Podman imagepodman-run- Run Podman containercompose-up- Start with docker-compose (interactive)compose-build- Build and start with docker-composedev-setup- Set up development environmentclean- Clean build artifacts
Instead of passwords, use Proxmox API tokens:
-
Create an API token in Proxmox:
- Go to Datacenter → Permissions → API Tokens
- Create a new token with appropriate privileges
-
Configure in
.env:PVETUI_TOKEN_ID=your-token-id PVETUI_TOKEN_SECRET=your-token-secret # Remove or comment out PVETUI_PASSWORD
The docker-compose.yml includes resource limits:
deploy:
resources:
limits:
memory: 256M
cpus: '0.5'
reservations:
memory: 64M
cpus: '0.1'Adjust these based on your needs.
Important for TUI Applications:
- ✅ Use:
docker compose run --rm pvetui - ✅ Use:
make docker-runormake podman-run - ❌ Avoid:
docker-compose updirectly, as it can have TTY attachment issues and doesn't clean up the container automatically.
The run command is designed for interactive sessions and is the most reliable way to use the TUI with Docker Compose.