# Hotify > Use this skill when the user wants to manage web apps behind Traefik with Cloudflare DNS and SSL automation, deploy apps to remote servers, manage Docker containers, or troubleshoot Traefik/DNS issues. - Skill: `javimosch/hotify` (Agent Skill) - Install (CLI): `npx skillmds@latest add javimosch/hotify` - Raw SKILL.md: https://api.skillmd.com/api/skills/javimosch/hotify/raw - Safety review: PASS (external: skill-scanner PASS, skillspector WARNING) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: javimosch (https://skillmd.com/u/javimosch) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/javimosch/hotify --- # hotify Plugin Traefik/Cloudflare app management CLI — deploy web apps behind Traefik with Cloudflare DNS and Let's Encrypt SSL certificates. Also supports Docker container management. ## Current Version: v2.8.1 ### v2.8.1 Features (External Reverse Proxy Support) - **External reverse proxy support**: Apps can now run on external machines while hotify handles DNS, TLS, and Traefik routing - **--backend-url parameter**: Configure custom backend URLs for apps (e.g., http://100.114.4.57:8080) - **Web UI support**: Backend URL field added to add/edit app forms - **Traefik integration**: Automatic routing to custom backend URLs when configured - Use cases: Apps running on different servers via Tailscale/VPN, containerized apps on separate hosts, microservices architectures ### v2.7.4 Features (Permission Enforcement) - **Implemented permission enforcement** at server level - all endpoints now require specific permissions - Added permission checking to auth middleware with 403 Forbidden responses - **Wildcard support** - `all` or `*` grants full access for easier key management - Comprehensive endpoint-to-permission mapping for all API routes - Permission denials logged in audit system for security monitoring - Admin permission automatically grants all permissions - Fine-grained access control for multi-team deployments ### v2.7.3 Features (Remote Execution for App Configuration) - **Remote execution for basic-auth, setup-traefik, setup-dns** — all app configuration commands now support remote execution via HTTP API - Added `--target` and `--local` flags to `basic-auth`, `setup-traefik`, and `setup-dns` commands - New remote API endpoints: `/api/remote/apps/{id}/basic-auth`, `/api/remote/apps/{id}/setup-traefik`, `/api/remote/apps/{id}/setup-dns` - **No-humans mindset**: Always prefer hotify HTTP API over SSH/scp when possible — developers can manage apps remotely without SSH access - Use case: DevOps installs hotify-cli on remote server, developers use hotify-cli locally with configured targets ### v2.7.1 Features (Docker Compose Status Detection) - **Improved status detection for Docker Compose apps** — now checks actual compose stack status instead of cached config - Added `checkComposeStatus()` function to verify Docker Compose stack is running - Local status checks now detect Docker Compose app status via `--local` flag - Config automatically updated when actual status differs from cached status - Fixed `--daemon` flag parsing in `handleCLIAppStart()` — daemon mode now works correctly - Added `--port` flag to `start` command for custom daemon port configuration ### v2.7.0 Features (Full SSH Independence) - **Refactored `traefik-system` to use HTTP API** — all commands now use HTTP API (no SSH required) - Added server-side API endpoints for Traefik installation/management (`/api/traefik-system/status`, `/api/traefik-system/install`, `/api/traefik-system/remove`) - Removed SSH execution from `traefik_system.go` — commands now run on remote server via hotify daemon - **hotify-cli is now fully SSH-independent** — all remote operations use HTTP API ### v2.6.0 Features (Docker Compose Deployment Automation) - `deploy-compose` — Copy full project tree to remote compose_path via HTTP API (replaces manual `scp`) - `compose-sync` — Sync compose file (+ .env) only — faster than full deploy - `compose-copy-dir` — Copy a specific local directory into remote compose_path - `volume-init` — Populate a Docker named volume with local directory content - `setup-compose` — Register app config + deploy project files in one command - All v2.6.0 commands use HTTP API (no SSH required) ### v2.5.0 Features (Docker Compose Support) - `compose` command — passthrough to `docker compose` (all subcommands forwarded verbatim) - `--id` flag resolves `compose_path` and `compose_file` from app config automatically - `--compose-file` and `--compose-path` flags in `setup`/`add`/`edit` - `compose_file` and `compose_path` fields in app config and `list` output - Hotify is responsible only for knowing which compose file to use — Docker config stays in the app repo ### v2.4.0 Features (Docker Support) - Docker container management (list/start/stop/restart/status/logs) - Traefik Docker provider enable/disable - Docker CLI integration via sudo docker commands ### v2.3.0 Features (Traefik Configuration Improvements) - Explicit domain specification in dynamic.yml (fixes ACME "domain not defined" errors) - --challenge-type flag (http/dns selection for ACME) - Smart restart (never uses reload, works even when reload unsupported) - DNS record existence check (skip/update/create based on current state) - Pre-flight config validation before touching Traefik files - New CLI commands: setup-dns, setup-traefik ### v2.1.0 Features (Process Management) - Pause/resume for both local and remote apps - Daemon PID tracking with two-strategy resolver (proc tree + port lookup) - Local mode with --local flag for direct execution ## Commands ### App Management - `hotify setup --id --name --domain --port

--cmd [--compose-file ] [--compose-path

] [--backend-url ]` — Create or update app (upsert) - `hotify add --id --name --domain --port

--cmd [--compose-file ] [--compose-path

] [--backend-url ]` — Strict create (fails if exists) - `hotify remove --id ` — Delete app - `hotify list` — List all apps ### Process Management - `hotify start --id [--local]` — Start app (local or remote) - `hotify stop --id [--local]` — Stop app (local or remote) - `hotify restart --id [--local]` — Restart app (local or remote) - `hotify status --id [--local]` — App status (local or remote) - `hotify pause --id [--local]` — Pause app (SIGSTOP) - `hotify resume --id [--local]` — Resume paused app (SIGCONT) ### Daemon - `hotify start --daemon` — Start hotify daemon (web UI + API) - `hotify stop` — Stop daemon - `hotify status` — Daemon status ### DNS & Traefik Configuration (v2.3.0+) - `hotify setup-dns --id [--ip ] [--target ] [--local]` — Create/update Cloudflare DNS A record - `hotify setup-traefik --id [--challenge-type http|dns] [--target ] [--local]` — Configure Traefik routing ### Basic Auth Management (v2.7.3+) - `hotify basic-auth --id --action [--user ] [--password

] [--hash ] [--target ] [--local]` — Manage Traefik HTTP basic auth ### Docker Compose (v2.5.0+) - `hotify compose [--id ] [args...]` — passthrough to `docker compose` - When `--id` is set, resolves `compose_path` and `compose_file` from app config - All subcommands and flags are forwarded verbatim to `docker compose` ### Docker Compose Deployment Automation (v2.6.0+) - `hotify deploy-compose --id --source

[--compose-file ] [--remote-path

] [--start]` — Copy full project tree to remote - `hotify compose-sync --id [--source

] [--restart] [--env=false]` — Sync compose file (+ .env) only - `hotify compose-copy-dir --id --dir --source ` — Copy a directory into remote compose_path - `hotify volume-init --id --volume --source ` — Populate Docker named volume with local directory - `hotify setup-compose --id --name --domain --port

--cmd --source

[--compose-file ] [--remote-path

] [--setup-dns] [--start]` — Register app + deploy in one command Examples: ```bash # App-aware (resolves path and compose file automatically) hotify-cli compose --id cmdcenter up -d hotify-cli compose --id cmdcenter down hotify-cli compose --id cmdcenter ps hotify-cli compose --id cmdcenter logs -f hotify-cli compose --id cmdcenter restart hotify-cli compose --id cmdcenter pull # Raw passthrough (runs docker compose in current directory) hotify-cli compose -f compose.binary.yml up -d hotify-cli compose ps ``` ### Docker Management (v2.4.0+) - `hotify docker list` — List all containers - `hotify docker start ` — Start container - `hotify docker stop ` — Stop container - `hotify docker restart ` — Restart container - `hotify docker status ` — Container status - `hotify docker logs ` — Container logs - `hotify docker enable-traefik` — Enable Traefik Docker provider - `hotify docker disable-traefik` — Disable Traefik Docker provider ### Deployment - `hotify deploy --id --source [--target ] [--setup-dns]` — Deploy binary/folder - `hotify prune --id ` — Remove DNS/Traefik for app - `hotify prune --all` — Rebuild Traefik for all apps ### Authentication - `hotify auth --url --token --name ` — Authenticate with remote daemon - `hotify targets --action list` — List targets - `hotify targets --action use --name ` — Set active target ### API Key Management (Local Only) - `hotify api-keys --action add --name [--permissions

]` — Create API key with permissions - `hotify api-keys --action list` — List all API keys - `hotify api-keys --action remove --name ` — Remove API key - `hotify api-keys --action permissions --name --add

--remove

` — Update permissions - `hotify api-keys --action usage --name ` — Show API key usage statistics **Available Permissions**: `deploy`, `start`, `stop`, `restart`, `logs`, `config`, `admin`, `all`, `*` **Note**: Permissions are fully enforced at server level as of v2.7.4. Use `all` or `*` for full access. ### Infrastructure - `hotify traefik-system` — Manage Traefik installation on targets ## Setup ```bash # Interactive setup (Cloudflare token, domain, email) hotify-cli init # Or non-interactive hotify-cli init --token --domain example.com --email admin@example.com ``` This creates `~/.hotify/config.json` with Cloudflare API credentials. ## Typical Workflow ```bash # 1. Register an app hotify-cli setup --id myapp --name "My App" --domain myapp --port 3000 --cmd "/usr/local/bin/myapp start" # 2. Setup DNS (checks for existing record) hotify-cli setup-dns --id myapp --ip 92.113.145.178 # 3. Setup Traefik (HTTP challenge by default) hotify-cli setup-traefik --id myapp --challenge-type http # 4. Deploy binary to remote hotify-cli deploy --id myapp --source ./myapp-binary --target dk1 # 5. Start app on remote hotify-cli start --id myapp --target dk1 # 6. Check status hotify-cli status --id myapp --target dk1 ``` ## External Reverse Proxy Workflow (v2.8.1+) The v2.8.1 release adds support for external reverse proxy targets, allowing apps to run on different machines while hotify handles DNS, TLS, and Traefik routing. ### Use Cases - Apps running on different servers via Tailscale/VPN - Containerized apps on separate hosts - Microservices architectures across multiple machines ### Usage Example ```bash # Setup app with external backend URL (e.g., Tailscale network) hotify-cli setup \ --id gitea-rbm2 \ --name "Gitea on rbm2" \ --domain gitea \ --port 3000 \ --cmd "/usr/local/bin/gitea start" \ --backend-url "http://100.114.4.57:3000" # Setup DNS and Traefik (still handled by hotify) hotify-cli setup-dns --id gitea-rbm2 hotify-cli setup-traefik --id gitea-rbm2 ``` When `--backend-url` is set: - Traefik routes to the specified URL instead of `http://127.0.0.1:` - DNS and TLS certificate management still handled by hotify - Basic auth and other Traefik middleware still apply - The app can run on any reachable machine (local network, Tailscale, VPN) ## Docker Compose Workflow (v2.5.0+) ```bash # 1. Register app with compose config (Docker config stays in the app repo) hotify-cli setup \ --id cmdcenter \ --name "Command Center" \ --domain cmdcenter \ --port 3031 \ --cmd "docker compose up -d" \ --compose-file compose.binary.yml \ --compose-path /home/dk1/cmdcenter # 2. Start compose stack (resolves path + file automatically) hotify-cli compose --id cmdcenter up -d # 3. Check status hotify-cli compose --id cmdcenter ps # 4. View logs hotify-cli compose --id cmdcenter logs -f # 5. Restart hotify-cli compose --id cmdcenter restart # 6. Stop hotify-cli compose --id cmdcenter down ``` ## Docker Compose Deployment Workflow (v2.6.0+) The v2.6.0 commands automate the manual `scp` workflow for Docker Compose deployments. All use the HTTP API (no SSH required). ```bash # Full deploy: copy entire project tree (compose file, .env, webui/, templates/, etc.) hotify-cli deploy-compose \ --id cir-doc-gen \ --source /local/path/to/project # Deploy and start immediately hotify-cli deploy-compose --id cir-doc-gen --source ./project --start # Sync only compose file (+ .env) after editing docker-compose.yml hotify-cli compose-sync --id cir-doc-gen --restart # Copy a specific directory (e.g., webui/) hotify-cli compose-copy-dir \ --id cir-doc-gen \ --dir webui \ --source /local/path/webui # Populate a Docker named volume with local content hotify-cli volume-init \ --id cir-doc-gen \ --volume cir-webui \ --source /local/webui # One-shot: register app + deploy + DNS + start hotify-cli setup-compose \ --id cir-doc-gen \ --name "CIR Doc Gen" \ --domain cir-doc-gen \ --port 8080 \ --cmd "docker compose up -d" \ --source /local/project \ --compose-file docker-compose.yml \ --remote-path /home/dk1/cir-doc-gen \ --setup-dns \ --start ``` **What this replaces:** - `deploy-compose` replaces: `scp docker-compose.yml`, `scp .env`, `scp -r webui/`, `scp -r templates/` - `compose-sync` replaces: `scp docker-compose.yml host:/path/` - `compose-copy-dir` replaces: `scp -r webui/ host:/path/webui/` - `volume-init` replaces: `sudo cp -r webui/* /var/lib/docker/volumes/.../` (requires write access on remote) ## Docker Workflow (v2.4.0+) ```bash # List all containers hotify-cli docker list # Check container status hotify-cli docker status --id mycontainer # Start/stop container hotify-cli docker start --id mycontainer hotify-cli docker stop --id mycontainer # Enable Traefik Docker provider (requires Traefik v3.6+) hotify-cli docker enable-traefik ``` ## Architecture - **Local CLI**: All CRUD, authentication, deployment, and Docker commands - **Daemon Mode** (`hotify-cli start -daemon`): HTTP server on port 8080 with embedded web UI + REST API - **Remote Targets**: Manage multiple servers via API with encrypted tokens - **Docker Integration**: Container management via Docker CLI, Traefik Docker provider support - **Transport**: All commands use HTTP API (no SSH required) — hotify-cli is fully SSH-independent as of v2.7.0 ## No-Humans Mindset: Prefer Hotify Over SSH/SCP **Core Principle**: If an operation can be done via hotify's HTTP API, always prefer it over SSH/scp. This enables true remote management without requiring SSH access to servers. ### When to Use Hotify HTTP API (Preferred) - **App configuration**: `setup`, `add`, `edit`, `remove`, `list` - **Process management**: `start`, `stop`, `restart`, `status`, `pause`, `resume` - **DNS & Traefik**: `setup-dns`, `setup-traefik`, `basic-auth` (v2.7.3+) - **Deployment**: `deploy`, `deploy-compose`, `compose-sync`, `compose-copy-dir` - **Docker operations**: `compose`, `docker` commands - **Infrastructure**: `traefik-system` (v2.7.0+) ### When SSH Might Still Be Needed - Initial hotify-cli installation on remote server - System-level troubleshooting outside hotify's scope - Manual file operations not supported by hotify API ### Remote Execution Pattern (v2.7.3+) ```bash # Remote mode (default - uses configured target) hotify-cli basic-auth --id myapp --action list hotify-cli setup-traefik --id myapp hotify-cli setup-dns --id myapp # Explicit target specification hotify-cli basic-auth --id myapp --action list --target dk1 hotify-cli setup-traefik --id myapp --target dk1 # Local mode (execute directly on local server) hotify-cli basic-auth --id myapp --action list --local hotify-cli setup-traefik --id myapp --local ``` ### Benefits of HTTP API Over SSH - **No SSH keys required**: Developers don't need SSH access to infrastructure - **Audit logging**: All operations logged via hotify's audit system - **Consistent interface**: Same commands work locally and remotely - **No tunneling required**: Works through firewalls/NAT without SSH tunnels - **Team collaboration**: Multiple developers can work via shared API tokens ### Important Note: Permission Enforcement (v2.7.4+) **✅ Permission Enforcement Implemented**: As of v2.7.4, hotify-cli enforces permissions at the server level. The auth middleware validates tokens AND checks specific permissions for each endpoint. **Current State**: - Permissions are enforced for all authenticated endpoints - Permission types: `deploy`, `start`, `stop`, `restart`, `logs`, `config`, `admin` - Wildcard support: `all` or `*` grants full access - Admin permission automatically grants all permissions - 403 Forbidden responses for insufficient permissions **Permission Mapping**: - `/api/status` → requires `logs` - `/api/config` → requires `config` - `/api/apps/*/start` → requires `start` - `/api/apps/*/stop` → requires `stop` - `/api/deploy` → requires `deploy` - `/api/api-keys/*` → requires `admin` - And more... (see permissions.go for full mapping) **Wildcard Usage**: ```bash # Create full access key using wildcard hotify-cli api-keys --action add --name fullaccess --permissions all # Alternative wildcard syntax hotify-cli api-keys --action add --name fullaccess --permissions "*" ``` **Recommendation for Agents**: - Use appropriate permission scoping for security - Create keys with minimum required permissions - Use wildcards (`all`/`*`) only for trusted administrative access - Monitor audit logs for permission denials ### Implementation Pattern When working with hotify, follow this decision tree: 1. **Is there a hotify command for this operation?** → Use hotify CLI 2. **Does it support remote execution?** → Use `--target` flag (default) 3. **Only use SSH if**: hotify cannot perform the operation at all ## Key Learnings & Caveats ### Traefik Configuration 1. **ACME "Domain Not Defined" Error (v2.3.0 fix)** - **Issue**: Traefik rejects domain configuration without explicit `domains:` block - **Fix**: Always include `domains: - main: ` in router TLS configuration - **Example**: ```yaml tls: certResolver: letsencrypt domains: - main: app.example.com ``` 2. **ACME Challenge Type Conflicts** - **Issue**: Having both DNS and HTTP challenges in traefik.yml causes conflicts - **Fix**: Use only one challenge type (HTTP is simpler, DNS for wildcards) - **Default**: HTTP challenge (v2.3.0+) 3. **Service Reload Not Supported** - **Issue**: `systemctl reload traefik` fails on some systems - **Fix**: Always use `systemctl restart traefik` (v2.3.0+) - **Implementation**: Detect running state, use start vs restart accordingly 4. **DNS Record Existence Check** - **Issue**: Attempting to create duplicate DNS records fails - **Fix**: Check existing record before creation — skip if IP matches, update if differs (v2.3.0+) - **Benefit**: Idempotent DNS setup ### Docker Compatibility 5. **Docker API Version Mismatch** - **Issue**: Traefik v3.1.4 uses Docker API v1.24, but Docker 29.x requires v1.44+ - **Symptom**: "client version 1.24 is too old. Minimum supported API version is 1.44" - **Fix**: Upgrade Traefik to v3.6+ (v3.7.0 recommended) - **Requirement**: Traefik v3.6+ for Docker 29.x compatibility 6. **Traefik Docker Provider** - **Configuration**: Use `exposedByDefault: false` for security - **Endpoint**: `unix:///var/run/docker.sock` - **Labels**: Required for routing (traefik.enable=true, Host rule, certResolver) - **Example labels**: ```yaml labels: - "traefik.enable=true" - "traefik.http.routers.myapp.rule=Host(\`myapp.example.com\`)" - "traefik.http.routers.myapp.entrypoints=websecure" - "traefik.http.routers.myapp.tls.certresolver=letsencrypt" - "traefik.http.services.myapp.loadbalancer.server.port=8080" ``` ### PID Tracking (v2.1.0+) 7. **Daemon PID Tracking Issue** - **Issue**: When starting app via `sh -c `, tracked shell PID exits immediately for daemon apps - **Fix**: Two-strategy resolver: 1. `/proc` tree walk — finds leaf child of shell (single-fork processes) 2. Port-based lookup via `ss` — finds PID by app's configured port (double-fork/setsid daemons) - **Implementation**: `resolveActualPID(shellPID int, port int)` in local_ops.go 8. **Local vs Remote Operations** - **Local mode**: `--local` flag executes commands directly on server (no API) - **Remote mode**: Uses hotify daemon API on target server - **PID tracking**: Both local and remote use same two-strategy resolver ### File Size Limits 9. **500 LOC Limit** - hotify-cli enforces 500 lines of code per source file - Files exceeding limit must be split (e.g., process.go → local_ops.go + remote_ops.go) - **Rationale**: Maintainability and readability ### Smoke Testing 10. **Smoke Test Approach** - Comprehensive test document for each version - Test server: dk1@92.113.145.178 - Categories: CLI structure, feature-specific, regression, E2E - Document issues found and fixed during testing - All tests must pass before release ### Security & Permissions 11. **Traefik Service File Permissions** - **Issue**: `/etc/systemd/system/traefik.service` owned by root, regular user can't write - **Fix**: Skip service file write if already exists (v2.3.0+) - **Rationale**: Config files in `/etc/traefik/` owned by deploy user, only service file needs root 12. **Cloudflare Token Format** - **Issue**: Legacy API format (X-Auth-Key + X-Auth-Email) vs Bearer token - **Fix**: hotify-cli uses legacy format for broader compatibility - **Note**: Bearer tokens may work but not explicitly tested ### Common Pitfalls 13. **Base Domain Extraction Bug** - **Issue**: `getZoneID` was extracting only TLD (`fr` instead of `intrane.fr`) - **Fix**: Split on all dots, take last 2 parts for registrable domain - **Impact**: DNS setup would fail with "zone not found" error 14. **Configuration Validation** - **Best practice**: Always validate config before touching Traefik files - **Check**: admin_email, domain, app ID, app domain, app port - **Benefit**: Prevents partial/broken state 15. **Watch vs Restart** - **Issue**: Traefik's `watch: true` on file provider doesn't always pick up changes - **Fix**: Always restart Traefik after configuration changes - **Rationale**: Reliable configuration application ## Troubleshooting ### Traefik Errors **"domain not defined" in ACME logs** - Cause: Missing explicit `domains:` block in router TLS configuration - Fix: Use v2.3.0+ setup-traefik (adds domain spec automatically) **"reload is not supported for this unit"** - Cause: systemd service doesn't support reload - Fix: v2.3.0+ uses restart automatically **Docker provider errors** - Check Traefik version (needs v3.6+ for Docker 29.x) - Check Docker API version (`docker version | grep "API version"`) - Verify Docker socket accessible: `ls -la /var/run/docker.sock` ### DNS Errors **"zone not found"** - Check Cloudflare token permissions - Verify domain is managed in Cloudflare - Check base domain extraction (should be 2-part, not just TLD) **"record already exists"** - v2.3.0+ handles this automatically (skip/update/create) - If using older version, manually delete via Cloudflare dashboard ### Process Errors **PID becomes invalid after start** - Daemon app double-forked, shell PID exited - v2.1.0+ uses two-strategy resolver to find actual daemon PID - Check: `hotify-cli status --id --local` ## Version-Specific Notes ### v2.7.4 - Implemented server-side permission enforcement for all API endpoints - Added wildcard support (`all`/`*`) for full access keys - Created comprehensive endpoint-to-permission mapping in permissions.go - Updated auth middleware to check permissions before allowing access - Added 403 Forbidden responses with audit logging for permission denials - Simplified permission management by removing redundant PermissionManager struct - Updated API key creation to expand wildcards to individual permissions ### v2.7.3 - Added remote execution support for `basic-auth`, `setup-traefik`, and `setup-dns` commands - Added `--target` and `--local` flags to app configuration commands - New remote API endpoints: `/api/remote/apps/{id}/basic-auth`, `/api/remote/apps/{id}/setup-traefik`, `/api/remote/apps/{id}/setup-dns` - Fixed route conflicts by using `/api/remote/apps/` path pattern instead of `/api/apps/` - Added `PostWithData` method to HTTPClient for POST requests that return response data - Updated AGENTS.md with remote execution documentation and "no-humans mindset" ### v2.7.0 - Refactored `traefik-system` to use HTTP API instead of SSH - Added server-side API endpoints for Traefik installation/management - hotify-cli is now fully SSH-independent (all commands use HTTP API) - Removed SSH execution code from traefik_system.go ### v2.6.0 - Added Docker Compose Deployment Automation (5 new commands) - All new commands use HTTP API (no SSH required) - Only `traefik-system` still uses SSH (legacy, to be refactored) - Added server-side API endpoint `/api/compose/volume-init` for volume initialization - Added `HTTPClient.PostLarge()` with 5-minute timeout for large uploads ### v2.4.0 - Added Docker container management - Added Traefik Docker provider enable/disable - Requires Traefik v3.6+ for Docker 29.x compatibility - Docker commands use `sudo docker` internally ### v2.3.0 - Fixed ACME domain specification - Added --challenge-type flag - Fixed service reload vs restart - Added DNS existence check - Added config validation - New CLI: setup-dns, setup-traefik ### v2.1.0 - Added pause/resume for apps - Fixed daemon PID tracking (both local and remote) - Added --local flag for direct execution - Split process.go into local_ops.go + remote_ops.go ## Dependencies - **Go**: Pure stdlib, no external dependencies - **Docker**: Required for Docker commands (v2.4.0+) - **Traefik**: Required for reverse proxy (v2.3.0+ requires v3.6+ for Docker 29.x) - **Cloudflare**: DNS provider (requires API token) - **systemd**: Service management (Linux)