What Are SSH PEM Keys? SSH PEM (Privacy Enhanced Mail) keys are cryptographic files used for secure authentication. They eliminate password-based logins and provide stronger security through asymmetric encryption. SSH PEM keys consist of a private key kept secret on your local machine and a public key installed on remote servers. Quick Answer SSH PEM keys are cryptographic file pairs (private + public) that enable password-less, secure server access. Generate them with ssh-keygen -t rsa -b 4096 , add the public key to ~/.ssh/authorized_keys on your server, and connect using ssh -i ~/.ssh/id_rsa user@server . Generating Your SSH Key Pair Step-by-Step Instructions Step 1: Open a terminal on your local machine. Step 2: Run the following command: ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -N "" Step 3: Your keys are now generated in ~/.ssh/ : id_rsa - Your private key (keep this secret) id_rsa.pub - Your public key (share with servers) Step 4: Secure your private key with proper permissions: chmod 600 ~/.ssh/id_rsa chmod 644 ~/.ssh/id_rsa.pub Adding Your Public Key to a Server Once you have your SSH key pair, add the public key to the target server: ssh-copy-id -i ~/.ssh/id_rsa.pub user@server_ip Or do it manually: cat ~/.ssh/id_rsa.pub | ssh user@server_ip "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys" Connecting with Your SSH Key Now you can connect to the server without entering a password: ssh -i ~/.ssh/id_rsa user@server_ip For the default SSH key location, you can simply use: ssh user@server_ip Troubleshooting Common Issue 1: Permission denied (publickey) Verify authorized_keys permissions are exactly 600 : chmod 600 ~/.ssh/authorized_keys Common Issue 2: Can't find key file Check whether the key exists in the expected location: ls -la ~/.ssh/ Common Issue 3: Server rejects key Ensure the public key is properly copied to the server and has correct permissions: ssh user@server_ip "cat ~/.ssh/authorized_keys" Common Issue 4: SSH timeout Check that the firewall allows port 22 and the SSH service is running: sudo systemctl status ssh Best Practices for 2026 Use RSA-4096 or Ed25519 keys - Stronger encryption than RSA-2048 Always set a passphrase - Protects your private key if compromised Restrict key permissions - Keep private keys at 600, public keys at 644 Keep private keys safe - Never share or upload them to version control Document key purposes - Maintain a list of which keys are used where Rotate keys annually - Generate new keys and update all servers Use SSH config file - Simplify connection management with aliases SSH Config File Example Create ~/.ssh/config for easier connections: Host production HostName 203.0.113.50 User deploy IdentityFile ~/.ssh/id_rsa Port 22 Host staging HostName 198.51.100.75 User deploy IdentityFile ~/.ssh/id_rsa_staging Port 2222 Now you can simply use ssh production . SSH PEM authentication remains one of the simplest ways to secure direct server access. Once your key pair is in place, daily connections become faster, more reliable, and easier to automate across environments.

Learn how to generate SSH PEM keys, install the public key on a server, connect without passwords, and troubleshoot common SSH key issues.

SSH with PEM Key File

OpenClaw is a personal AI assistant with a multi-channel gateway — think of it as a self-hosted AI hub that connects to your tools, documents, and workflows. Running it on your own infrastructure keeps your data private. Running it inside Kata Containers adds hardware-level isolation , ensuring that even if the AI workload is compromised, it cannot escape to your host system. This guide covers two ways to get started — pick whichever fits your workflow. Why Kata Containers for AI Workloads? AI assistants like OpenClaw process sensitive data: your documents, API keys, conversation history, and workspace files. Standard Docker containers ( runc ) share the host kernel — a container escape exploit could expose everything on the host. Kata Containers solve this by running each container inside a lightweight virtual machine: runc (standard) Kata Kernel Shared with host Dedicated guest kernel Isolation Linux namespaces + cgroups Hardware VM boundary (VT-x/EPT) Escape impact Full host access Contained in VM OCI compatible Yes Yes For AI workloads that handle private data, the security trade-off is compelling: you get a hardware isolation boundary that's orders of magnitude harder to bypass than namespace-based containers. Bare-metal requirement: read this first Kata Containers need direct /dev/kvm access on the host. That means bare-metal servers only . Every Hetzner Cloud VM type — CX, CPX, CCX, and CAX — runs on a hypervisor that does not expose /dev/kvm to the guest, and Hetzner's own FAQ confirms nested virtualisation is not supported on Cloud servers. On Hetzner you need a Robot bare-metal server . Same rule applies elsewhere: any provider that puts you inside a VM cannot run Kata. Providers where Kata works: Hetzner Robot, OVH bare metal, Scaleway Dedibox, self-owned hardware. Path A: Deploy via TryDirect (Easiest) The fastest way to run OpenClaw with Kata — no Terraform, no Ansible, no infrastructure to manage. TryDirect handles the deployment flow for you, but Kata still requires a host with real /dev/kvm access. 1. Create a TryDirect account Sign up at try.direct . If you're bringing your own infrastructure, make sure the target host is a bare-metal server (see the section above). 2. Create your stack From the dashboard, select OpenClaw from the app catalog. Choose Kata Containers as the runtime. 3. Deploy Click Deploy . TryDirect handles everything: Targets infrastructure with real KVM access Installs Docker and Kata Containers Generates the compose file with runtime: kata Deploys OpenClaw with hardware isolation You get a running OpenClaw instance with Kata isolation in minutes, accessible via the URL shown in your dashboard. 4. Manage Use the TryDirect dashboard or the Stacker CLI: stacker status # container health stacker logs --service openclaw # view logs stacker agent status # verify runtime: kata That's it. If you don't need full control over the infrastructure, TryDirect is the recommended path. Read on only if you prefer to self-host. Path B: Self-Hosted Setup (Full Control) If you'd rather manage your own servers, you can provision and configure everything yourself using the bare-metal guidance and Ansible files included in the Stacker repository . What you need A bare-metal server — Hetzner Robot or any provider that exposes /dev/kvm directly to your host OS Ansible installed locally The Stacker CLI installed Hetzner users: you need a Hetzner Robot bare-metal server , not a Hetzner Cloud VM. All Hetzner Cloud VM families — CCX, CX, CPX, and CAX — run on a hypervisor that does not expose /dev/kvm to the guest. See the Hetzner KVM Guide for a valid bare-metal setup flow. Step 1: Provision a Hetzner Robot bare-metal server Order and install the server first: Order an x86_64 dedicated server in the Hetzner Robot portal . Install Ubuntu 22.04 LTS (or another supported Linux distribution). Add your SSH key and boot the server. SSH into the host and verify that KVM is actually present: ssh root@ ls -la /dev/kvm lsmod | grep kvm egrep -c '(vmx|svm)' /proc/cpuinfo If /dev/kvm is missing, stop there — that host cannot run Kata Containers. Step 2: Configure with Ansible Once the bare-metal server is online, use the Ansible playbook at docs/kata/ansible/kata-setup.yml : cd stacker/docs/kata/ansible ansible-playbook -i , kata-setup.yml \ --private-key ~/.ssh/id_rsa \ --user root The playbook: Validates KVM access ( /dev/kvm ) Installs Kata Containers from the official APT repository Merges the kata runtime into Docker's daemon.json Restarts Docker and runs a smoke test ( docker run --rm --runtime kata hello-world ) Step 3: Initialize your OpenClaw stack mkdir openclaw-stack && cd openclaw-stack # Initialize a stacker project stacker init # Add OpenClaw from the service catalog stacker service add openclaw This generates a stacker.yml with OpenClaw configured: name: openclaw-stack app: type: custom services: - name: openclaw image: ghcr.io/openclaw/openclaw:2026.3.1 ports: - "18789:18789" environment: OPENCLAW_GATEWAY_BIND: lan volumes: - openclaw_config:/home/node/.openclaw - openclaw_workspace:/home/node/.openclaw/workspace The image is pinned to 2026.3.1 for reproducibility. Substitute a later tag once you've tested it. Step 4: Deploy with Kata isolation stacker deploy --runtime kata That's it. Stacker will: Validate the runtime value ( kata is accepted, unknown values are rejected) Check capabilities — verify the target agent supports Kata Generate the compose file with runtime: kata on each service Deploy via Docker Compose on the target server Each OpenClaw container now runs inside its own lightweight VM with a dedicated kernel. Step 5: Verify the deployment # Check container status stacker status # View logs stacker logs --service openclaw --follow # Verify Kata runtime is active stacker agent status # Look for "runtime": "kata" in the deployment details On the server, you can also verify directly: ssh root@ docker inspect openclaw | grep -i runtime # Expected: "Runtime": "kata" Why this matters for OpenClaw specifically OpenClaw processes and stores: Your conversations with AI models API keys for LLM providers (OpenAI, Anthropic, etc.) Workspace files that may contain proprietary code or documents Gateway configurations that bridge multiple communication channels With standard runc , a vulnerability in OpenClaw's Node.js runtime, a dependency supply-chain attack, or a malicious prompt injection that achieves code execution would have direct access to the host filesystem and network. With Kata, that exploit is trapped inside a VM: It sees a minimal guest kernel, not your host It cannot access host files outside its mounted volumes It cannot inspect other containers or host processes Network access is mediated through a virtual NIC Advanced: mixed runtime stacks Not every service in your stack needs Kata. You can run security-sensitive services (like OpenClaw) with Kata while keeping supporting services (like databases) on standard runc : services: - name: openclaw image: ghcr.io/openclaw/openclaw:2026.3.1 runtime: kata # Hardware-isolated ports: - "18789:18789" environment: OPENCLAW_GATEWAY_BIND: lan volumes: - openclaw_config:/home/node/.openclaw - openclaw_workspace:/home/node/.openclaw/workspace - name: postgres image: postgres:16 # runtime: runc (default) — database stays on runc for performance environment: POSTGRES_DB: openclaw POSTGRES_PASSWORD: ${DB_PASSWORD} volumes: - pgdata:/var/lib/postgresql/data This gives you the best of both worlds: hardware isolation where it matters, native performance where it doesn't. Kata fallback behavior If you request --runtime kata but the agent detects that Kata is unavailable (e.g., /dev/kvm missing after a host migration), the agent will: Log a kata_fallback warning Fall back to runc Report the fallback in the deployment result Stacker surfaces this warning in CLI output: Warning: Kata runtime unavailable on target host, fell back to runc. Reason: /dev/kvm not accessible This ensures your deployment succeeds even if Kata becomes temporarily unavailable, while keeping you informed about the security downgrade. Summary Path What you do What's handled for you TryDirect Sign up, pick OpenClaw + Kata, click Deploy KVM-capable infrastructure, Docker, Kata, DNS Self-hosted Provision Robot bare metal, run kata-setup.yml , then stacker deploy --runtime kata Compose generation, runtime injection Running OpenClaw inside Kata Containers gives you: Privacy : your AI data stays on your server, not in a cloud SaaS Isolation : hardware-enforced VM boundary around each container Simplicity : one flag ( --runtime kata ) — everything else is standard Docker Compatibility : standard OCI images, no rebuilds required For more details, see the Kata Containers documentation , Hetzner KVM Guide , and Network Constraints .

Run OpenClaw with Kata Containers for hardware-isolated self-hosted AI. Two paths: TryDirect managed deploy or self-hosted Hetzner bare metal setup with Ansible.

Deploying OpenClaw with Kata Containers: Hardware-Isolated AI on Your Own Server

What Is Docker Compose? Docker Compose is a tool for defining and running multi-container Docker applications. It uses YAML files (docker-compose.yml) to configure your application's services, networks, and volumes in a single, declarative format. Instead of running multiple docker run commands, you define everything in one file and launch your entire stack with a single command. Quick Answer Docker Compose orchestrates multiple containers using a yaml file. Create docker-compose.yml with services (api, db, redis, etc.), then run docker compose up -d . Compose handles networking, volumes, environment variables, and service startup order automatically. Installing Docker Compose Ubuntu 24.04 & Debian 12 Docker Compose comes built-in with modern Docker installations. Verify your installation: docker compose version If not installed: Add Docker repository Update package lists Install docker-compose-plugin Verify installation Real-World Production Example Here's a production stack with nginx, Node.js API, PostgreSQL, and Redis: version: '3.8' services: nginx: image: nginx:latest ports: - "80:80" - "443:443" volumes: - ./nginx.conf:/etc/nginx/nginx.conf depends_on: - api networks: - backend api: build: . expose: - 3000 environment: - NODE_ENV=production - DATABASE_URL=postgres://user:pass@postgres:5432/app - REDIS_URL=redis://redis:6379 depends_on: - postgres - redis networks: - backend postgres: image: postgres:16 environment: - POSTGRES_USER=user - POSTGRES_PASSWORD=secure_password - POSTGRES_DB=app volumes: - postgres_data:/var/lib/postgresql/data networks: - backend redis: image: redis:7-alpine networks: - backend volumes: postgres_data: networks: backend: driver: bridge Architecture Overview: Reverse proxy: nginx on ports 80/443 Application: Node.js API on port 3000 (internal) Database: PostgreSQL with persistent volume Cache: Redis for sessions and caching Network: All services on internal backend network for security Common Operations Start all services docker compose up -d View logs docker compose logs api -f Scale a service docker compose up -d --scale worker=4 Restart a specific service docker compose restart api Execute command in container docker compose exec api npm run migrate Stop and remove everything (with volumes) docker compose down -v Environment Variables Create a .env file in the same directory as docker-compose.yml: DATABASE_URL=postgres://user:password@postgres:5432/myapp REDIS_URL=redis://redis:6379 API_PORT=3000 NODE_ENV=production Reference variables in docker-compose.yml: services: api: environment: - DATABASE_URL=${DATABASE_URL} - REDIS_URL=${REDIS_URL} Health Checks Ensure services start in the correct order: services: postgres: image: postgres:16 healthcheck: test: ["CMD-SHELL", "pg_isready -U user"] interval: 10s timeout: 5s retries: 5 api: build: . depends_on: postgres: condition: service_healthy Networking Between Services Services can communicate using service names as hostnames: # From api service, connect to postgres: const connection = await postgres.connect('postgres://user:pass@postgres:5432/app'); # From api service, connect to redis: const redis = require('redis').createClient({host: 'redis', port: 6379}); Production Best Practices Use specific image versions - Never use :latest Set resource limits - Prevent runaway containers Use health checks - Ensure proper service startup order Separate concerns - One service per container Secure credentials - Use .env files, never commit secrets Volume backups - Regularly backup persistent data Log aggregation - Use logging drivers for centralized logs Troubleshooting Port already in use docker compose down # or change port mapping in docker-compose.yml Service won't start docker compose logs service_name Can't reach service from another container docker compose exec api ping postgres

Master Docker Compose for orchestrating multi-container applications. Learn services, networks, volumes, environment variables, and production best practices.

Docker Compose: Deploy Multi-Container Applications

What Is Fail2Ban? Fail2Ban is an intrusion prevention framework that monitors logs for suspicious activity and automatically bans attacking IP addresses. It's essential for protecting SSH services from automated brute-force attacks. When Fail2Ban detects repeated failed login attempts, it temporarily blocks the attacker's IP address at the firewall level, preventing further attack attempts. Quick Answer Fail2Ban automatically blocks IPs after repeated failed login attempts. Install: sudo apt install fail2ban . Create /etc/fail2ban/jail.local with jail configs (sshd: 3 failures in 5 mins = 30min ban). Restart: sudo systemctl restart fail2ban . Monitor: sudo fail2ban-client status sshd . Installation on Ubuntu 24.04 & Debian 12 Step-by-Step Setup Step 1: Update package lists sudo apt update Step 2: Install Fail2Ban and systemd integration sudo apt install -y fail2ban fail2ban-systemd Step 3: Verify installation fail2ban-client --version Step 4: Start the service sudo systemctl start fail2ban Step 5: Enable on system boot sudo systemctl enable fail2ban Configuration Fail2Ban uses configuration files in /etc/fail2ban/ . The main configuration is in jail.conf , but never edit this directly . Instead, create a jail.local file with your custom settings: sudo nano /etc/fail2ban/jail.local Basic Configuration Example [DEFAULT] # Global settings bantime = 1800 # Ban for 30 minutes findtime = 300 # Check last 5 minutes maxretry = 3 # Ban after 3 failures [sshd] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 3 [recidivism] enabled = true filter = recidivism action = iptables-multiport[name=Recidivism, port="ssh,http,https"] logpath = /var/log/fail2ban.log bantime = 86400 # Repeat offenders get 24-hour ban findtime = 86400 maxretry = 2 Configuration Parameters Explained bantime: Duration (in seconds) to ban an IP. Set to -1 for permanent ban findtime: Time window (in seconds) to look for failures maxretry: Number of failures before ban is triggered enabled: Whether this jail is active port: Service port to monitor (ssh, http, etc.) filter: Log parsing rules to use logpath: Log file to monitor Whitelisting IP Addresses Add trusted IPs that should never be banned. Edit /etc/fail2ban/jail.local : [DEFAULT] ignoreip = 127.0.0.1/8 ::1 192.0.2.50 203.0.113.0/24 [sshd] enabled = true # ... rest of sshd configuration Understanding IP Ranges 127.0.0.1/8 - Localhost and local network ::1 - IPv6 localhost 192.0.2.50 - Single IP address (your office) 203.0.113.0/24 - CIDR notation for a subnet (256 IPs) Verify whitelisted IPs: sudo fail2ban-client get sshd ignoreip Monitoring and Management Check jail status sudo fail2ban-client status sshd View currently banned IPs sudo fail2ban-client get sshd banlist View all jails sudo fail2ban-client status Unban an IP manually sudo fail2ban-client set sshd unbanip 203.0.113.100 View live logs sudo tail -f /var/log/fail2ban.log Restart Fail2Ban After Configuration Changes After editing jail.local , restart the service: sudo systemctl restart fail2ban Verify the changes took effect: sudo fail2ban-client status sshd | grep "Max retry" Advanced: Custom SSH Port If you're running SSH on a non-standard port (e.g., 2222), update the configuration: [sshd] enabled = true port = 2222 filter = sshd logpath = /var/log/auth.log maxretry = 3 Best Practices for 2026 Set reasonable ban times: 30 minutes for casual attempts, 24 hours for repeat offenders Use low maxretry: 3 failed attempts is standard; consider 2 for high-security environments Whitelist trusted networks: Add office, VPN, and admin IPs to ignoreip Monitor logs regularly: Watch for patterns of attacks Combine with other security: SSH keys, key-only auth, change default port Enable recidivism jail: Harder penalties for repeat attackers Review jails regularly: Ensure all jails are properly configured Integration with SSH Key Authentication For maximum security, use SSH keys AND Fail2Ban together: # /etc/ssh/sshd_config PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes MaxAuthTries 3 # Combined with Fail2Ban in jail.local [sshd] maxretry = 3 Troubleshooting Jail not starting sudo fail2ban-client status sudo systemctl status fail2ban sudo journalctl -u fail2ban -n 20 Check filter parsing sudo fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf Test configuration file syntax sudo fail2ban-client -d Verify log path exists ls -l /var/log/auth.log

Deploy Fail2Ban on Ubuntu 24.04 and Debian 12 to automatically block SSH brute-force attacks. Configure jails, whitelist IPs, and integrate with SSH for layered defense.

Fail2Ban: Block SSH Brute Force Attacks

What You'll Set Up A container-down alarm for your deployment using stacker monitor (new in Stacker 0.3.2). You declare an alert once in stacker.yml , and Stacker notifies you the moment any container stops running — and again when it recovers. It's edge-triggered (one alert per change, not per poll), cron-friendly , and needs no web UI. Every command and message below is from a live deployment. Configure the alarm with a monitoring.alerts block Choose a notification channel: terminal, webhook (ntfy/Slack), or a pipe Run it as a loop or a one-shot cron check Understand edge-triggering and the state file Quick Answer # stacker.yml monitoring: status_panel: true alerts: interval: 30 on_recovery: true target: terminal: true # or a webhook / pipe — see below stacker monitor --once # one check (cron) · stacker monitor # loop Stop a container and the next check alerts you. Restart it and you get the recovery notice. Step 1: Declare the Alarm in stacker.yml Add an alerts block under monitoring . Three fields: monitoring: status_panel: true alerts: interval: 30 # poll interval in seconds (default 60) on_recovery: true # also notify when containers recover (default true) target: # where to deliver the alert (required) terminal: true Validate it like any config change: stacker config validate # ✓ Configuration is valid Step 2: Choose a Notification Channel The target is one of three shapes: Terminal + desktop The simplest — an OS notification, a terminal bell, and a line on stderr. Great for a laptop or a tmux pane you keep open: target: terminal: true Webhook (ntfy, Slack, anything HTTP) POST the alert message to any URL. Perfect for phone push via ntfy, or a Slack incoming webhook: target: url: "https://ntfy.example.com/alerts" method: POST # optional, defaults to POST Pipe (route through a Stacker pipe) Hand the alert to a declared pipe for richer routing. (Accepted today; dispatch is a follow-up — use terminal or webhook for now.) target: pipe: oncall-notify Step 3: Run It Two modes — a long-running loop, or a one-shot check you schedule yourself: stacker monitor # loops every `interval` seconds stacker monitor --once # a single check, then exits (cron-friendly) stacker monitor --interval 15 # override the configured interval For a hands-off setup, put the one-shot form in cron: # check every minute * * * * * cd /path/to/project && stacker monitor --once …or run the loop under systemd / tmux on a box that's always on. What It Looks Like When a Container Drops Everything healthy — a quiet line, no alert: $ stacker monitor --once · 4 container(s), all healthy Now stop a container to simulate a failure: $ docker stop project-ntfy-1 # (on the server) $ stacker monitor --once ● ⚠️ container problem: 1 not running (project-ntfy-1) 🔔 Stacker container alert: ⚠️ container problem: 1 not running (project-ntfy-1) Run it again while still down — silence . That's edge-triggering: it already told you once. $ stacker monitor --once # (no alert — still down, nothing new) Restart the container and the next check sends the recovery notice: $ docker start project-ntfy-1 $ stacker monitor --once ● ✅ all containers recovered 🔔 Stacker container alert: ✅ all containers recovered With a webhook target, that same message lands on your ntfy topic or Slack channel — verify it yourself: curl "http:// :8080/alerts/json?poll=1" # {"event":"message","topic":"alerts", # "message":"⚠️ container problem: 1 not running (project-ntfy-1)"} How Edge-Triggering Works On each check, stacker monitor fetches live container health from the Status Panel agent, decides up (all running) or down (any not running), and compares it to the last known state stored in .stacker/monitor.state . It only notifies on a change : up → down → "container problem" alert down → up → "recovered" alert (unless on_recovery: false ) same state → nothing Because the state is a file, one-shot --once runs stay edge-triggered across separate cron invocations — you won't get a fresh alert every minute while a container is down. A brand-new watcher against an already-down stack alerts immediately (a sensible baseline). Frequently Asked Questions Is this different from stacker status --watch --notify ? Yes. status --watch --notify notifies on deployment lifecycle (a deploy reaching completed/paused/failed). stacker monitor watches ongoing container health after deploy. Do I need the Status Panel agent? Yes — set monitoring.status_panel: true so the agent is installed during deploy (or add it later with stacker agent install ). The monitor reads live health from it. Will cron spam me while a container stays down? No — that's the whole point of edge-triggering plus the .stacker/monitor.state file. You get one alert on the drop and one on recovery. Can I alert only, not on recovery? Set on_recovery: false — you'll get the problem alerts but not the "recovered" notices. How do I watch multiple projects? Run stacker monitor --once from each project directory (each has its own stacker.yml and .stacker/monitor.state ) — one cron line per project. Key Takeaways monitoring.alerts + stacker monitor = a built-in container-down alarm (Stacker 0.3.2), no web UI Three channels: terminal , HTTP url (ntfy/Slack), or a pipe Edge-triggered via .stacker/monitor.state — one alert per change, cron-safe --once for cron, the bare command for a long-running loop Recovery notices are on by default; turn them off with on_recovery: false

Get notified the moment a Docker container goes down with `stacker monitor`. Configure terminal, ntfy/Slack webhook, or pipe notifications from stacker.yml — edge-triggered, cron-friendly, no web UI.

Get Notified When a Container Goes Down — stacker monitor

What You'll Do Push a new Docker image tag to a running app on a remote server — from your laptop, in one command, without SSH-ing in . No docker pull , no editing compose on the box, no server login. The Stacker CLI talks to the Status Panel agent already running on your deployment, so you preview the change, apply it, and confirm the new image is live, all from your terminal. Update a container's image with a single command Preview the change first with a read-only plan Verify the new image is running Keep stacker.yml in sync so the change sticks Quick Answer stacker agent deploy-app --image : --force Example: stacker agent deploy-app app --image myorg/api:v2.1 --force . Done — the running container is recreated on the new image, no SSH required. Why No SSH? When you deploy with Stacker (with monitoring.status_panel: true ), a small Status Panel agent runs alongside your containers. The CLI sends it commands over the message bus — so updating an image is an API call, not a shell session. You don't open a terminal on the server, you don't run docker by hand, and there's an audit trail of what changed. Step 1: Find the App Code Every container is addressed by its app code. List them: stacker agent apps # or, with live health/images: stacker agent health # CONTAINER STATE IMAGE # project-app-1 running myorg/api:v2.0 The app code is the service name (e.g. app , or a named service). Step 2: Preview the Change (Recommended) Before touching production, ask for a read-only plan. It shows exactly what will change and returns a fingerprint you apply verbatim — so what you reviewed is exactly what runs: stacker agent deploy-app app --image myorg/api:v2.1 --plan Review the plan, then apply it by fingerprint: stacker agent deploy-app app --apply-plan Step 3: Or Just Apply It If you don't need the preview, update in one shot: stacker agent deploy-app app --image myorg/api:v2.1 --force --image is the full reference including the tag ( myorg/api:v2.1 , nginx:1.27 , caronc/apprise:latest ). There's no separate --tag flag — the tag is part of the image. --force recreates the container so it actually pulls and restarts on the new image. Step 4: Verify It's Live Confirm the new image is the one running — the IMAGE column is the proof: stacker agent health # project-app-1 running myorg/api:v2.1 ← new tag, up stacker agent logs app --limit 100 # sanity-check startup Useful Flags Flag What it does --deployment Target a specific deployment (otherwise the active agent for the project is used) --env Select an environment/profile ( local / dev / prod ) --runtime kata|runc Container runtime (default runc ) --json Machine-readable output for scripts/CI Keep stacker.yml in Sync agent deploy-app updates the running container on the server directly — it does not rewrite your local stacker.yml . That's perfect for a hotfix or a quick roll-forward, but it means a future full deploy ( stacker deploy ) would use whatever image is still pinned in your config. So after the update, bump the tag in stacker.yml too: app: type: custom image: myorg/api:v2.1 # was v2.0 Now the new image is both live and the persistent default — no surprise rollback on the next full deploy. Roll Back the Same Way Rolling back is just deploying the previous tag — again, no SSH: stacker agent deploy-app app --image myorg/api:v2.0 --force Frequently Asked Questions Do I need SSH access at all? No. The command goes through the Status Panel agent over the message bus. (Stacker still keeps an emergency SSH key for you — see stacker status — but you don't need it for image updates.) Does this pull the image automatically? Yes — with --force the agent recreates the container, which pulls the specified image if it isn't already present. What about private registries? Configure registry credentials for the deployment (via deploy.registry or the STACKER_DOCKER_* env vars) so the agent can pull private images. Can I update several apps at once? Run one agent deploy-app per app code. Scripting it with --json makes multi-app roll-outs a short shell loop. How do I know it worked? stacker agent health shows the live IMAGE per container — if it reads your new tag and the container is running , you're done. Pair it with stacker monitor to be alerted if the new image crashloops. Key Takeaways stacker agent deploy-app --image : --force updates a running container's image — no SSH --plan → --apply-plan lets you review before applying to production stacker agent health confirms the new image is live (the IMAGE column) Also bump the tag in stacker.yml so a future full deploy doesn't revert it Rollback is the same command with the previous tag

Update a Remote Docker Container Image Without SSH — Stacker CLI

What You'll Build A working webhook pipeline between two tiny self-hosted apps — apprise (the source) and ntfy (the target) — using nothing but stacker pipe . You fire a payload, the pipe delivers it to ntfy's publish webhook, and you watch it land. Every command and every response below is from a real deployment. Co-locate two apps on one server so the agent can wire them together Create a pipe with manual endpoints — apprise has no auto-discoverable API Activate, trigger with a JSON payload, and confirm delivered: true Verify the delivery independently with curl Quick Answer stacker pipe create app ntfy \ --source-endpoint "GET /status" \ --target-endpoint "POST /pipetest" \ --source-fields message \ --target-fields message \ --name apprise-to-ntfy stacker pipe activate --trigger manual stacker pipe trigger --data '{"message":"hello from the pipe"}' The payload lands on ntfy's pipetest topic. No discovery, no HTTPS, no scripts. Why apprise → ntfy Needs Manual Endpoints Stacker's pipe discovery scans running containers for OpenAPI specs, HTML forms, and REST APIs at standard paths. apprise exposes none of those, so it can't be a pipe source through discovery. That's exactly what manual endpoints are for: you name the source and target endpoints yourself, and discovery is skipped entirely. Any app — or any HTTP URL — becomes pipeable. Step 1: Deploy Both Apps on One Server A pipe connects apps on the same server (the agent resolves each container by its my.stacker.service label). The simplest way is one project with two services — apprise as the main app, ntfy as a service: name: pipe-webhook-demo project: identity: pipe-webhook-demo # SOURCE — apprise notification gateway app: type: custom image: caronc/apprise:latest ports: ["8000:8000"] environment: APPRISE_STATEFUL_MODE: enabled services: # TARGET — ntfy webhook sink (POST /{topic} publishes) - name: ntfy image: binwiederhier/ntfy:latest command: serve ports: ["8080:80"] environment: NTFY_AUTH_DEFAULT_ACCESS: "read-write" proxy: type: none deploy: target: server cloud: provider: hetzner region: fsn1 size: cpx22 public_ports: ["8000", "8080"] volumes: apprise_config: {} ntfy_data: {} stacker deploy --target cloud --force-new After it comes up, both containers are running side by side: project-app-1 caronc/apprise:latest project-ntfy-1 binwiederhier/ntfy:latest Step 2: Create the Pipe with Manual Endpoints apprise is the source ( app ), ntfy is the target. The target endpoint is ntfy's publish webhook, POST /pipetest . We map a single message field through: stacker pipe create app ntfy \ --source-endpoint "GET /status" \ --target-endpoint "POST /pipetest" \ --source-fields message \ --target-fields message \ --name apprise-to-ntfy --json Discovery is skipped and the pipe is created immediately: Using source GET /status — manual endpoint Using target POST /pipetest — manual endpoint Manual endpoints — building field mapping from provided fields. "id": "eeba4c8e-9c1e-4db4-bf79-e82f4c3fb8a5", "field_mapping": { "message": "$.message" }, "source_container": "app", "target_container": "ntfy", "status": "draft" Step 3: Activate and Fire It stacker pipe activate eeba4c8e-… --trigger manual # ✓ completed stacker pipe trigger eeba4c8e-… --data '{"message":"hello from the apprise->ntfy pipe"}' # ✓ completed delivered: true trigger_count: 1 The execution log confirms it: stacker pipe history eeba4c8e-… # EXECUTION ID TRIGGER STATUS DURATION # 78bbf89e-… manual ✓ success 0ms stacker pipe list # eeba4c8e-… app → ntfy ● active triggers=1 errors=0 Step 4: Verify the Delivery with curl A pipe just POSTs the mapped payload to the target endpoint — here, ntfy's POST /{topic} . You can confirm it landed by reading the topic. ntfy serves published messages as JSON: curl -s "http:// :8080/pipetest/json?poll=1" {"event":"message","topic":"pipetest", "message":"{\"message\":\"hello from the apprise->ntfy pipe\"}"} The payload the pipe delivered is right there on the topic. You can reproduce the pipe's raw HTTP call by hand, too: # exactly what the pipe does under the hood — POST to ntfy's webhook curl -s -d '{"message":"manual curl check"}' http:// :8080/pipetest And sanity-check both ends of the pipe independently: curl -sI http:// :8000/ # apprise UI → HTTP 200 curl -s http:// :8080/v1/health # ntfy → {"healthy":true} Why No Proxy or HTTPS? The pipe delivers container-to-container over the internal Docker network — http://project-ntfy-1:80/pipetest — never through the public edge. ntfy's "requires HTTPS" note only applies to external and mobile-app usage; internal POST /{topic} publishing works over plain HTTP. So there's nothing to terminate and no certificate to manage for the pipe itself. (If you want ntfy reachable over HTTPS for real external clients, add proxy: type: caddy — but that's orthogonal to the pipe.) How Field Mapping Works Here With manual endpoints, fields map source → target by name first, then position , then identity . We passed --source-fields message and --target-fields message , so the mapping is simply message ← $.message . Leave --target-fields off and you get a pass-through of the whole payload. Going Further (Stacker 0.3.2) Two upgrades make this pipe production-ready and reproducible. Add a retry policy and a failure handler Attach retries and lifecycle handlers right at creation — they're stored in the pipe's config so the runtime honors them: stacker pipe create app ntfy \ --source-endpoint "GET /status" --target-endpoint "POST /pipetest" \ --source-fields message --target-fields message \ --name apprise-to-ntfy \ --retry 5 --retry-backoff-ms 500 \ --on-failure oncall-notify # run another pipe if delivery keeps failing Declare it in stacker.yml instead (Infrastructure-as-Code) Rather than a long imperative command, commit the pipe to your config and reconcile it: pipes: - name: apprise-to-ntfy source: app target: ntfy source_endpoint: "GET /status" target_endpoint: "POST /pipetest" source_fields: [message] target_fields: [message] retry: 5 on_failure: oncall-notify stacker pipe diff # preview: create / update / unchanged / orphan stacker pipe apply # create declared-but-missing pipes (idempotent) # stacker pipe apply --prune # also delete pipes not in stacker.yml Now the pipe is version-controlled, reviewable, and reproducible across environments. Frequently Asked Questions Do both apps have to be running to create the pipe? The manual-endpoint create is a template — it doesn't probe the apps. But delivery does need the target reachable on the server, so both containers should be up when you trigger. Why does the ntfy message look like raw JSON? ntfy treats a topic POST body as the message text, so it publishes the JSON payload verbatim. That's expected — the pipe delivered exactly what you sent. Can I trigger it automatically instead of manually? Yes — stacker pipe activate --trigger webhook fires on incoming data, and --trigger poll --poll-interval checks on a schedule. We used manual here for a deterministic, one-shot test. Key Takeaways Manual endpoints ( --source-endpoint / --target-endpoint ) pipe any app, even without a discoverable API A pipe is just a mapped POST to the target endpoint — verify it with a plain curl against the topic Delivery is internal (container-to-container), so no proxy or HTTPS is needed for the pipe Co-locate source and target on one server; the agent resolves them by their my.stacker.service labels --name plus explicit endpoints make the whole flow non-interactive and scriptable

A real, end-to-end Stacker PIPE example: wire apprise to ntfy as a webhook using manual endpoints, trigger it, and verify delivery with curl. No endpoint discovery, no HTTPS, no glue scripts.

apprise → ntfy: A Real Webhook Pipe with Stacker PIPE

What You'll Learn How to keep an eye on your running Docker containers using nothing but the stacker CLI — check health, stream logs, read deploy events, restart a stuck container, and even hand your logs to an AI for a diagnosis. No Grafana to run, no Portainer to expose, no browser open. Just your terminal and an SSH-native workflow. See live container state (CPU, memory, up/down) remotely Stream and filter logs from the command line Find out why a deploy paused or a container crashlooped Feed logs to an AI — including a fully local, private model Script it all into alerts, aliases, and cron jobs Quick Answer stacker status # is the deployment up? IP, services, health stacker agent health # live per-container CPU% / MEM% / state stacker logs -f --tail 100 # stream container logs stacker deployment events # why did it pause / fail? stacker agent logs app --limit 200 | stacker ai ask "why is this crashing?" Five commands, zero web UIs. Everything below expands on these. Why Monitor From the CLI? A web dashboard is another service you have to run, expose, secure, and keep updated — just to answer "is my container healthy?" On a small server that's a lot of overhead for a yes/no question. The CLI is SSH-native, works over a slow link, returns machine-readable JSON you can pipe into scripts, and never opens a port you didn't already need. And because the answers are text, you can hand them straight to an AI. The Mental Model A Stacker deployment is a set of services (containers) on a server. A small Status Panel agent runs alongside them and answers CLI queries over the message bus — so stacker agent … reads live container state without a browser or an exposed dashboard. Two families of commands: stacker status / stacker deployment … — deployment-level state from the API stacker agent … — live container health, logs, and control, straight from the agent on the box Step 1: Is It Up? — stacker status stacker status Shows the deployment state, public IP, each service and its ports, and the emergency SSH line: ✓ Deployment #849 — status: completed IP: 178.105.97.168 ── Services ── • app (ports: 8000:8000) • ntfy (ports: 8080:80) Two flags make it a daily driver: stacker status --watch — live refresh, with a terminal notification when the deployment reaches a terminal state. stacker status --json — machine-readable output for scripts (see the automation section). Step 2: Live Container Health — stacker agent health This is the remote equivalent of docker stats — per-container state, CPU, and memory, without SSHing in: stacker agent health Overall: ▶ running CONTAINER STATE CPU% MEM% IMAGE project-app-1 ▶ running 0.2 2.8 caronc/apprise:latest project-ntfy-1 ▶ running 0.0 0.3 binwiederhier/ntfy:latest statuspanel ▶ running 0.0 0.1 trydirect/status:latest Related views: stacker agent status — agent + container status for the deployment stacker agent containers — every container on the server stacker agent apps — apps deployed for the target stacker agent history — an audit trail of agent commands Step 3: Logs, From the Terminal Two ways to read logs — the local-friendly logs and the agent-fetched agent logs : stacker logs -f # follow/stream stacker logs --tail 200 # last 200 lines stacker logs --since 2h # last two hours stacker logs --service ntfy # one service only stacker agent logs app --limit 200 # pull N lines via the agent Step 4: Why Did It Pause or Fail? — stacker deployment events When a deploy pauses, the generic status line rarely tells the whole story. The structured event log does: stacker deployment events # role-level, timestamped events stacker deployment state # canonical deployment state This is where you find the real cause — a port already in use, a cloud quota ( resource_limit_exceeded ), an Ansible role that failed — rather than a wrapped "internal error." Make this your first stop for a stuck deployment. Step 5: Act On It — restart , deploy-app stacker agent restart # bounce a wedged container stacker agent deploy-app --app --image --tag stacker agent exec ... # raw agent command (advanced) Config-Driven Health: the monitoring: Block Turn on the agent and healthchecks declaratively in stacker.yml : monitoring: status_panel: true healthcheck: endpoint: /health interval: 30s metrics: telegraf: true # and per-service container healthchecks: services: - name: api image: myorg/api:latest healthcheck: test: "CMD curl -f http://localhost:8000/health || exit 1" interval: 30s timeout: 5s retries: 3 These feed the state you see in status and agent health — the CLI just reports what the healthchecks decide. The Differentiator: AI Analysis From the CLI Because every command returns text, you can pipe it straight into an AI for a diagnosis. No copy-paste into a chat window: stacker agent logs app --limit 200 | stacker ai ask "why is this container crashing?" # or attach a file: stacker ai ask "diagnose this" --context ./logs.txt Pick your provider in stacker.yml — and note the privacy angle for a monitoring workflow: ai: enabled: true provider: ollama # local model — your logs never leave the server model: qwen2.5-coder endpoint: http://localhost:11434 timeout: 0 tasks: [troubleshoot, security] Anthropic and OpenAI work too ( provider: anthropic|openai with api_key: ${VAR} ), but Ollama keeps every log line on your own box — exactly what you want when the "data" is your production logs. You can also run stacker ai --write to let a tool-capable model propose a fix to stacker.yml or .stacker/ . A Real Example: a Crashlooping Container Here's the workflow end-to-end on an app that wouldn't stay up. First, health flags it: stacker agent health # project-app-1 ⏸ Restarting (1) ghcr.io/dagucloud/dagu:latest Then the logs show the smoking gun: stacker agent logs app --limit 40 # Error: failed to create Wiki store: mkdir /var/lib/dagu/dags/wiki: permission denied # ERROR Failed to create example DAG … open /var/lib/dagu/dags/…: permission denied Hand it to the AI: stacker agent logs app --limit 40 | stacker ai ask "why does this container keep restarting?" …and the diagnosis is immediate: the named volume is created root-owned , but the image runs as a non-root user, so it can't write its data directory. The fix is a volume-ownership tweak ( user: or an init that chown s the path) — not an app bug. You found it, diagnosed it, and know the fix, all from the terminal. Living With It: Scripting & Alerts The --json outputs turn monitoring into one-liners: # alert if any container isn't running # (agent health --json is an array of {name, status, cpu_pct, mem_pct, …}) stacker agent health --json 2>/dev/null \ | jq -e 'all(.[]; .status == "running")' >/dev/null \ || echo "⚠️ a container is down" # handy aliases alias sst='stacker status' alias sh='stacker agent health' alias slog='stacker logs -f --tail 100' # cron: check every 5 minutes, notify on trouble */5 * * * * stacker status --json | jq -e '.status=="completed"' >/dev/null \ || curl -d "deploy unhealthy" ntfy.example.com/alerts Pair it with a healthcheck gate in CI ( stacker ci ), and route failures to Slack or ntfy — you can even wire that last hop with a Stacker PIPE . Alert When a Container Goes Down New in Stacker 0.3.2: a built-in stacker monitor command does exactly this. Add a monitoring.alerts block to stacker.yml and it watches container health, firing an alert once when a container stops and once when everything recovers (edge-triggered — no repeat spam): monitoring: status_panel: true alerts: interval: 30 on_recovery: true target: terminal: true # terminal + desktop notification # url: "https://ntfy.example.com/alerts" # or an HTTP webhook # method: POST stacker monitor # loop every `interval` seconds stacker monitor --once # single check — ideal for cron # stop a container → the next check alerts: # ● ⚠️ container problem: 1 not running (project-ntfy-1) # 🔔 Stacker container alert: ⚠️ container problem: 1 not running (project-ntfy-1) Alert state is persisted to .stacker/monitor.state , so one-shot --once runs stay edge-triggered across cron invocations. Targets can be a terminal/desktop notification, an HTTP webhook (ntfy, Slack), or (soon) a Stacker pipe. The manual recipe (still handy, and how it works under the hood) Before the built-in command — or if you want full control — you can build the same thing from agent health --json . A plain cron check fires every run while something is down, so make it edge-triggered to notify once on drop and once on recovery: #!/usr/bin/env bash # container-watch.sh — notify on state CHANGE only (no spam) STATE=/tmp/stacker-health.state if stacker agent health --json 2>/dev/null \ | jq -e 'all(.[]; .status == "running")' >/dev/null; then now=up else now=down fi prev=$(cat "$STATE" 2>/dev/null) if [ "$now" != "$prev" ]; then [ "$now" = down ] && msg="⚠️ a container is DOWN" || msg="✅ all containers recovered" curl -s -d "$msg" https://ntfy.example.com/alerts # or Slack / email echo "$now" > "$STATE" fi # check every 2 minutes */2 * * * * /usr/local/bin/container-watch.sh Swap the curl for your channel of choice — Slack webhook, an SMTP one-liner, or route it through a Stacker PIPE to ntfy. Want per-container granularity? Change the jq to emit the offenders: stacker agent health --json 2>/dev/null \ | jq -r '.[] | select(.status != "running") | .name' # → project-app-1 Troubleshooting Playbook Symptom Command sequence App unreachable stacker status (public_ports open?) → stacker agent health (container up?) → stacker agent logs → stacker ai ask Deploy paused / "internal error" stacker deployment events (real cause) → stacker deployment state Container crashlooping stacker agent health → stacker agent logs app --limit 200 → pipe to stacker ai ask → stacker agent restart High CPU/memory stacker agent health (CPU% / MEM%) → stacker logs --since 1h Frequently Asked Questions Do I need to install anything on the server? Set monitoring.status_panel: true and Stacker installs the agent during deploy. On an existing server, stacker agent install adds it. Does agent health require SSH each time? No — it talks to the on-box agent over the message bus. SSH is only the emergency fallback ( stacker status prints the exact line). Will sending logs to AI leak my data? Only if you choose a hosted provider. With provider: ollama the model runs locally and your logs never leave the server. Can Stacker notify me automatically when a container goes down? Yes, as of Stacker 0.3.2 — add a monitoring.alerts block and run stacker monitor (see above). It edge-triggers a terminal/desktop notification or webhook when a container stops and again when it recovers. On older versions, wire the same behavior with the agent health --json + cron script above. Can I get JSON for my own dashboards/scripts? Yes — --json is available on status , agent health , and more. Pipe into jq . Key Takeaways status → agent health → logs → deployment events covers 90% of day-to-day monitoring — no web UI The Status Panel agent answers live queries over the bus; SSH is only a fallback Every command is text, so stacker ai ask can diagnose logs directly — locally with Ollama for full privacy --json | jq turns monitoring into alerts, aliases, and cron in a few lines When a deploy is stuck, stacker deployment events is where the real cause lives

Monitor your Docker containers entirely from the command line with Stacker — live health, logs, events, and AI-powered troubleshooting. No web UI to host or secure. Full guide with real examples.

Monitor Your Docker Containers from the Command Line with Stacker

The Integration Problem You found the perfect self-hosted stack. App A stores your data. App B handles your workflow. But there is no plugin, no Zapier trigger, and the only integration option is a $50/mo SaaS connector that routes your data through someone else's servers. This is the reality for most self-hosted applications. Directus, Plausible, Outline, NocoDB, Ghost — all have solid APIs, but none appear in Zapier's 7,000-app catalog. When you need these apps to talk to each other, you are left writing curl scripts, managing cron jobs, and debugging JSON parsing errors at 2am. Three Scenarios Where This Hurts No plugin exists. Your app is niche, self-hosted, or too new. Zapier, Make, and n8n have no pre-built connector. The API exists but nobody has wrapped it. Only the cloud version is supported. The integration platform supports the SaaS version of your app, but you are running self-hosted. The connector does not work with your instance. The "integration" costs more than the apps. A third-party connector charges $50-200/mo for what amounts to a webhook relay. You are paying more for the glue than for the tools themselves. What Are Stacker PIPEs? A PIPE is a CLI-native data bridge between any two HTTP services. It runs entirely on your infrastructure — the Stacker agent fetches data from a source endpoint, applies field mapping, and delivers it to a target endpoint. Three commands: create, activate, trigger. No SaaS dependency, no per-execution fees, no data leaving your server. Why PIPEs Over Zapier? 1. Zero Per-Task Cost Zapier charges per "task" — each data transfer counts. Make charges per "operation." n8n Cloud charges per workflow execution with monthly limits. A moderately busy app processing 10,000 form submissions or webhook events per month can cost $100-500 on these platforms. Stacker PIPEs run on your own infrastructure with no per-execution fees. The only cost is the server you already pay for. For high-volume integrations, this eliminates the primary cost driver of cloud integration platforms entirely. 2. Data Never Leaves Your Infrastructure Zapier and Make route all data through their servers. Even n8n's self-hosted option requires their cloud for certain features. Stacker PIPEs execute entirely within your Docker network — the agent fetches from source containers and pushes to target containers using internal IPs. No third party sees your data in transit. This matters for healthcare, finance, GDPR-regulated workloads, or any scenario where "we don't want our data on someone else's server" is a requirement, not a preference. 3. Works with Internal Docker Network Services Zapier and Make can only reach publicly accessible APIs. They cannot connect to services running on internal Docker networks — a Directus instance on port 8055 inside a container, a PostgREST endpoint, or a Kong gateway route. Stacker PIPEs operate at the container level. They reach services by Docker DNS name ( plausible:8000 , directus:8055 ) without requiring public exposure. No need to open ports, configure reverse proxies, or generate API keys for external access. 4. Any HTTP Endpoint, No Connector Needed Zapier has 7,000+ pre-built connectors. If your app is not among them, you cannot integrate it without writing custom code steps. Make has fewer. n8n requires building custom HTTP Request nodes. Stacker PIPEs work with any HTTP endpoint. You specify the source path ( GET /api/v1/stats ) and the target path ( POST /api/v1/conversations ) and it works — regardless of whether the API follows OpenAPI conventions or uses custom routing like Directus at /items/* or Chatwoot at /api/v1/* . Example: Plausible Analytics to Slack Plausible is a privacy-first analytics tool with a clean REST API — but no Zapier connector, no Make integration, and no n8n node. If you want to send Plausible pageview data to Slack when a blog post hits a traffic threshold, your options are: write a custom script, or use Stacker PIPEs. Architecture ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ Plausible │ │ Stacker │ │ Slack │ │ Analytics │ │ Agent │ │ Webhook │ └──────┬────────┘ └──────┬──────┘ └──────┬───────┘ │ │ │ │ GET /api/v1/ │ │ │ stats/realtime │ │ │◄───────────────────│ │ │ │ Field mapping │ │ │ ($.results) │ │ │ │ │ │ POST /webhook │ │ │───────────────────►│ Three Commands # 1. Create the pipe stacker pipe create plausible slack --name "plausible-alerts" # 2. Activate — tell the agent where to fetch and where to deliver stacker pipe activate # 3. Trigger — fetch data and deliver it stacker pipe trigger --data '{"page":"/blog/my-post","visitors":1000}' The agent fetches pageview data from Plausible's API, maps the relevant fields, and POSTs the payload to the Slack webhook. No scripts, no cron jobs, no third-party service seeing your analytics data. The Trade-offs Stacker PIPEs are not a drop-in replacement for Zapier. They serve a different audience and solve a different problem. Here is what you give up: CLI comfort required. PIPEs are created via command line. There is no browser-based visual editor. If your team is not comfortable with a terminal, this is not the right tool. No visual workflow builder. Zapier and Make support multi-step workflows with branching, filtering, delays, and conditional logic. PIPEs are point-to-point: source endpoint, field mapping, target endpoint. No branching, no multi-step chains. No pre-built connectors. Every integration requires manual endpoint specification and field mapping. There is no marketplace of shared pipe configurations or community-contributed templates. Endpoint discovery is incomplete. The agent's automatic endpoint discovery only finds APIs at standard paths ( /api , /openapi.json ). Apps with non-standard paths require manual specification. When to Use What Use Case Best Tool Non-technical team, simple webhooks between popular SaaS apps Zapier Visual workflows with branching, delays, and error handling Make or n8n Self-hosted stack, data privacy requirements, high volume Stacker PIPEs Internal Docker services that should not be exposed publicly Stacker PIPEs Apps with no Zapier/Make connector and non-standard APIs Stacker PIPEs Full Comparison Dimension Stacker PIPEs Zapier Make n8n Pricing Flat (server only) Per-task Per-operation Per-execution (cloud) or free (self-hosted) Data privacy Your infra Their servers Their servers Self-host option Internal Docker access Yes No No Yes (self-hosted) Setup CLI required Browser Browser Browser Visual builder No Yes Yes Yes Multi-step workflows No (point-to-point) Yes Yes Yes Custom APIs Any HTTP Webhooks only HTTP module HTTP Request node Vendor lock-in Low (standard HTTP) High High Low (OSS) Key Takeaways PIPEs are the integration layer for teams already self-hosting with Stacker — the audience that has rejected SaaS for deployment should also reject SaaS for integration. Zero per-task pricing eliminates the cost surprise of Zapier and Make for high-volume workloads. Data never leaves your infrastructure — critical for privacy-sensitive workloads in healthcare, finance, or GDPR-regulated environments. Works with any HTTP API, no connector dependency. If the app has an API, PIPEs can connect to it. Further Reading How to Connect Any Two Apps with Stacker PIPEs - Manual Endpoint Guide Connect Directus to Any Service with Stacker PIPEs Stacker PIPE Execution Deep Dive - Debugging Cross-Container Data Pipelines For full PIPE documentation, see the Stacker docs .

Why Stacker PIPEs beat Zapier for self-hosted integrations. Zero per-task cost, data privacy, internal Docker network access, any HTTP endpoint.

No Plugin for Your App? Why Stacker PIPEs Beat Zapier for Self-Hosted Integrations

What You'll Learn How to connect any two self-hosted applications with a Stacker PIPE using manual endpoint specification. This approach works even when apps aren't running - no endpoint discovery required. Create pipes with explicit source and target endpoints Map data fields between different APIs Activate, trigger, and monitor pipe execution Troubleshoot common pipe errors Quick Answer stacker pipe create \ --source-endpoint "METHOD /path" \ --target-endpoint "METHOD /path" \ --source-fields field1,field2 \ --target-fields field1,field2 \ --name "my-pipe" Creates a pipe in seconds. Works with any HTTP API. Why Manual Endpoints? Stacker's endpoint discovery scans running containers for OpenAPI specs, HTML forms, and REST API patterns. But not all apps expose standard paths. Apps like Directus (at /items/* ) or Chatwoot (at /api/v1/* ) use non-standard routes that the probe doesn't find. Manual endpoint specification bypasses discovery entirely. You tell the pipe exactly where to fetch and where to deliver - no scanning, no guessing, no running containers required. Step 1: Create the Pipe Define the source endpoint (where data comes from) and target endpoint (where data goes): 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 creates a pipe template that maps name , email , and message from Directus to content in Chatwoot. Step 2: Activate the Pipe stacker pipe list # get the pipe ID stacker pipe activate # start listening for data Step 3: Trigger and Test stacker pipe trigger --data '{"name":"Test","email":"test@example.com","message":"Hello!"}' stacker pipe history # view execution log Supported Endpoint Formats Method + path: POST /api/v1/items - specifies HTTP method and path Bare path: /api/v1/items - defaults to GET How Field Mapping Works When you specify --source-fields and --target-fields , the pipe maps fields by position. The first source field maps to the first target field, and so on. # Source: name, email, message # Target: content # Result: all three source fields are combined into the "content" target field For more complex transformations, use JSONPath expressions with the source_url activation method. Example: Directus to Chatwoot When a new item is created in Directus, send a message to Chatwoot: # Create the pipe 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" # Activate stacker pipe activate # Test with sample data stacker pipe trigger --data '{ "name": "Jane Doe", "email": "jane@example.com", "message": "I need help with my order" }' # Check execution log stacker pipe history Benefits of Manual Endpoints No discovery required - works even when apps aren't running No agent dependency - bypasses endpoint discovery limitations Immediate - create pipes in seconds Flexible - works with any HTTP API endpoint Portable - same pipe works across environments Troubleshooting "Not a terminal" error Use the --name flag to skip interactive prompts. The pipe create command defaults to an interactive name prompt that fails in scripts. "Authentication token expired" error Run stacker login to refresh your session before running pipe commands. Fields not matching Use --source-fields and --target-fields to explicitly specify field names. Position-based mapping requires the same number of fields on both sides. Frequently Asked Questions Can I create pipes without running containers? Yes. Manual endpoint specification doesn't require the apps to be running. The pipe is a template that activates when the apps are available. What HTTP methods are supported? Any standard HTTP method: GET, POST, PUT, PATCH, DELETE. Specify it in the endpoint string (e.g., POST /api/v1/items ). How do I map fields with different names? Use --source-fields and --target-fields to map by position. For JSONPath-based mapping, use the source_url activation method. Can I use this with APIs that require authentication? Yes. Use --target-header "Authorization: Bearer " when activating or triggering the pipe. Key Takeaways Manual endpoints work without running containers or endpoint discovery Use --name flag to avoid interactive prompts in scripts Field mapping is position-based - match source fields to target fields Works with any HTTP API, any method, any authentication scheme Pipes are reusable - activate once, trigger as needed

Connect any two self-hosted apps with Stacker PIPEs using manual endpoint specification. No discovery required - create data pipelines between Directus, Chatwoot, WordPress, and any HTTP API in seconds.

How to Connect Any Two Apps with Stacker PIPEs - Manual Endpoint Guide

What You'll Build A reusable data pipeline that fetches content from Directus, transforms it with JSONPath field mapping, and delivers it to any HTTP endpoint - all managed with three CLI commands. No curl scripts, no cron jobs, no custom code. Directus as a data source (headless CMS) Any HTTP endpoint as a target (Chatwoot, Slack, CRMs, webhooks) JSONPath-based field transformation Auth header support for protected APIs Quick Answer # 1. Activate the pipe stacker pipe activate \ --source-url "http://directus:8055/items/pages" \ --trigger manual \ --target-header "Authorization: Bearer " # 2. Trigger data transfer stacker pipe trigger --json # 3. List active pipes stacker pipe list --json Three commands. Data flows from Directus to any HTTP endpoint. Why Use Stacker PIPEs Instead of Custom Scripts? Every SaaS product eventually faces the same problem: data trapped in one system needs to reach another. Directus holds your content. Chatwoot handles your conversations. Slack gets your notifications. Each has an API. Each needs data from the others. The traditional approach requires writing a bash script with curl -X POST , parsing JSON with jq , handling auth tokens, scheduling with cron, and fixing it when it breaks. Every integration becomes a fragile snowflake. Stacker PIPEs replace all of that with a composable, reusable data connection. Define the source, target, and mapping once - then trigger it with a single command. Prerequisites Stacker CLI installed ( cargo install stacker-cli ) A deployed Stacker project with Directus running An agent registered and connected to the dashboard # Verify agent is connected stacker agent health --deployment Step 1: Create the Pipe Instance Create a pipe instance through the Stacker API or dashboard. This registers the pipe in the Stacker database and returns a unique pipe_instance_id . curl -X POST "https://stacker.try.direct/api/v1/pipes/instances" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer " \ -d '{ "name": "directus-to-webhook", "source_type": "http", "target_type": "http" }' Step 2: Activate the Pipe on the Agent Activation tells the agent where to fetch data from and where to send it. The agent handles HTTP requests across Docker networks, auth headers, JSONPath transformation, and error reporting. stacker pipe activate \ --source-url "http://project-directus-1:8055/items/pages" \ --trigger manual \ --target-header "Authorization: Bearer " \ --deployment Verify the pipe is active: stacker pipe list --json --deployment Step 3: Trigger the Pipe Fetch data from Directus and deliver it to the target endpoint. You can filter data using Directus query parameters. stacker pipe trigger \ --source-url "http://project-directus-1:8055/items/pages?filter[status][eq]=published" \ --target-header "Authorization: Bearer " \ --json \ --deployment What Happens Under the Hood Agent fetches source - HTTP GET to the Directus endpoint, receiving JSON data Field mapping applied - JSONPath expressions transform the data (e.g., $.data[0].title extracts the first item's title) Delivery to target - HTTP POST to the target endpoint with auth headers and mapped data Step 4: Check the Result The JSON output includes the full execution status: { "command_id": "cmd_abc123...", "status": "completed", "result": { "success": true, "source_data": { "data": [ {"id": 1, "title": "Hello World", "status": "published"} ] }, "mapped_data": { "content": "Hello World" }, "target_response": { "status": 200, "delivered": true, "transport": "http" } } } Real-World Examples Sync Directus Content to Chatwoot stacker pipe activate \ --source-url "http://project-directus-1:8055/items/knowledge_base" \ --trigger manual \ --target-header "Authorization: Bearer " \ --deployment stacker pipe trigger \ --source-url "http://project-directus-1:8055/items/knowledge_base?filter[category][eq]=faq" \ --json \ --deployment Send Directus Notifications to Slack stacker pipe activate \ --source-url "http://project-directus-1:8055/items/notifications" \ --trigger manual \ --target-header "Authorization: Bearer " \ --target-header "Content-Type: application/json" \ --deployment stacker pipe trigger \ --source-url "http://project-directus-1:8055/items/notifications?filter[read][eq]=false" \ --json \ --deployment Push Directus Changes to an External API stacker pipe activate \ --source-url "http://project-directus-1:8055/items/products" \ --trigger manual \ --target-header "X-API-Key: " \ --deployment stacker pipe trigger \ --source-url "http://project-directus-1:8055/items/products?filter[updated_at][gt]=2026-01-01" \ --json \ --deployment Why source_url Changes Everything Before source_url , pipes required source_container - the agent had to be on the same Docker network as the source service. This meant complex network configuration and no support for authenticated APIs. With source_url : Agent fetches any HTTP endpoint directly Works across Docker networks Supports target_headers for authentication No curl needed - everything through stacker pipe Troubleshooting "Source fetch failed with status 403" Directus requires authentication. Add the admin token to the source URL or configure Directus public role permissions for read access. "Target request failed with status 404" The target endpoint path is incorrect. Double-check the API path - for Chatwoot, ensure you include the account ID: /api/v1/accounts/ /conversations . "Pipe instance ID is not active on this agent" Activate the pipe first with stacker pipe activate before triggering. Architecture Overview ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ Directus │ │ Stacker │ │ Target │ │ │ │ Agent │ │ Service │ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ │ │ │ HTTP GET │ │ │◄───────────────────│ │ │ (source_url) │ │ │ │ field_mapping │ │ │ (JSONPath) │ │ │ │ │ │ HTTP POST │ │ │ (target_headers) │ │ │───────────────────►│ Frequently Asked Questions Can I use Stacker PIPEs without Directus? Yes. PIPEs work with any HTTP source - Directus is just one example. You can fetch data from any REST API, CMS, or webhook endpoint. Do PIPEs require the agent to be on the same Docker network? With source_url , no. The agent fetches any HTTP endpoint directly. The older source_container method required network proximity. How do I schedule recurring pipe triggers? Use --trigger poll with an interval when activating the pipe. The agent will check for new data at the specified cadence. What authentication methods are supported? Pass any header with --target-header . Bearer tokens, API keys, basic auth - any HTTP header works. Key Takeaways Stacker PIPEs replace custom curl scripts with three CLI commands source_url enables cross-network, authenticated API integration JSONPath field mapping transforms data without custom code Works with Directus, Chatwoot, Slack, or any HTTP endpoint Pipes are reusable - activate once, trigger as needed

Learn how to connect Directus to any HTTP service using Stacker PIPEs. Fetch data from Directus, transform it with JSONPath, and deliver it to Slack, Chatwoot, or any webhook - no scripts needed.

Connect Directus to Any Service with Stacker PIPEs - No Scripts Required

What You'll Build A working data pipe between a Supabase stack (Kong + PostgREST) and a PostHog-compatible event receiver, deployed on Hetzner Cloud with Stacker. Events flow from Supabase through Kong to PostHog - all self-hosted. Supabase with Kong API gateway, PostgREST, Auth, Realtime, Storage PostHog-compatible event receiver Stacker PIPE connecting both services Deployed on Hetzner Cloud with status panel agent Quick Answer # Deploy the stack stacker deploy --target cloud --key htz-0 # Create the pipe stacker pipe create supabase-posthog posthog --manual # Test the connection curl -X POST http:// :8000/posthog/capture \ -H "Content-Type: application/json" \ -d '{"event":"test","properties":{"source":"pipe-demo"}}' Events flow from Supabase through Kong to PostHog. Prerequisites Stacker CLI installed and authenticated ( stacker login ) Hetzner cloud credentials configured ( stacker clouds ) Docker running locally (for image transfer if needed) Step 1: Create the Project stacker init supabase-posthog Set the project identity in stacker.yml : name: supabase-posthog project: identity: supabase-posthog Step 2: Define the Stack Configure Kong as the API gateway, Supabase services, and a PostHog-compatible event receiver in stacker.yml . app: type: custom image: kong/kong:3.9.1 ports: - "8000:8000" - "8443:8443" services: - name: db image: supabase/postgres:17.6.1.136 # ... database init, healthcheck, volumes - name: posthog image: python:3.11-alpine ports: - "8001:8000" volumes: - ./posthog-receiver/app.py:/app/app.py:ro command: python /app/app.py Kong Route Configuration Create kong.yml with upstream timeouts to avoid probe hangs. Without explicit timeouts, Kong defaults to 60 seconds per upstream operation - probes hitting a down service would hang for the full duration. services: - name: rest-v1 url: http://rest:3000 connect_timeout: 5000 write_timeout: 5000 read_timeout: 5000 routes: - name: rest-all paths: - /rest/v1/ - name: posthog-v1 url: http://posthog:8000 connect_timeout: 5000 write_timeout: 5000 read_timeout: 5000 routes: - name: posthog-capture paths: - /posthog/ Step 3: Deploy to Cloud stacker deploy --target cloud --key htz-0 Stacker provisions a Hetzner server, installs Docker and the status panel agent, copies the config bundle, and starts all containers. After deployment completes, verify everything is running: stacker status stacker agent status stacker agent containers All services should show running . If some are restarting , check their logs: stacker agent logs rest --limit 20 Step 4: Create the Pipe The pipe connects Supabase PostgREST (source) to PostHog's /capture endpoint (target). First, scan for endpoints - note the probe takes 3-5 minutes, so the CLI timeout may need extending. # Using pipe scan (may time out if probe takes long) stacker pipe scan --app supabase-posthog # Alternative: use agent exec with a longer timeout stacker agent exec probe_endpoints \ --params '{"app_code":"supabase-posthog","capture_samples":true}' \ --timeout 600 --json Then create the pipe: stacker pipe create supabase-posthog posthog --manual Step 5: Test the Pipe Verify the PostHog receiver accepts events: # Direct to PostHog curl -X POST http:// :8001/capture \ -H "Content-Type: application/json" \ -d '{"event":"test","properties":{"source":"pipe-demo"}}' # Through Kong gateway curl -X POST http:// :8000/posthog/capture \ -H "Content-Type: application/json" \ -d '{"event":"test","properties":{"source":"pipe-demo"}}' Check the PostHog logs to confirm receipt: stacker agent logs posthog --limit 10 # Expected: Received capture event: {"event": "test", "properties": {"source": "pipe-demo"}} Troubleshooting Probe Hangs or Times Out Most common cause: The remote docker-compose.yml is invalid - missing volume definitions, undefined networks, or file ownership issues. Run docker compose ps on the server to check. ssh trydirect@ cd /home/trydirect/project docker compose ps # Validate compose file docker compose config Probe Works but Endpoints Are Empty Check Kong upstream timeouts. If Kong's upstream connections hang (default 60s), the probe waits for each timeout. Set connect_timeout , write_timeout , read_timeout to 5000ms on all Kong services. Container Name Not Resolved The agent needs access to Docker and a valid compose file. Run docker compose ps directly on the server. If it errors with "refers to undefined network" or "refers to undefined volume", the compose file is broken. Agent Responds Slowly If the compose file is invalid, every agent operation that validates the compose will hang. Fix the compose file first, then restart the agent: ssh trydirect@ sudo docker compose -f /home/trydirect/statuspanel/docker-compose.yml up -d Verification Checklist stacker deployments shows all deployments stacker status shows last deployment status stacker agent containers lists all services as running stacker agent exec probe_endpoints returns endpoints with operations Direct curl to PostHog /capture returns {"status": "ok"} Events appear in stacker agent logs posthog Frequently Asked Questions Why use Kong as the API gateway? Kong routes traffic to multiple Supabase services (PostgREST, Auth, Realtime, Storage) through a single entry point. It also handles timeouts, rate limiting, and CORS. Can I use the real PostHog instead of a receiver? Yes. Replace the Python receiver with the official PostHog Docker image. The pipe endpoint remains the same - /capture . How do I extend the probe timeout? Use stacker agent exec probe_endpoints --timeout 600 for a 10-minute timeout. The default CLI timeout may be too short for complex stacks. Do I need to open firewall ports? Yes. After cloud deploy, open the ports you need: stacker cloud firewall add --public-ports 8000/tcp,8001/tcp . Key Takeaways Supabase + PostHog deploys as a single Stacker project Kong upstream timeouts must be set explicitly to avoid probe hangs Invalid compose files cause agent slowness - validate with docker compose config The pipe works through Kong gateway or directly to the PostHog receiver Source: github.com/trydirect/stacker

Connect Supabase and PostHog with a Stacker PIPE. Step-by-step guide to deploying the stack, configuring Kong API gateway, creating data pipes, and troubleshooting common issues.

Connect Supabase to PostHog with Stacker PIPEs - Complete Setup Guide

Check some deployment facilitation tips and tech howto's. Learn how to integrate popular technologies and their key features. Learn something new with TryDirect

Dashboard

TryDirect blog