What You'll Build A production-ready Ghost blog running on Hetzner Cloud - configured and deployed with two commands. Ghost 5 with MySQL 8, persistent storage, and a cloud firewall. Ghost 5 (alpine) with MySQL 8 Hetzner Cloud server provisioned automatically Docker and status panel agent installed Persistent volumes for database and content Quick Answer # Install Ghost to Hetzner Cloud stacker install ghost \ --domain blog.example.com \ --key htz-0 \ --provider hetzner \ --region fsn1 \ --size cx23 # Deploy stacker deploy --target cloud --key htz-0 --force-new Ghost is live at http:// :2368 . Prerequisites Stacker CLI installed ( curl -fsSL https://stacker.try.direct/install.sh | bash ) Authenticated: stacker login Hetzner cloud credential saved (verify with stacker list clouds ) Step 1: Install Ghost The stacker install command writes a stacker.yml with Ghost and MySQL pre-configured. All flags are optional except the cloud credential. stacker install ghost \ --domain blog.example.com \ --key htz-0 \ --provider hetzner \ --region fsn1 \ --size cx23 Install Flags Reference --domain - Sets the blog URL (optional, can set later) --key - Saved credential from stacker list clouds (required for cloud) --provider - hetzner , digitalocean , aws , linode , vultr --region - fsn1 , nbg1 , hel1 for Hetzner --size - cx23 (2 vCPU, 4 GB), cx33 (2 vCPU, 8 GB) --set key=value - Override any install input (repeatable) --name - Project name override --file - Custom output path for stacker.yml Step 2: Deploy to Cloud stacker deploy --target cloud --key htz-0 --force-new Stacker provisions the server, installs Docker, transfers the compose file, and starts the containers. The output includes the server IP: Server details: ghost-ae91 (root@203.0.113.42:22) Deploy to an Existing Server stacker deploy --target server Requires deploy.server.host in stacker.yml . Redeploy with Changes stacker deploy --target cloud --key htz-0 --force-rebuild Step 3: Open the Firewall By default, only SSH (22) is open on cloud deploys. Ghost runs on port 2368 - you need to open it explicitly. stacker cloud firewall add --public-ports 2368/tcp This is the most common reason for "app unreachable after deploy" - forgetting to open the port. Step 4: Verify stacker status Shows running containers, ports, and health. Then open http:// :2368 in your browser to complete Ghost setup. Status and Logs stacker list deployments stacker deployment events --deployment stacker agent logs ghost Other Templates Stacker has templates for many apps beyond Ghost: # List all available templates stacker templates --json # Search for a specific app stacker find wordpress --json # Install any template stacker install --domain --key --provider --region --size Clean Up stacker destroy This destroys the cloud server and all associated resources. Troubleshooting "Cloud API credentials are required" The --key flag must match a saved credential name from stacker list clouds . Typos cause this error. Ghost unreachable after deploy Port 2368 is closed by default. Run stacker cloud firewall add --public-ports 2368/tcp to open it. Domain not working --domain sets the install input but doesn't configure DNS or a reverse proxy. Point your domain's A record to the server IP and set up SSL separately. Marketplace marker blocking hooks If stacker.yml contains # @stacker-origin: marketplace , custom hooks are blocked. Remove that line before deploying if you have custom scripts. Frequently Asked Questions How much does it cost to run Ghost on Hetzner? A cx23 server (2 vCPU, 4 GB RAM) costs approximately €5.49/month. More than enough for a Ghost blog. Can I use a different cloud provider? Yes. Stacker supports Hetzner, DigitalOcean, AWS, Linode, and Vultr. Change --provider and --region accordingly. Do I need to install Docker on the server? No. stacker deploy --target cloud installs Docker and all dependencies automatically. Can I deploy Ghost to my own server instead? Yes. Use stacker deploy --target server with deploy.server.host set in stacker.yml . Key Takeaways stacker install ghost generates a complete stacker.yml with Ghost and MySQL Cloud deployment provisions the server, installs Docker, and starts containers Always open the firewall port after cloud deploy ( stacker cloud firewall add ) The same workflow works for any Stacker template - WordPress, Plausible, Nextcloud, etc. Source: github.com/trydirect/stacker

Deploy Ghost CMS to Hetzner Cloud with a single Stacker command. Complete guide covering stacker install, cloud deployment, firewall setup, and troubleshooting.

Deploy Ghost CMS to Hetzner Cloud with One Stacker Command

What You'll Test Deploy Directus and Chatwoot on the same server, create a data pipe between them, and verify that data flows from the headless CMS to the support platform. This is a practical test of Stacker's PIPE system. Directus data change → webhook → PIPE → Chatwoot incoming message Quick Answer # Deploy both apps docker compose -f docker-compose.yml -p project up -d # Scan for endpoints stacker pipe scan --app directus --container project-directus-1 stacker pipe scan --app chatwoot --container project-chatwoot-1 # Create and activate pipe stacker pipe create directus chatwoot stacker pipe activate # Test stacker pipe trigger --data '{"event":"item.created","collection":"posts"}' Use --container flag for reliable endpoint discovery. Step 1: Deploy Both Apps Deploy Directus and Chatwoot with a combined compose file: docker compose -f docker-compose.yml -p project up -d This creates all necessary containers on the same Docker network. Step 2: Scan for Endpoints Use the --container flag for reliable discovery. The default remote_app scope returns empty for most apps. stacker pipe scan --app directus --container project-directus-1 stacker pipe scan --app chatwoot --container project-chatwoot-1 Note: Directus uses non-standard API paths ( /items/* ), so the probe may not find endpoints automatically. Use manual endpoints as a fallback. Step 3: Create the Pipe stacker pipe create directus chatwoot If the interactive prompt fails, use the --name flag: stacker pipe create directus chatwoot --name "directus-chatwoot" For apps with non-standard paths, specify endpoints manually: stacker pipe create directus chatwoot \ --source-endpoint "POST /items" \ --target-endpoint "POST /api/v1/conversations" \ --source-fields "name,email,message" \ --target-fields "content" \ --name "directus-chatwoot" Step 4: Activate the Pipe stacker pipe activate Step 5: Test the Pipe stacker pipe trigger --data '{"event":"item.created","collection":"posts"}' Check the execution log: stacker pipe history Known Issues remote_app Scope Returns Empty The agent doesn't pass resolved containers to the probe when using remote_app scope. Use --container flag to force direct_container scope. Agent Must Be on Same Docker Network The status-panel agent and project containers are on different Docker networks by default. Bridge them: docker network connect project_app-network statuspanel_agent CLI Auth Token Expires Run stacker login before pipe commands if you get authentication errors. Container Name Mismatch Stacker generates the main app service as app , producing containers named project-app-1 . If your app code doesn't match, rename the compose service: sed -i 's/^ app:/ directus:/' .stacker/docker-compose.yml Troubleshooting Commands # Check agent status stacker agent status # View agent logs docker logs statuspanel_agent | grep -i 'probe\|match\|resolve' # Check container labels docker inspect --format '{{range $k,$v := .Config.Labels}}{{$k}}={{$v}}{{"\n"}}{{end}}' # Verify network connectivity docker exec statuspanel_agent curl -s http://project-directus-1:8055/items Frequently Asked Questions Can I test pipes without the agent? No. The agent executes pipe commands. Without it, stacker pipe trigger hangs and times out. Why does endpoint discovery fail for Directus? Directus uses /items/* instead of standard /api/* paths. The agent's probe only checks standard paths. Use manual endpoints. How do I verify the pipe is working? Check stacker pipe history for execution results. A successful trigger shows status: completed with the target response. What data format does the pipe expect? JSON. Pass data with --data '{"key":"value"}' . The pipe maps source fields to target fields based on the pipe configuration. Key Takeaways Use --container flag for reliable endpoint discovery Manual endpoints work when discovery fails Agent must be on the same Docker network as project containers Run stacker login before pipe commands Check stacker pipe history for execution results

Test a Directus to Chatwoot data pipe with Stacker. Deploy both apps, scan for endpoints, create the pipe, and trigger data flow between your headless CMS and support platform.

Testing a Directus to Chatwoot Pipe with Stacker - Step-by-Step

What We Tested We deployed Directus, Chatwoot, Stirling-PDF, and WordPress on the same server and ran stacker pipe scan and stacker pipe create to test endpoint discovery. Here's what the agent finds - and what it misses. Quick Answer Works: HTML forms on pages, REST APIs at standard /api paths, OpenAPI specs at /api/docs . Doesn't work: Directus at /items/* , Chatwoot at /api/v1/* , Stirling-PDF internal API, Hanko at /v1/* . Workaround: Use manual endpoint specification with --source-endpoint and --target-endpoint . What the Agent Discovers The agent's probe scans for three types of endpoints: OpenAPI/Swagger specs - at standard paths like /api/docs , /swagger.json , /openapi.json HTML forms - on the root page of web applications REST API patterns - at standard paths like /api , /api/v1 , /api/v2 Results by Application WordPress (Contact Form 7) - Discovered The agent successfully finds HTML forms on WordPress pages: { "forms": [{ "action": "/contact#wpcf7-f5-p6-o1", "fields": ["your-name", "your-email", "your-subject", "your-message"] }] } WordPress exposes forms directly on its pages, which the agent's HTML probe detects. This is the most reliable discovery path. Directus - Not Discovered Directus exposes its REST API at /items/* and GraphQL at /graphql . Neither path matches the agent's standard patterns. The probe returns empty. Workaround: Use manual endpoints: stacker pipe create directus chatwoot \ --source-endpoint "POST /items" \ --target-endpoint "POST /api/v1/conversations" Chatwoot - Not Discovered Chatwoot's REST API lives at /api/v1/* . The agent checks /api and /api/v2 but not /api/v1 . Returns empty. Workaround: Specify endpoints manually. Stirling-PDF - Not Discovered Stirling-PDF's internal API uses non-standard paths. The probe finds nothing. Hanko - Not Discovered Hanko's REST API at /v1/* doesn't match any standard pattern. Container Resolution - Works The agent correctly resolves container names via my.stacker.service labels: Container name resolved via compose service label app_code="project-directus-1" resolved_name="project-directus-1" Network Connectivity - Works After connecting the agent to the project network ( docker network connect ), the agent can reach containers on their internal IPs. Why Some Apps Aren't Found The agent probe checks a fixed set of paths: /api/docs , /swagger.json , /openapi.json - OpenAPI specs /api , /api/v1 , /api/v2 - REST patterns Root page - HTML forms Apps that use non-standard paths (Directus at /items/* , Chatwoot at /api/v1/* ) are invisible to the probe. The probe doesn't follow redirects or check app-specific paths. Workarounds Option 1: Use Apps with Standard API Patterns Apps that expose OpenAPI specs or REST APIs at /api/* paths are discovered automatically. WordPress with Contact Form 7 is the most reliable for form discovery. Option 2: Manual Endpoint Specification Bypass discovery entirely with explicit endpoints: stacker pipe create \ --source-endpoint "METHOD /path" \ --target-endpoint "METHOD /path" \ --source-fields field1,field2 \ --target-fields field1,field2 \ --name "my-pipe" Option 3: Use --container Flag The direct_container probe scope finds more endpoints than remote_app : stacker pipe scan --app --container --protocols html_forms Next Steps for Stacker Enhance agent probe to check more paths (including app-specific ones) Allow manual endpoint specification in stacker pipe create (already available) Use app documentation to pre-populate endpoint discovery Support OpenAPI spec URLs as input to the probe Frequently Asked Questions Why doesn't the agent find Directus endpoints? Directus uses /items/* instead of the standard /api/* path. The agent's probe only checks standard paths. Use manual endpoint specification as a workaround. Can I improve endpoint discovery? Use the --container flag with stacker pipe scan to force direct container probing. This finds more endpoints than the default remote_app scope. Will Stacker add support for non-standard API paths? The manual endpoint feature already covers this. Future updates may add app-specific probe patterns or allow custom OpenAPI spec URLs. What's the most reliable way to create pipes? Use manual endpoints. They work regardless of whether the app is running, what API paths it uses, or which Docker network the agent is on. Key Takeaways Endpoint discovery works for apps with standard /api/* paths and HTML forms Non-standard paths (Directus, Chatwoot, Hanko) require manual endpoints Container resolution and network connectivity work correctly Manual endpoint specification is the most reliable approach The --container flag finds more endpoints than the default probe scope

Results from testing Stacker PIPE endpoint discovery across Directus, Chatwoot, WordPress, and Stirling-PDF. What works, what doesn

Stacker PIPE Endpoint Discovery - What Works and What Doesn't

What This Covers A technical walkthrough of getting Stacker's PIPE system working end-to-end: creating pipes, activating them on remote agents, and triggering execution between containers on a live server. We hit every wall possible - Docker networking, agent modes, deployment hashes - and documented the fixes. Quick Answer # The working PIPE flow (4 commands): stacker pipe create directus chatwoot --source-endpoint "POST /items" --name "directus-chatwoot" stacker pipe activate --server --pipe stacker pipe scan directus --server stacker pipe trigger directus --server --pipe "directus-chatwoot" If pipes hang or timeout, check: Docker network isolation, agent daemon mode, and deployment hash validity. The Stack Directus - headless CMS, source of data Chatwoot - customer support platform, target for data Stacker - deployment platform orchestrating both The promise: a single stacker pipe trigger command fetches data from Directus and pushes it to Chatwoot. In practice, getting there took four days of debugging across three servers, two Docker networks, and an orphaned AMQP consumer. Day 1: Creating the Pipe The stacker pipe create command needed a --name flag. Previously, it always prompted interactively, which broke CI and scripting workflows. stacker pipe create directus chatwoot \ --source-endpoint "POST /items" \ --target-endpoint "POST /api/v1/conversations" \ --source-fields "name,email,message" \ --target-fields "content" \ --name "directus-chatwoot" This created the pipe template locally. Remote activation worked on the first try - the pipe instance was registered with the Stacker API and linked to the deployment. Takeaway: The pipe creation flow (CLI → API → database) is solid. The bottleneck was always the execution side. Day 2: The Agent Mystery With the pipe created, we tried stacker pipe trigger . It hung for 30 seconds, then timed out. No error, no output. The command was reaching the server, but nothing was executing. Daemon Mode vs. Web Server The Dockerfile's default entrypoint starts a web server. But for pipe execution, the agent needs to run as a daemon - a long-polling background process that pulls commands from the Stacker API and executes them locally. # The default entrypoint (web server mode): ENTRYPOINT ["/usr/local/bin/status", "serve", "--with-ui"] # What we needed (daemon mode): docker run -d \ --name statuspanel_agent \ --entrypoint /usr/local/bin/status \ -c /app/config.json \ ... The Deployment Hash Problem Even with the correct mode, the agent returned 403 errors. Every deployment in Stacker gets a unique hash ( deployment_ ), and the agent authenticates using this hash. After redeploying, the old hash was invalid. # Find current deployment hash curl -s "https://stacker.try.direct/api/v1/project/330/deployments" \ -H "Authorization: Bearer $TOKEN" | jq '.[0].deployment_hash' # → "deployment_abc12345-6789-0def-ghij-klmnopqrstuv" Lesson: Every time you redeploy, check if the agent's deployment hash is still valid. Day 3: Network Isolation With the agent registered and polling, pipe scan worked - it found the Directus container. But pipe trigger still timed out. Two Networks, One Problem The target server had two Docker networks: project_app-network - Bridge network for project containers (Directus, Chatwoot) default_network - External network for the status panel agent Docker bridge networks are isolated by default. Containers on different networks cannot reach each other by IP. The agent could resolve container names but couldn't actually connect to them. # Fix: connect the agent to the project network docker network connect project_app-network statuspanel_agent Day 4: The Execution With networking and naming fixed, pipe trigger finally executed. The agent received the command, parsed it, and attempted to run: failed to fetch trigger_pipe source: source container request failed with code 127: /bin/sh: curl: not found The Directus container doesn't have curl installed. The agent tries to fetch source data by running curl inside the target container via docker exec . The important thing: the mechanism works. The command was received, executed, and reported back. The failure is at the application level (missing curl), not the infrastructure level. What We Discovered: Two Parallel Architectures While debugging, we found agent-executor - a standalone Rust binary that connects to RabbitMQ and listens for StepCommand messages. We built it, deployed it, and watched it crash repeatedly. Here's the thing: no code in Stacker ever publishes StepCommand to RabbitMQ . Stacker has two execution paths that were never connected: HTTP long-polling (statuspanel_agent) - Working. Used by stacker pipe trigger and pipe scan AMQP (agent-executor) - Orphaned, never wired up. The infrastructure exists but no publisher was ever implemented The Complete Working Flow Create pipe (CLI) - Creates pipe template and instance in Stacker database Activate pipe (CLI) - Enqueues activation command to agent Scan endpoints (CLI) - Agent runs probe on target container, returns available endpoints Trigger execution (CLI) - Agent receives command via long-poll, executes inside source container, pushes data to target, reports result back Lessons Learned 1. Docker Networking Is the #1 Gotcha Every cross-container communication issue was network-related. The agent must be on the same Docker network as the containers it manages. This is not obvious from the documentation. 2. Deployment Hashes Are Ephemeral Every deploy creates a new hash. If the agent is registered with an old hash, all commands fail with 403. After any deploy, re-register the agent. 3. Daemon Mode Is Not the Default The Dockerfile entrypoint starts a web server. For pipe execution, you need the daemon. This is a configuration detail that's easy to miss. 4. AMQP Was Designed but Never Connected The agent-executor binary and RabbitMQ integration exist in the codebase, but no code publishes to the pipe_execution exchange. The HTTP long-polling path is the only one that works. Frequently Asked Questions Why does stacker pipe trigger hang and timeout? The most common cause is Docker network isolation. The agent must be on the same bridge network as the project containers. Run docker network connect project_app-network statuspanel_agent to fix it. What is the difference between daemon mode and web server mode? Web server mode ( serve --with-ui ) hosts the status panel dashboard. Daemon mode polls the Stacker API for commands and executes them locally. Pipes require daemon mode. Do I need to re-register the agent after every deploy? Yes. Each deployment creates a new hash. The agent authenticates with the hash it was registered with. If the hash changes, the agent returns 403. Why doesn't curl work inside containers? Many minimal Docker images (like Directus) don't include curl. The pipe executor currently assumes curl is available. A future update will use an alternative HTTP client. What's Next Install curl in target containers or modify the pipe executor to use a different HTTP client Wire up the AMQP path for event-driven pipe execution Auto-register agents with current deployment hashes after redeploy Key Takeaways Stacker's PIPE architecture is sound - the gaps are in networking and configuration Docker network isolation is the most common blocker for cross-container pipes Agent must run in daemon mode, not web server mode Deployment hashes are ephemeral - re-register after every deploy The HTTP long-polling path works end-to-end; AMQP is unused infrastructure

Stacker PIPE Execution Deep Dive - Debugging Cross-Container Data Pipelines

What You'll Build When a visitor submits a contact form on WordPress, send a custom event to Matomo analytics - all running on the same server. No third-party services, no custom code, just Stacker PIPEs. WordPress form → Stacker PIPE → Matomo tracking event Quick Answer # Deploy both apps stacker deploy --target cloud --force-rebuild # Fix container naming (required workaround) sed -i 's/^ app:/ wordpress-matomo:/' .stacker/docker-compose.yml # Bridge Docker networks docker network connect project_app-network statuspanel_agent # Scan and create pipe stacker pipe scan --app wordpress-matomo --container project-wordpress-matomo-1 stacker pipe create wordpress-matomo matomo Three workarounds needed - but the pipe works end-to-end. Step 1: Deploy Both Apps We created a combined project wordpress-matomo with four containers in a single stacker.yml : wordpress-matomo - WordPress with Contact Form 7 wp-db - MySQL 8.0 for WordPress matomo - Matomo analytics matomo-db - MariaDB 11 for Matomo stacker deploy --target cloud --force-rebuild One deploy put everything on a Hetzner cloud server. Worked flawlessly on the first try. Step 2: Set Up the Form Install Contact Form 7 on WordPress and create a form with name, email, and message fields. We also added a plain HTML form on the homepage to ensure the agent could detect it. # Verify the form is serving curl -s http:// :8080/ | grep ' Confirmed: one element with action /wp-json/demo/v1/submit . Step 3: The Agent Scan - First Wall stacker pipe scan --app wordpress-matomo # Result: empty. No endpoints, no forms, no protocols detected. The agent connected to the container but returned nothing. The container was running, the form was serving, but the agent couldn't find it. The Problem: Container Name Mismatch The agent resolves containers by name , not by the my.stacker.service label. Stacker generates the main app compose service with the hardcoded name app , producing containers named project-app-1 . The agent's app code is wordpress-matomo but the container name doesn't match. # Agent log shows the mismatch: WARN No matching container found. Attempted patterns: exact match, prefix, suffix, contains app_code="wordpress-matomo" available_containers=["project-app-1", "project-matomo-1", ...] The Fix: Rename the Compose Service sed -i 's/^ app:/ wordpress-matomo:/' .stacker/docker-compose.yml sed -i 's/my.stacker.service: "app"/my.stacker.service: "wordpress-matomo"/' .stacker/docker-compose.yml After redeploy, the agent resolves correctly: INFO Container name resolved via compose service label app_code="wordpress-matomo" resolved_name="project-wordpress-matomo-1" Step 4: Network Isolation - Second Wall Even with the container name resolved, the probe returned empty. The agent could see the container but couldn't reach it. # Check agent networks docker inspect statuspanel_agent | jq '.[].NetworkSettings.Networks | keys' # Result: agent on "default_network", project on "project_app-network" Docker bridge networks are isolated by default. Containers on different networks can't communicate directly. The agent resolves the name but can't open a TCP connection. # Fix: bridge the networks docker network connect project_app-network statuspanel_agent After this, the scan returns real data: { "forms": [{ "action": "/contact#wpcf7-f5-p6-o1", "fields": ["your-name", "your-email", "your-subject", "your-message"] }] } Step 5: Probe Scope - Third Wall Even with the network connected, the remote_app probe scope (used by stacker pipe create ) returns empty. The direct_container scope (used by --container ) finds everything. remote_app ( --app ) - probes the app's published host port. Returns empty. direct_container ( --app --container ) - connects directly to the container's internal IP. Finds forms and endpoints. # Use direct_container scope for reliable discovery stacker pipe scan --app wordpress-matomo --container project-wordpress-matomo-1 --protocols html_forms Key Findings Container Matching The agent matches app codes to container names using string patterns (exact/prefix/suffix/contains). Renaming the compose service from app to the project name fixes the match, but this is a workaround. The root fix belongs in Stacker's compose generator. Network Injection The status-panel agent runs on an external network. Project containers run on a compose-scoped bridge. They can't communicate unless manually bridged. Stacker already has inject_external_network() for NPM proxy mode - it needs to be enabled for status-panel mode too. Probe Scope Gap remote_app and direct_container probes behave differently. The pipe create wizard uses remote_app which doesn't find forms that direct_container does. Commands Cheat Sheet # Check agent sees containers stacker agent status # Scan with direct container probe (works) stacker pipe scan --app --container --protocols html_forms # Check agent logs on server docker logs statuspanel_agent | grep -i 'probe\|match\|resolve' # Check which networks the agent is on docker inspect statuspanel_agent --format '{{range $k,$_ := .NetworkSettings.Networks}}{{$k}} {{end}}' # Bridge the networks docker network connect project_app-network statuspanel_agent # Rename compose service (workaround) sed -i 's/^ app:/ :/' .stacker/docker-compose.yml sed -i 's/my.stacker.service: "app"/my.stacker.service: " "/' .stacker/docker-compose.yml Frequently Asked Questions Why does stacker pipe scan return empty results? Three common causes: (1) container name mismatch - rename the compose service to match the app code, (2) Docker network isolation - connect the agent to the project network, (3) wrong probe scope - use --container flag for direct container probing. Do I need to bridge Docker networks every time? The docker network connect command is ephemeral - it's lost on agent restart. For a persistent fix, add default_network as an external network in your compose file. Can I use this pattern for other WordPress integrations? Yes. The same approach works for any WordPress form plugin - Contact Form 7, WPForms, Gravity Forms. The pipe captures form submissions and delivers them to any HTTP endpoint. What's the permanent fix for container name matching? Stacker needs to inject the project name into the compose service name during generation, instead of hardcoding app . This is a one-line change in Stacker's compose generator. Key Takeaways WordPress + Matomo deploy in one command with Stacker Three workarounds needed: compose service rename, network bridging, direct container probe Docker network isolation is the most common blocker for cross-container pipes The --container flag forces direct container probing which finds forms reliably The PIPE architecture is sound - the gaps are in configuration, not code

Build a WordPress to Matomo analytics pipe with Stacker. Complete walkthrough covering deployment, Contact Form 7 integration, Docker networking fixes, and agent probe troubleshooting.

WordPress to Matomo Pipe with Stacker - Form Submissions to Analytics Events

What You'll Learn A workflow for testing any GitHub project in 2 minutes - no Docker Compose, no manual setup, no debugging. Just clone and run. Deploy any project with 2 commands Automatic project detection and Docker config Healthchecks and .env templates included Works with Python, Node, Go, Rust, PHP projects The Problem You find an interesting GitHub project. You want to test it. Here's what usually happens: Clone the repo Read the README for 20 minutes Realize the Docker setup is incomplete or outdated Write a Dockerfile Write docker-compose.yml Add healthchecks manually Set up .env with the right variables Debug for an hour Total time: 1-3 hours. Often you give up. The Solution stacker init --from-github owner/repo --with-ai --force stacker deploy --target local That's it. Stacker handles everything else. How It Works 1. Stacker clones the repo stacker init --from-github https://github.com/plausible/analytics --force 2. It detects the project type Stacker reads the repo and figures out: Language (Python, Node, Go, Rust, PHP) Framework (Flask, Express, Gin, Actix) Services (PostgreSQL, Redis, Elasticsearch, etc.) Port mappings from docker-compose.yml or source 3. It generates the Docker config # What gets created: stacker.yml # Deployment config .stacker/Dockerfile # Optimized for the project .stacker/docker-compose.yml # Production-ready .env.example # All env vars with placeholders scripts/generate-secrets.sh # Auto-generates passwords 4. You deploy cp .env.example .env ./scripts/generate-secrets.sh stacker deploy --target local Real Examples Test a password manager mkdir ~/vaultwarden && cd ~/vaultwarden stacker init --from-github dani-garcia/vaultwarden --with-ai --force cp .env.example .env && ./scripts/generate-secrets.sh stacker deploy --target local # Running at http://localhost:8080 Test a wiki mkdir ~/wiki && cd ~/wiki stacker init --from-github Requarks/wiki --with-ai --force cp .env.example .env && ./scripts/generate-secrets.sh stacker deploy --target local # Running at http://localhost:3000 Test a code editor mkdir ~/editor && cd ~/editor stacker init --from-github coder/code-server --with-ai --force cp .env.example .env && ./scripts/generate-secrets.sh stacker deploy --target local # Running at http://localhost:8080 Test a file manager mkdir ~/files && cd ~/files stacker init --from-github filebrowser/filebrowser --with-ai --force cp .env.example .env && ./scripts/generate-secrets.sh stacker deploy --target local # Running at http://localhost:8080 What If Detection Fails? If Stacker can't auto-detect the project, it falls back to asking you or using the project's existing Dockerfile. You can also use AI to help: stacker init --from-github owner/repo --with-ai --force # AI reads the README and source code to figure out the stack Customizing After Deployment Edit stacker.yml to change ports, add services, or configure networking: # Change the port app: ports: - "8081:8080" # Add a database services: - name: postgres image: postgres:16-alpine environment: POSTGRES_DB: myapp POSTGRES_PASSWORD: "${DB_PASSWORD}" volumes: - pg_data:/var/lib/postgresql/data # Add a reverse proxy proxy: type: nginx auto_detect: true domains: - domain: myapp.local ssl: off upstream: app:8080 Cleaning Up # Stop everything stacker destroy --target local # Remove all generated files rm -rf .stacker stacker.yml .env .env.example scripts/ The Full Workflow # 1. Find a project # 2. Test it in 2 minutes mkdir ~/project && cd ~/project stacker init --from-github owner/repo --with-ai --force cp .env.example .env && ./scripts/generate-secrets.sh stacker deploy --target local # 3. Like it? Deploy to a server stacker config setup server stacker deploy --target server # 4. Done. Two commands from GitHub to production. Key Takeaways Any GitHub project can be tested in 2 minutes Stacker handles detection, Docker config, healthchecks, and secrets Works with Python, Node, Go, Rust, PHP, and more The same config works on local, server, or cloud Source: github.com/trydirect/stacker

Test any GitHub project in 2 minutes - no Docker Compose, no manual setup. Just clone and run.

The Fastest Way to Test Any GitHub Project Locally

What You'll Build Five real self-hosted apps running on your machine - each deployed with two commands. Total time: under 10 minutes. Plausible - web analytics (Google Analytics alternative) Vaultwarden - password manager (Bitwarden compatible) Outline - team wiki and note-taking Code Server - VS Code in your browser Filebrowser - web-based file manager Quick Answer # For any of these apps: mkdir ~/app-name && cd ~/app-name stacker init --from-github owner/repo --with-ai --force cp .env.example .env && ./scripts/generate-secrets.sh stacker deploy --target local Same pattern. Different repo. 2 minutes each. Prerequisites Docker ( docker --version ) Stacker ( stacker --version ) curl -fsSL https://raw.githubusercontent.com/trydirect/stacker/main/install.sh | bash 1. Plausible Analytics (2 min) Privacy-first web analytics. No cookies, no personal data collection. mkdir ~/plausible && cd ~/plausible stacker init --from-github plausible/analytics --with-ai --force cp .env.example .env ./scripts/generate-secrets.sh # Edit .env - set your domain: # PLAUSIBLE_BASE_URL=http://localhost:8000 stacker deploy --target local # Dashboard: http://localhost:8000 Stacker handles: ClickHouse database, PostgreSQL, the Plausible API, and the tracker script endpoint. 2. Vaultwarden (2 min) Lightweight Bitwarden-compatible password manager. Self-host, sync across devices. mkdir ~/vaultwarden && cd ~/vaultwarden stacker init --from-github dani-garcia/vaultwarden --with-ai --force cp .env.example .env ./scripts/generate-secrets.sh stacker deploy --target local # Web UI: http://localhost:8080 Create an admin account, then use the Bitwarden mobile app with your self-hosted URL. 3. Outline Wiki (3 min) Fast, collaborative team wiki. Notion alternative, open source. mkdir ~/outline && cd ~/outline stacker init --from-github outline/outline --with-ai --force cp .env.example .env ./scripts/generate-secrets.sh # Outline needs an OIDC provider - edit .env: # OIDC_CLIENT_ID=your-id # OIDC_CLIENT_SECRET=your-secret # OIDC_AUTH_URI=http://localhost:3000 stacker deploy --target local # Wiki: http://localhost:3000 Outline requires an authentication provider (Google, Slack, or OIDC). The .env.example lists all required variables. 4. Code Server (1 min) VS Code running in your browser. Access your dev environment from anywhere. mkdir ~/code-server && cd ~/code-server stacker init --from-github coder/code-server --with-ai --force cp .env.example .env ./scripts/generate-secrets.sh # Set your password in .env: # PASSWORD=your-secure-password stacker deploy --target local # IDE: http://localhost:8080 5. Filebrowser (1 min) Web-based file manager. Browse, edit, and share files from your browser. mkdir ~/filebrowser && cd ~/filebrowser stacker init --from-github filebrowser/filebrowser --with-ai --force cp .env.example .env ./scripts/generate-secrets.sh stacker deploy --target local # File manager: http://localhost:8080 Running Everything Together All five apps can run simultaneously on different ports: stacker status # plausible running :8000 # vaultwarden running :8080 # outline running :3000 # code-server running :8443 # filebrowser running :8500 Customizing Ports If a port conflicts, edit stacker.yml : # Example: move Vaultwarden to port 8081 app: ports: - "8081:8080" Deploying to a Server Once everything works locally, push to a server: stacker config setup server stacker deploy --target server Or deploy to cloud: stacker config setup cloud stacker deploy --target cloud What Each App Needs App Services Port Setup Notes Plausible ClickHouse, PostgreSQL 8000 Set PLAUSIBLE_BASE_URL in .env Vaultwarden None (single container) 8080 Just set PASSWORD Outline PostgreSQL, Redis, S3 3000 Needs OIDC provider Code Server None (single container) 8080 Set PASSWORD Filebrowser None (single container) 8080 Zero config Key Takeaways Same pattern for every app: init, configure, deploy Stacker handles Docker complexity automatically Healthchecks, port isolation, and secret generation are built in Works identically on local, server, or cloud Source: github.com/trydirect/stacker

Deploy 5 useful self-hosted apps in 10 minutes with Stacker - analytics, password manager, note-taking, code editor, and file sharing.

Deploy 5 Useful Self-Hosted Apps in 10 Minutes

What You'll Build A self-hosted Umami analytics dashboard with PostgreSQL - running on your machine in under 5 minutes. No Google Analytics, no data leaves your server. Umami dashboard (Node.js) PostgreSQL database with healthchecks Persistent volumes for data .env template with auto-generated secrets Quick Answer mkdir ~/umami && cd ~/umami stacker init --from-github umami-software/umami --with-ai --force cp .env.example .env && ./scripts/generate-secrets.sh stacker deploy --target local Dashboard at http://localhost:3000 . Default login: admin / umami. Prerequisites Docker ( docker --version ) Git ( git --version ) Stacker ( stacker --version ) Step 1: Install Stacker curl -fsSL https://raw.githubusercontent.com/trydirect/stacker/main/install.sh | bash stacker --version # stacker 0.3.0 Step 2: Generate Configuration mkdir ~/umami && cd ~/umami stacker init --from-github umami-software/umami --with-ai --force Stacker clones Umami, reads the docker-compose.yml, and generates: stacker.yml # Deployment config .stacker/Dockerfile # Optimized Node.js build .stacker/docker-compose.yml # Production compose file .env.example # All env vars with placeholders scripts/generate-secrets.sh # Fills in passwords Step 3: Configure Secrets cp .env.example .env ./scripts/generate-secrets.sh # Generates: DB_PASSWORD, DATABASE_URL, HASH_SALT Optional - edit .env to set your timezone or tracking domain: TZ=UTC TRACKER_SCRIPT_NAME=tracker.js Step 4: Deploy stacker config validate # ✓ Configuration is valid stacker deploy --target local # Building app... # Creating postgres... # ✓ Stack deployed successfully Step 5: Verify and Use stacker status # umami running # postgres running open http://localhost:3000 Login with admin / umami . Change the password immediately. Understanding the Generated Config The stacker.yml that Stacker generated: name: umami app: type: node ports: - "3000:3000" environment: DATABASE_URL: "postgresql://umami:${DB_PASSWORD}@postgres:5432/umami" NEXT_AUTH_URL: "http://localhost:3000" NEXT_AUTH_SECRET: "${HASH_SALT}" services: - name: postgres image: postgres:16-alpine ports: - "127.0.0.1:5432:5432" environment: POSTGRES_DB: umami POSTGRES_USER: umami POSTGRES_PASSWORD: "${DB_PASSWORD}" volumes: - postgres_data:/var/lib/postgresql/data healthcheck: test: "CMD pg_isready -U umami" interval: 5s timeout: 2s retries: 10 volumes: postgres_data: {} What Stacker got right automatically: Node.js detected from package.json PostgreSQL service extracted from compose file Healthcheck - pg_isready added for database Port isolation - PostgreSQL on 127.0.0.1 only Named volume - data persists across restarts Secrets - no hardcoded passwords Customizing Add a reverse proxy with SSL # Add to stacker.yml: proxy: type: nginx auto_detect: true domains: - domain: analytics.yourdomain.com ssl: auto upstream: app:3000 stacker deploy --target local Deploy to a remote server stacker config setup server # Enter: host, user, SSH key stacker deploy --target server Deploy to cloud stacker config setup cloud # Choose: hetzner, digitalocean, aws, linode, vultr stacker deploy --target cloud Adding Your Website to Umami Once Umami is running: Open http://localhost:3000 Login → Settings → Websites → Add Website Enter your domain and name Copy the tracking script into your HTML: Troubleshooting Port 3000 already in use # Edit stacker.yml: app: ports: - "3001:3000" stacker deploy --target local Database connection refused # Check PostgreSQL is healthy: stacker status # Check logs: stacker logs postgres Want to reset everything stacker destroy --target local rm -rf .stacker stacker.yml .env .env.example Key Takeaways Umami deploys in 5 minutes with 4 commands Stacker handles the entire Docker stack automatically Healthchecks, port isolation, and secret generation are built in The same config works on local, server, or cloud Source: github.com/trydirect/stacker

Deploy Umami analytics in 5 minutes with Stacker - self-hosted, privacy-first alternative to Google Analytics.

Deploy Self-Hosted Analytics in 5 Minutes - Umami + Stacker

What You'll Build In this tutorial, you'll deploy three real open-source projects using Stacker - no Docker expertise needed. By the end, you'll have: A self-hosted analytics dashboard (Umami) A privacy-focused web archiver (ArchiveBox) An AWS-compatible local cloud emulator (Floci) Each deployment takes two commands. Total time: under 5 minutes. Quick Answer The Stacker deployment pattern for any GitHub repo: stacker init --from-github owner/repo --with-ai --force stacker deploy --target local That's it. Stacker handles project detection, Docker configuration, service setup, healthchecks, env vars, and secrets generation. Prerequisites Docker installed ( docker --version ) Git installed ( git --version ) Optional: Ollama running locally for AI-assisted config ( ollama serve ) Step 1: Install Stacker curl -fsSL https://raw.githubusercontent.com/trydirect/stacker/main/install.sh | bash stacker --version # Should print: stacker 0.3.0 Step 2: Deploy Umami Analytics Umami is a privacy-first, open-source alternative to Google Analytics. It uses PostgreSQL for data storage and runs on Node.js. 2.1 Generate the configuration mkdir ~/umami && cd ~/umami stacker init --from-github umami-software/umami --with-ai --force Stacker clones the repo, reads the docker-compose.yml, detects a Node.js app with a PostgreSQL dependency, and generates: # What you'll see in your directory: stacker.yml # The deployment config .stacker/Dockerfile # Optimized Node.js Dockerfile .stacker/docker-compose.yml # Production compose file .env.example # Template with detected env vars scripts/generate-secrets.sh # Auto-generate DB passwords 2.2 Generate secrets and deploy cp .env.example .env ./scripts/generate-secrets.sh # Fills in DB_PASSWORD, etc. stacker config validate # ✓ Configuration is valid stacker deploy --target local # Builds and starts containers 2.3 Verify stacker status # Should show: umami (running), postgres (running) # Open in browser open http://localhost:3000 Step 3: Deploy ArchiveBox ArchiveBox is a self-hosted web archiving solution. Python-based, with a more complex setup involving multiple volumes and environment variables. mkdir ~/archivebox && cd ~/archivebox stacker init --from-github ArchiveBox/ArchiveBox --with-ai --force # Review the generated stacker.yml cat stacker.yml # Generate secrets and deploy cp .env.example .env ./scripts/generate-secrets.sh stacker deploy --target local Notice how Stacker handled ArchiveBox's complexity: multiple volumes for data persistence, the correct entrypoint command, and all the environment variables pulled from the project's documentation. Step 4: Deploy Floci (AWS Local Emulator) Floci emulates AWS services locally. It's a complex Go project with Docker-in-Docker, multiple port ranges, and volume mounts for the Docker socket. mkdir ~/floci && cd ~/floci stacker init --from-github floci-io/floci --with-ai --force Stacker handles the complexity automatically: Detects the Dockerfile at the project root Reads the docker-compose.yml to find port mappings (4566, plus the port ranges) Extracts all 7 FLOCI_* environment variables from the compose file Identifies the Docker socket volume mount ( /var/run/docker.sock ) Generates a clean stacker.yml with the app as app.image: floci/floci:latest Step 5: Understanding the Generated Config Let's look at what Stacker produced for Umami. The stacker.yml will look something like: name: umami deploy: target: local app: type: node path: . ports: - "3000:3000" environment: DATABASE_URL: "postgresql://umami:${DB_PASSWORD}@postgres:5432/umami" HASH_SALT: "${HASH_SALT}" services: - name: postgres image: postgres:16-alpine ports: - "127.0.0.1:5432:5432" environment: POSTGRES_DB: umami POSTGRES_USER: umami POSTGRES_PASSWORD: "${DB_PASSWORD}" volumes: - postgres_data:/var/lib/postgresql/data healthcheck: test: "CMD-SHELL pg_isready -U umami -d umami" interval: 5s timeout: 2s retries: 10 volumes: postgres_data: {} proxy: type: none auto_detect: false Key things Stacker got right without any manual input: Correct app type: Node.js detected from package.json Database service: PostgreSQL extracted from docker-compose.yml Healthcheck: pg_isready automatically added Port isolation: PostgreSQL bound to 127.0.0.1 - not exposed externally Volume persistence: Named volume for database data Secret handling: All passwords use ${VAR_NAME} syntax, never hardcoded Step 6: Customizing the Configuration Edit stacker.yml to customize your deployment: # Add a reverse proxy with SSL proxy: type: nginx auto_detect: true domains: - domain: umami.yourdomain.com ssl: auto upstream: app:3000 # Enable monitoring monitoring: status_panel: true healthcheck: endpoint: /api/health interval: 30s # Add AI troubleshooting for failed deployments ai: enabled: true provider: ollama After editing, redeploy: stacker config validate stacker deploy --target local Step 7: Deploying to Production Once your stack works locally, deploy it to your own server: # Option A: Your own server stacker config setup server # Enter: host IP, SSH user, SSH key path stacker deploy --target server # Option B: Cloud provider (Hetzner, DO, AWS, etc.) stacker config setup cloud # Interactive wizard: choose provider, region, instance size stacker deploy --target cloud Stacker provisions the server, installs Docker, deploys your stack, configures the reverse proxy with SSL, and installs the Status Panel agent for ongoing monitoring - all from the CLI. What to Do When Things Go Wrong AI generation fails # Stacker falls back to template-based detection automatically. # Or try a different AI provider: stacker init --from-github owner/repo --with-ai \ --ai-provider openai --ai-api-key sk-... --force Deployment fails # Check logs stacker logs # With AI troubleshooting enabled in stacker.yml: stacker ai ask "why is my postgres container crashing?" --context ./stacker.yml Port conflict # Edit stacker.yml to change the host port: app: ports: - "3001:3000" # Changed host port from 3000 to 3001 # Redeploy stacker deploy --target local Need to regenerate # Use --force to overwrite existing files stacker init --from-github owner/repo --with-ai --force Beyond the Tutorial Stacker does much more than deploy from GitHub: Visual Stack Builder: Drag-and-drop interface for composing multi-service stacks at try.direct 56+ pre-built stacks: One-click deploy for n8n, Supabase, Ghost, Grafana, Open WebUI, and more Pipes: Container-to-container data flows (like self-hosted Zapier) CI/CD integration: stacker ci export --platform github generates GitHub Actions workflows Vault secrets: Remote secret storage and injection for production deployments Key Takeaways Any GitHub repo with a docker-compose.yml can be deployed in two commands --with-ai dramatically improves config quality by reading README, compose, and source Healthchecks, port isolation, and secret handling are automatic The same stacker.yml works identically on local, server, and cloud targets You own the infrastructure - Stacker just manages the deployment Everything is open source (MIT) on GitHub

Step-by-step tutorial: deploy any GitHub project with Stacker in 5 minutes. From discovery to production - no Docker expertise required.

From GitHub Repo to Production - A 5-Minute Stacker Tutorial

The Self-Hosting Landscape in 2026 Self-hosting has never been more accessible. Between Docker, Compose, and a growing ecosystem of deployment tools, you no longer need a full-time DevOps engineer to run production workloads on your own servers. But the landscape is crowded, and picking the right tool depends on what you actually need: simplicity, control, cost predictability, or all three. Quick Answer Use Stacker if you want to deploy any GitHub repo in one command and own your infrastructure. It auto-detects project types, generates Docker configurations, provisions cloud servers, and deploys - all from a CLI. Unlike Vercel or Railway, you own the servers. Unlike Coolify or CapRover, you don't need to set them up first. The Competitors at a Glance Tool Model Best For Biggest Limitation Stacker Open-source CLI + hosted platform Deploying OSS projects, multi-service stacks Newer ecosystem, smaller community Vercel / Netlify PaaS, usage-based pricing Frontend apps, serverless functions Not for databases or stateful workloads Railway / Render PaaS, per-service pricing Full-stack apps with managed DBs Unpredictable bills, platform lock-in Coolify Self-hosted OSS, free Heroku-like PaaS on your own server Must provision and maintain the server yourself CapRover Self-hosted OSS, free Simple app hosting with a web UI Single-server only, limited multi-stack support Portainer Self-hosted, free/enterprise Managing existing Docker containers Manages containers you already have - doesn't create them Stacker vs Vercel/Railway: Own Your Infrastructure Vercel and Railway are excellent for getting started fast - push to Git, get a URL. But the tradeoffs compound over time: Pricing scales with usage, not value. A moderately busy app can cost $50-200/mo before you know it. You don't own the infrastructure. Migrating away means re-architecting your deployment. Limited to their supported stack. Want to run a Rust binary, an n8n workflow, or a custom Docker image? You're often out of luck or paying a premium. With Stacker, you deploy to your own Hetzner, DigitalOcean, AWS, or on-premise server. You pay the cloud provider directly - Stacker manages the deployment, not the bill. A $5/mo Hetzner VPS running Stacker can replace $200/mo of PaaS services. Stacker vs Coolify: Provisioning Included Coolify is the most popular self-hosted PaaS. It gives you a Heroku-like dashboard on your own server. But there's a catch: Coolify requires you to already have a server running. You need to provision a VPS, install Docker, install Coolify, configure networking, and then start deploying apps. That's the part Coolify doesn't help with. Stacker operates one layer below and above. It provisions the cloud server for you (from 8+ providers including Hetzner, DigitalOcean, AWS, Linode, Vultr, Contabo), deploys your stack, configures the reverse proxy and SSL, sets up monitoring, and installs a Status Panel agent for ongoing management. You can use Coolify alongside Stacker - Stacker provisions the server, then Coolify manages day-2 operations. They complement each other. Stacker vs CapRover: Multi-Service, Multi-Cloud CapRover is a simple, single-server PaaS. Install it on one machine, deploy apps through a web UI. It works well for simple setups but hits walls when you need: Multi-server deployments (API on one machine, database on another) Complex multi-container stacks with service dependencies Cloud-provider portability (move from Hetzner to AWS without changing your deployment config) Pre-built templates for common stacks (n8n + Qdrant + Ollama, for example) Stacker handles all of these with a single stacker.yml file. You define your stack once, and it deploys identically to any provider. Where Stacker Is Unique Six capabilities that no single competitor combines: Full lifecycle: Provision server → generate Dockerfiles → deploy → configure proxy/SSL → monitor → update. One CLI, end to end. Multi-cloud: 8+ providers (Hetzner, DO, Linode, Vultr, Contabo, AWS, OCI, OVH) plus your own server. Switch providers by changing one line. AI-powered config generation: Point at a GitHub repo, Stacker reads the README, compose file, and source to infer the full deployment config. No lock-in: You own the servers, SSH keys, and data. Stacker generates standard Docker Compose files you can use without the CLI. Status Panel agent: A lightweight agent runs on your server for health monitoring, log streaming, container restarts, and configuration updates - without SSH. Marketplace: 56+ pre-built stacks (n8n, Qdrant, Ollama, Supabase, Ghost, Umami, Plausible, etc.) deployable in one click. Creators earn 75% revenue share. When to Use What Your Need Best Tool Why Deploy a Next.js landing page Vercel Free tier, instant deploys, built-in analytics Deploy a full-stack app with DB Railway or Stacker Railway for speed, Stacker for cost control Self-host 10+ OSS tools on one server Coolify Web UI for managing many apps on a single machine Deploy a complex multi-service stack (API + DB + cache + queue + AI) Stacker Auto-detects everything, provisions the server, one command Manage existing Docker containers Portainer Purpose-built for container management, not deployment Deploy any GitHub repo without reading the docs Stacker stacker init --from-github is unmatched The Bottom Line Stacker isn't trying to be the best at everything. It's the best at one specific workflow: I found a project on GitHub, I want it running on my server, and I don't want to spend an hour configuring YAML. For everything else, use the right tool - but for that workflow, nothing else comes close. Getting Started # Install curl -fsSL https://raw.githubusercontent.com/trydirect/stacker/main/install.sh | bash # Deploy something stacker init --from-github plausible/analytics --with-ai stacker deploy --target local Stacker CLI is MIT-licensed on GitHub . The managed platform is at try.direct .

Compare Stacker, Coolify, CapRover, Vercel, and Railway for self-hosting. Which tool gives you the most control with the least ops overhead?

Self-Host Without the Ops Overhead - Stacker vs Coolify, Vercel, and CapRover

What Is Stacker? Stacker is an open-source CLI tool that turns any project into a deployable Docker stack. Add a stacker.yml to your repo, and Stacker generates Dockerfiles, docker-compose definitions, reverse-proxy configs, and deploys locally or to cloud providers - optionally with AI assistance. It's like having a DevOps engineer in your terminal. Quick Answer Deploy any GitHub repo with one command: stacker init --from-github owner/repo --with-ai stacker deploy --target local Stacker shallow-clones the repo, auto-detects the project type and services, generates a ready-to-use stacker.yml , and deploys with a single follow-up command. No YAML, no Docker expertise needed. The Problem: "I Found a Cool Project, Now What?" You find an interesting project on GitHub - a self-hosted analytics dashboard, an AI agent framework, an internal helpdesk. The README says "docker compose up" but then you discover: The compose file expects 14 environment variables you need to configure Three of those are secrets you're supposed to generate yourself The database needs manual initialization before the app starts Port mapping is wrong for your machine SSL needs configuring separately What should take 30 seconds becomes a 30-minute debugging session. Stacker fixes this. Installing Stacker curl -fsSL https://raw.githubusercontent.com/trydirect/stacker/main/install.sh | bash stacker --version Stacker is a single static binary for macOS and Linux, x86_64 and ARM64. No runtime dependencies beyond Docker and git. The Magic Command: stacker init --from-github This is the feature that makes Stacker fundamentally different from every other deployment tool. You point it at any GitHub repo, and it does the rest: # Deploy ArchiveBox (self-hosted web archiving) stacker init --from-github ArchiveBox/ArchiveBox --with-ai stacker deploy --target local # Deploy Plausible Analytics (privacy-first analytics) stacker init --from-github plausible/analytics --with-ai stacker deploy --target local # Deploy anything with a docker-compose.yml stacker init --from-github owner/repo --with-ai What happens under the hood: Shallow-clone the repo into a temp directory Auto-detect the project type (Node, Python, Rust, Go, PHP, static, or custom) Parse docker-compose.yml to identify services - the main app, databases, caches, queues Classify infrastructure (postgres, redis, mysql, mongo, rabbitmq, elasticsearch) and infer appropriate healthchecks Detect environment variables and generate .env.example with secrets marked for generation Generate a complete stacker.yml with the correct app type, image or Dockerfile reference, port mappings, service dependencies, and monitoring config Create .stacker/Dockerfile and .stacker/docker-compose.yml for immediate deployment Generate scripts/generate-secrets.sh that uses openssl rand -hex to fill in secret values AI-Powered Config Generation With --with-ai , Stacker scans the repo's README, docker-compose.yml, Dockerfile, package.json, and source files using an LLM to infer context that simple file detection can't discover - port mappings buried in documentation, environment variables documented in READMEs, service relationships, and deployment prerequisites. Supports Ollama (local, free, private by default), OpenAI, and Anthropic: # Local AI with Ollama (default, free) stacker init --from-github owner/repo --with-ai # OpenAI stacker init --from-github owner/repo --with-ai \ --ai-provider openai --ai-api-key sk-... # Anthropic stacker init --from-github owner/repo --with-ai \ --ai-provider anthropic --ai-api-key $ANTHROPIC_API_KEY # Remote Ollama server stacker init --from-github owner/repo --with-ai \ --ai-endpoint http://192.168.1.100:11434 --ai-model qwen2.5-coder If the AI provider is unreachable, Stacker falls back to template-based detection automatically. And if the model outputs docker-compose format instead of stacker format (common with smaller models), Stacker automatically converts it. From Zero to Deployed in Two Commands Here's the complete workflow for deploying any project you find on GitHub: # 1. Generate configuration from the repo stacker init --from-github floci-io/floci --with-ai --force # 2. Review what was generated stacker config validate cat stacker.yml # 3. Deploy locally stacker deploy --target local # 4. Check status stacker status # 5. View logs stacker logs What Gets Generated After running stacker init --from-github , your directory contains: stacker.yml - The single deployment configuration file .stacker/Dockerfile - Optimized for the detected project type .stacker/docker-compose.yml - Ready-to-use compose definition .env.example - Template with detected environment variables scripts/generate-secrets.sh - Auto-generates secure random values for secrets Healthchecks That Work Out of the Box Stacker automatically infers appropriate healthchecks for infrastructure services: PostgreSQL: pg_isready -U postgres (interval 5s, timeout 2s) Redis: redis-cli ping (interval 5s, timeout 2s) MySQL/MariaDB: mysqladmin ping -h localhost (interval 5s, timeout 2s) MongoDB: mongosh --eval 'db.adminCommand("ping")' RabbitMQ: rabbitmq-diagnostics -q ping Elasticsearch: curl -fsSL http://localhost:9200/_cluster/health Security by Default Stacker enforces several security best practices automatically: Secrets use ${VAR_NAME} syntax - never hardcoded passwords Infrastructure ports bind to 127.0.0.1 - databases aren't exposed to the network Secrets generation is idempotent - generate-secrets.sh only fills missing values, never overwrites existing ones .env is gitignored - secrets never accidentally committed Beyond Local: Deploy to Any Cloud Once your stack works locally, deploy it to production on your own infrastructure: # Deploy to your own server stacker config setup server stacker deploy --target server # Deploy to Hetzner, DigitalOcean, AWS, Linode, or Vultr stacker config setup cloud stacker deploy --target cloud You own the infrastructure. Stacker manages the deployment. No vendor lock-in, no platform markups on your cloud bill. Open Source The Stacker CLI is MIT-licensed and available on GitHub at github.com/trydirect/stacker . The deployment engine, visual Stack Builder, and marketplace are hosted services available at try.direct . Getting Started Install: curl -fsSL https://raw.githubusercontent.com/trydirect/stacker/main/install.sh | bash Find a project: Browse GitHub for anything with a docker-compose.yml Deploy: stacker init --from-github owner/repo --with-ai && stacker deploy --target local Iterate: Edit stacker.yml , re-run stacker deploy

Deploy any GitHub repository with a single command using Stacker. No Docker expertise needed - auto-detects project type, services, ports, and env vars.

Deploy Any GitHub Repo in One Command with Stacker

What Happens When a Service Is Missing? You've created a project on the Stacker dashboard, deployed it to a cloud server, and everything looks good - except the main application container isn't there. Only the database is running. This usually happens when the project was set up without a proper application template, leaving you with a half-empty stack. In this guide, we'll walk through a real scenario: an Umami analytics project that was deployed with only PostgreSQL and no Umami container. You'll learn how to inspect the deployment, add the missing app via the Stacker API, deploy it, and verify everything works - all from the command line. Quick Answer Use stacker agent status to inspect your deployment, then register the missing app via the Stacker API ( POST /project/{id}/apps ) and deploy it with stacker agent deploy-app . Step 1: Inspect the Current Deployment Start by checking what's actually running on your deployment agent. Use the stacker agent status command with your deployment hash: stacker agent status --deployment deployment_c837325f-34b3-4d1f-b4a0-e55a49cf8926 This shows you the running containers, their images, and their states: ──────────────────────────────────────────────────────────────────────────────────────────── Agent: ● online Heartbeat: 2026-07-01T18:31:56.563318Z ──────────────────────────────────────────────────────────────────────────────────────────── APP NAME IMAGE ENABLED postgres postgres postgres:latest yes ──────────────────────────────────────────────────────────────────────────────────────────── CONTAINER STATE PORTS IMAGE project-postgres-1 ⟳ restarting 5432 postgres:latest statuspanel_agent ▶ running - registry-intl.eu-central-1.… statuspanel ▶ running - registry-intl.eu-central-1.… ──────────────────────────────────────────────────────────────────────────────────────────── Notice only postgres appears in the APP list. The Umami analytics container is completely absent. Step 2: Get Detailed App Configuration For more detail, use the --json flag. This reveals the exact environment variables, port mappings, volumes, and network configuration of the running apps: stacker agent status --deployment deployment_c837325f-34b3-4d1f-b4a0-e55a49cf8926 --json Look for the apps array in the JSON output. For our postgres app: { "apps": [ { "code": "postgres", "image": "postgres:latest", "environment": { "POSTGRES_DB": "umami", "POSTGRES_USER": "umami", "POSTGRES_PASSWORD": "umami" }, "ports": [{"host_port": 5432, "container_port": 5432}], "networks": ["default_network"], ... } ] } This tells us the database credentials ( umami for user, password, and database name) - exactly what we need to configure the Umami container's DATABASE_URL . Step 3: Check If a Template Exists See what templates are available in the marketplace: stacker templates | grep -i umami stacker catalog | grep -i umami If nothing shows up, there's no Umami template you can simply install. You'll need to register the app manually. Step 4: Create the App via the Stacker API Apps are managed through the Stacker REST API. The endpoint is a POST to /project/{project_id}/apps - and it's an upsert, so you can safely run it multiple times. First, find your project ID and get your auth token from ~/.config/stacker/credentials.json : # List projects to find your project ID stacker projects | grep umami # Output: 243 umami 2026-06-30T08:49:12... # Your access token is stored here cat ~/.config/stacker/credentials.json Now create the Umami app: TOKEN="*******token*******" curl -s -X POST "https://try.direct/stacker/project/243/apps" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "code": "umami", "name": "Umami Analytics", "image": "ghcr.io/umami-software/umami:postgresql-latest", "environment": { "DATABASE_URL": "postgresql://umami:umami@postgres:5432/umami", "HASH_SALT": "3b8e9f1a7c2d5e4f6a0b9c8d7e6f5a4b3c2d1e0f" }, "ports": [ {"host_port": 3000, "container_port": 3000, "protocol": "tcp"} ], "depends_on": ["postgres"], "restart_policy": "always", "enabled": true, "deploy_order": 2 }' Successful response: { "message": "OK", "item": { "id": 28, "project_id": 243, "code": "umami", "name": "Umami Analytics", "image": "ghcr.io/umami-software/umami:postgresql-latest", "environment": { "DATABASE_URL": "postgresql://umami:umami@postgres:5432/umami", "HASH_SALT": "3b8e9f1a7c2d5e4f6a0b9c8d7e6f5a4b3c2d1e0f" }, "ports": [{"container_port": 3000, "host_port": 3000, "protocol": "tcp"}], "restart_policy": "always", "enabled": true, "deploy_order": 2, "created_at": "2026-07-01T18:39:11.469030Z", "updated_at": "2026-07-01T18:39:11.469030Z", "config_version": 1 } } Step 5: Plan and Deploy the App First, preview what deploy-app will do: stacker agent deploy-app umami \ --deployment deployment_c837325f-34b3-4d1f-b4a0-e55a49cf8926 \ --plan Expected plan output: { "hasChanges": true, "actions": [ { "kind": "redeploy_app", "target": "app", "appCode": "umami", "reason": "explicit deploy-app plan targets a single app" }, { "kind": "sync_app_config", "target": "app", "appCode": "umami", "reason": "app config version is ahead of the synced Vault/runtime version" } ] } Apply the plan: stacker agent deploy-app umami \ --deployment deployment_c837325f-34b3-4d1f-b4a0-e55a49cf8926 Successful deployment output: Command: cmd_513774de-e91e-4357-b886-8565f3ce3ef2 Type: deploy_app Status: ✓ completed { "app_code": "umami", "container_state": "running", "deployed_at": "2026-07-01T18:40:36Z", "status": "deployed" } Step 6: Verify Everything Is Running Check the status again: stacker agent status --deployment deployment_c837325f-34b3-4d1f-b4a0-e55a49cf8926 ──────────────────────────────────────────────────────────────────────────────────────────── Agent: ● online Heartbeat: 2026-07-01T18:40:36.661528Z ──────────────────────────────────────────────────────────────────────────────────────────── APP NAME IMAGE ENABLED postgres postgres postgres:latest yes umami Umami Analytics ghcr.io/umami-software/umam… yes ──────────────────────────────────────────────────────────────────────────────────────────── CONTAINER STATE PORTS IMAGE umami ▶ running - ghcr.io/umami-software/umam… postgres ▶ running - postgres:latest statuspanel_agent ▶ running - registry-intl.eu-central-1.… statuspanel ▶ running - registry-intl.eu-central-1.… ──────────────────────────────────────────────────────────────────────────────────────────── Both postgres and umami are now listed as apps and running. You can inspect the logs to confirm the application started correctly: stacker agent logs umami \ --deployment deployment_c837325f-34b3-4d1f-b4a0-e55a49cf8926 Look for key log lines: ✓ DATABASE_URL is defined. ✓ Database connection successful. ✓ Database is up to date. > umami@3.2.0 start-server > node server.js ▲ Next.js 16.2.6 - Local: http://localhost:3000 - Network: http://0.0.0.0:3000 ✓ Ready in 0ms Step 7: Configure a Domain Set a public domain for the new app via the API: curl -s -X PUT "https://try.direct/stacker/project/243/apps/umami/domain" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{"domain": "umami.try.direct", "ssl_enabled": true}' Then configure the reverse proxy on the agent: stacker agent configure-proxy umami \ --domain umami.try.direct \ --port 3000 \ --ssl \ --deployment deployment_c837325f-34b3-4d1f-b4a0-e55a49cf8926 \ --force Troubleshooting Common Issues Issue 1: "service refers to undefined network" If the existing app has networks configured but the Docker Compose file lacks the network definition, update the existing app to remove the network reference: curl -s -X POST "https://try.direct/stacker/project/243/apps" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "code": "postgres", "image": "postgres:latest", ... }' Omitting the networks field lets Docker Compose use its default network, which all services can share. Issue 2: "service refers to undefined volume" Named volumes must be defined at the top level of the Compose file. If the deploy-app command complains about undefined volumes, remove the volumes configuration from the app definition (the data persists on disk via the existing container). Issue 3: Vault is unavailable Some operations (like configure-proxy ) require HashiCorp Vault for credential resolution. If Vault is unavailable, the proxy configuration step will fail. In this case, the app will still run and be accessible on its internal port - you can configure DNS and SSL manually on the server. Key Commands Reference Command Purpose stacker agent status --deployment Inspect running containers and apps stacker agent status --deployment --json Detailed JSON view with config stacker projects | grep Find your project ID POST /project/{id}/apps Register a new app (via API) stacker agent deploy-app --deployment Deploy the registered app to the agent stacker agent logs --deployment View container logs stacker agent configure-proxy --domain ... --port ... Set up reverse proxy and SSL How It All Fits Together The Stacker platform separates app registration from app deployment (done through the CLI, which sends commands to the remote agent). This two-step process gives you full control: API - Define the Docker image, environment variables, port mappings, volumes, restart policy, and deployment order CLI - Push the configuration to the remote server, pull the image, create the container, and wire it into the existing Docker Compose project This approach works for any containerized application, not just Umami. Whether you're adding Redis, a custom API, or a background worker, the workflow is identical. The next time you find a project deployed without its main application container, you now have the exact steps to fix it - inspect, register, deploy, verify.

Learn how to add a missing container service to an existing Stacker deployment using the Stacker CLI and API. Step-by-step walkthrough with real commands and output.

How to Add a Missing Service to a Stacker Deployment

TryDirect blog. Check some deployment facilitation tips and tech how to's. Read articles about new and popular technologies and their key features. 