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

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 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

OpenClaw went from a side project to hundreds of thousands of GitHub stars in months. It also went from zero to hundreds of malicious skills on its own marketplace in weeks. Both facts describe the same tool, and if you are planning to run it, you need to understand why.

OpenClaw connects to messaging apps like WhatsApp, Telegram, Discord, and Slack, reads local files, executes shell commands, and acts on your behalf across whatever services you connect it to.

OpenClaw is not unsafe by design, but its permission model makes a compromised instance far more damaging than typical software. The risks are well documented at this point: a supply-chain campaign called ClawHavoc placed 341 malicious skills on ClawHub, a critical remote-code-execution flaw (CVE-2026-25253) let attackers hijack instances through a single malicious link, and Cisco found that 26% of 31,000 scanned agent skills contained at least one exploitable vulnerability. None of that means the tool is unusable. It means safe deployment comes down to isolation, a locked-down firewall, skill vetting, and logging, not avoidance.

This guide covers what independent security researchers actually documented, why the risk is structural rather than a handful of bad skills, and a practical checklist for running OpenClaw without becoming the next case study.

Why OpenClaw Is a Different Kind of Security Risk

Most software vulnerabilities give an attacker a foothold. A compromised OpenClaw instance often gives an attacker the same permissions the agent already has, which for most users includes:

Read access to local files, and often to connected cloud storage

Live API keys and OAuth tokens for every connected service, from email and calendars to crypto wallets in some setups

The ability to install new skills on its own, if configured for autonomous operation

Skills, OpenClaw's extension mechanism, run with the same permissions as the agent itself. There is no sandbox boundary between "this skill checks the weather" and "this skill reads your browser's saved passwords." Security researchers have repeatedly shown that the two can look identical from the outside, and by design, ClawHub requires nothing more than a week-old GitHub account to publish a new one.

What the Security Research Actually Found

These incidents are documented by named security vendors and researchers, not rumor. Where sources disagreed on details, we've gone with the figures corroborated by multiple independent outlets.

The ClawHavoc supply chain attack. In February 2026, Koi Security audited all 2,857 skills then live on ClawHub and identified 341 malicious entries, roughly 12% of the registry. Of those, 335 were traced to a single coordinated campaign, now tracked as ClawHavoc, that used fake "prerequisite" install steps to deliver Atomic Stealer (AMOS) on macOS, a tool built to harvest browser passwords, crypto wallet keys, and session cookies. By later scans the count of flagged malicious skills had grown well past 800 as the registry itself expanded.

A critical remote code execution flaw. Tracked as CVE-2026-25253 and rated CVSS 8.8, this vulnerability let an attacker hijack a running OpenClaw instance and steal its authentication token simply by getting the victim to click a crafted link or visit a malicious page. It was patched within days of disclosure, but only for users who updated.

Widespread vulnerability rates across the wider skill ecosystem. Cisco's AI Defense team scanned roughly 31,000 agent skills across multiple frameworks, OpenClaw included, and found that about 26% contained at least one exploitable vulnerability: command injection, data exfiltration, or prompt injection.

Credential exposure at scale. Snyk's separate ToxicSkills audit scanned close to 4,000 ClawHub skills and found that 7.1% (283 skills) exposed sensitive credentials in plaintext, with 13.4% classified as containing critical-severity issues.

Scanners can be bypassed. Trail of Bits demonstrated that ClawHub's own malware-scanning pipeline could be defeated by padding a malicious skill file with roughly 100,000 blank lines, pushing the harmful code outside the window the scanner actually inspects. Comparable gaps were found in third-party scanning tools built specifically to catch this kind of threat.

Exposed instances at scale. Cisco has reported more than 135,000 OpenClaw instances reachable from the public internet, many running outdated, vulnerable versions.

The institutional response has been telling. China's government restricted state agencies, state-owned enterprises, and banks from running OpenClaw, citing risks around unauthorized data deletion, data leaks, and excessive resource usage. Multiple security vendors, including Cisco, report seeing similar internal restrictions inside enterprises as adoption grows.

The checklist below is what deploying it "deliberately, isolated, and monitored" actually looks like in practice.

How to Deploy OpenClaw Safely: A 7-Step Checklist

1. Never run it on a machine with unrelated sensitive access

Do not install OpenClaw on your daily laptop, especially one logged into personal email, banking, or production infrastructure. A dedicated VM, cloud instance, or container gives you a hard boundary between "if this agent is compromised" and "everything I own".

2. Default to deny on outbound network access

An agent that can only reach the specific APIs it needs is far less useful to an attacker than one with open egress to the entire internet. Configure your firewall for allowlisted outbound connections rather than blocklisting known-bad destinations after the fact.

3. Treat every third-party skill as untrusted code

Skills execute with full agent permissions the moment they are installed. Before adding anything from ClawHub:

Scan it with a dedicated tool built for this, such as Cisco's open-source skill-scanner, rather than relying on the marketplace's built-in check alone

Read the SKILL.md file and any bundled scripts yourself if the skill touches credentials, files, or network calls

Keep the total number of installed skills small; every skill is additional attack surface

Avoid one-click installs from public marketplaces in any environment connected to sensitive accounts

4. Keep credentials out of the agent's filesystem

Use a secrets manager or vault rather than letting OpenClaw store API keys and tokens in plaintext config files. Rotate tokens regularly, and scope each connected service to the minimum permissions the agent actually needs. If a skill only needs to read a calendar, it should not also hold write access to email.

5. Patch on a schedule, not when you remember

CVE-2026-25253 and similar flaws were fixed quickly once disclosed. The instances that got compromised were, overwhelmingly, ones running outdated versions. Update OpenClaw and its dependencies on a defined cadence, and subscribe to the project's security advisories.

If OpenClaw can act autonomously, you need an audit trail of what it acted on: which skills ran, which tool calls fired, which external destinations received data. Runtime monitoring is what turns "we think something went wrong three weeks ago" into "we caught this in under a minute".

7. Separate the agent from production infrastructure

If OpenClaw is managing DevOps tasks, deploying code, or touching infrastructure, give it a scoped service account rather than admin credentials, and route its actions through the same review gates you would require of a junior engineer.

Once the isolation and monitoring model above is in place, the remaining decision is infrastructure: a self-managed server, a cloud VM you harden by hand, or a preconfigured deployment.

TryDirect's marketplace includes an OpenClaw preconfigured stack, built by the StackDog Team, that deploys to Amazon EC2, DigitalOcean, or Hetzner Cloud with a firewall already configured. It is worth being direct about what that stack currently is and is not: the listing is explicitly labeled an experimental setup, and at the time of writing it has passed 3 of the marketplace's 8 verification checks. That is not unusual for a preconfigured stack built around a tool this new, but it does mean the firewall and isolation it ships with are a starting point, not a substitute for the credential hygiene, skill vetting, and monitoring practices above.

The advantage of deploying through a marketplace stack rather than a manual install is mainly speed and a consistent baseline: a fresh, isolated instance with networking pre-configured, rather than OpenClaw sharing a machine with other workloads by default. Whichever route you choose, self-hosted VM, containerized deployment, or a marketplace image, the checklist does not change. Isolation, a locked-down firewall, vetted skills, and real logging are what determine whether an OpenClaw deployment is a productivity tool or a liability.

Is OpenClaw safe to use? OpenClaw is not inherently unsafe, but its permission model, an agent with shell access, file access, and live credentials, means the consequences of a compromise are more severe than with typical software. Safety depends heavily on how it is deployed and which skills are installed, not just which version you run.

What is ClawHub and why does it matter for security? ClawHub is OpenClaw's community marketplace for skills, the packages that extend what the agent can do. Because anyone with a week-old GitHub account can publish and vetting has historically been limited, ClawHub was the primary vector for the ClawHavoc campaign and other malicious-skill incidents documented by Koi Security, Snyk, and Cisco.

Should I run OpenClaw on my personal computer? It is not recommended if that machine also holds sensitive personal accounts, saved passwords, or production credentials. A dedicated, isolated environment, whether a cloud VM, container, or preconfigured stack, limits the blast radius if something goes wrong.

Do skill scanners fully solve the malicious skill problem? No. Trail of Bits demonstrated bypasses against ClawHub's own scanning pipeline and several third-party scanners. Scanning is a useful first filter, not a guarantee, which is why limiting the number of installed skills and reviewing anything with credential or network access still matters.

Deploy OpenClaw on an isolated, firewall-configured instance in minutes with the OpenClaw preconfigured stack on TryDirect.

OpenClaw went from a side project to hundreds of thousands of GitHub stars in months. It also went from zero to hundreds of malicious skills on its own marketplace in weeks. Both facts describe the same tool, and if you are planning to run it, you need to understand why.

OpenClaw connects to messaging apps like WhatsApp, Telegram, Discord, and Slack, reads local files, executes shell commands, and acts on your behalf across whatever services you connect it to.

OpenClaw is not unsafe by design, but its permission model makes a compromised instance far more damaging than typical software. The risks are well documented at this point: a supply-chain campaign called ClawHavoc placed 341 malicious skills on ClawHub, a critical remote-code-execution flaw (CVE-2026-25253) let attackers hijack instances through a single malicious link, and Cisco found that 26% of 31,000 scanned agent skills contained at least one exploitable vulnerability. None of that means the tool is unusable. It means safe deployment comes down to isolation, a locked-down firewall, skill vetting, and logging, not avoidance.

This guide covers what independent security researchers actually documented, why the risk is structural rather than a handful of bad skills, and a practical checklist for running OpenClaw without becoming the next case study.

Why OpenClaw Is a Different Kind of Security Risk

Most software vulnerabilities give an attacker a foothold. A compromised OpenClaw instance often gives an attacker the same permissions the agent already has, which for most users includes:
Full shell access on the host machine
Read access to local files, and often to connected cloud storage
Live API keys and OAuth tokens for every connected service, from email and calendars to crypto wallets in some setups
The ability to install new skills on its own, if configured for autonomous operation

Skills, OpenClaw's extension mechanism, run with the same permissions as the agent itself. There is no sandbox boundary between "this skill checks the weather" and "this skill reads your browser's saved passwords." Security researchers have repeatedly shown that the two can look identical from the outside, and by design, ClawHub requires nothing more than a week-old GitHub account to publish a new one.

What the Security Research Actually Found

These incidents are documented by named security vendors and researchers, not rumor. Where sources disagreed on details, we've gone with the figures corroborated by multiple independent outlets.

The ClawHavoc supply chain attack. In February 2026, Koi Security audited all 2,857 skills then live on ClawHub and identified 341 malicious entries, roughly 12% of the registry. Of those, 335 were traced to a single coordinated campaign, now tracked as ClawHavoc, that used fake "prerequisite" install steps to deliver Atomic Stealer (AMOS) on macOS, a tool built to harvest browser passwords, crypto wallet keys, and session cookies. By later scans the count of flagged malicious skills had grown well past 800 as the registry itself expanded.

A critical remote code execution flaw. Tracked as CVE-2026-25253 and rated CVSS 8.8, this vulnerability let an attacker hijack a running OpenClaw instance and steal its authentication token simply by getting the victim to click a crafted link or visit a malicious page. It was patched within days of disclosure, but only for users who updated.

Widespread vulnerability rates across the wider skill ecosystem. Cisco's AI Defense team scanned roughly 31,000 agent skills across multiple frameworks, OpenClaw included, and found that about 26% contained at least one exploitable vulnerability: command injection, data exfiltration, or prompt injection.

Credential exposure at scale. Snyk's separate ToxicSkills audit scanned close to 4,000 ClawHub skills and found that 7.1% (283 skills) exposed sensitive credentials in plaintext, with 13.4% classified as containing critical-severity issues.

Scanners can be bypassed. Trail of Bits demonstrated that ClawHub's own malware-scanning pipeline could be defeated by padding a malicious skill file with roughly 100,000 blank lines, pushing the harmful code outside the window the scanner actually inspects. Comparable gaps were found in third-party scanning tools built specifically to catch this kind of threat.

Exposed instances at scale. Cisco has reported more than 135,000 OpenClaw instances reachable from the public internet, many running outdated, vulnerable versions.

The institutional response has been telling. China's government restricted state agencies, state-owned enterprises, and banks from running OpenClaw, citing risks around unauthorized data deletion, data leaks, and excessive resource usage. Multiple security vendors, including Cisco, report seeing similar internal restrictions inside enterprises as adoption grows.

The checklist below is what deploying it "deliberately, isolated, and monitored" actually looks like in practice.

How to Deploy OpenClaw Safely: A 7-Step Checklist

1. Never run it on a machine with unrelated sensitive access
Do not install OpenClaw on your daily laptop, especially one logged into personal email, banking, or production infrastructure. A dedicated VM, cloud instance, or container gives you a hard boundary between "if this agent is compromised" and "everything I own".

2. Default to deny on outbound network access
An agent that can only reach the specific APIs it needs is far less useful to an attacker than one with open egress to the entire internet. Configure your firewall for allowlisted outbound connections rather than blocklisting known-bad destinations after the fact.

3. Treat every third-party skill as untrusted code
Skills execute with full agent permissions the moment they are installed. Before adding anything from ClawHub:
Scan it with a dedicated tool built for this, such as Cisco's open-source skill-scanner, rather than relying on the marketplace's built-in check alone
Read the SKILL.md file and any bundled scripts yourself if the skill touches credentials, files, or network calls
Keep the total number of installed skills small; every skill is additional attack surface
Avoid one-click installs from public marketplaces in any environment connected to sensitive accounts

4. Keep credentials out of the agent's filesystem
Use a secrets manager or vault rather than letting OpenClaw store API keys and tokens in plaintext config files. Rotate tokens regularly, and scope each connected service to the minimum permissions the agent actually needs. If a skill only needs to read a calendar, it should not also hold write access to email.

5. Patch on a schedule, not when you remember
CVE-2026-25253 and similar flaws were fixed quickly once disclosed. The instances that got compromised were, overwhelmingly, ones running outdated versions. Update OpenClaw and its dependencies on a defined cadence, and subscribe to the project's security advisories.

6. Log everything the agent does
If OpenClaw can act autonomously, you need an audit trail of what it acted on: which skills ran, which tool calls fired, which external destinations received data. Runtime monitoring is what turns "we think something went wrong three weeks ago" into "we caught this in under a minute".

7. Separate the agent from production infrastructure
If OpenClaw is managing DevOps tasks, deploying code, or touching infrastructure, give it a scoped service account rather than admin credentials, and route its actions through the same review gates you would require of a junior engineer.

Where to Actually Run It

Once the isolation and monitoring model above is in place, the remaining decision is infrastructure: a self-managed server, a cloud VM you harden by hand, or a preconfigured deployment.

TryDirect's marketplace includes an OpenClaw preconfigured stack, built by the StackDog Team, that deploys to Amazon EC2, DigitalOcean, or Hetzner Cloud with a firewall already configured. It is worth being direct about what that stack currently is and is not: the listing is explicitly labeled an experimental setup, and at the time of writing it has passed 3 of the marketplace's 8 verification checks. That is not unusual for a preconfigured stack built around a tool this new, but it does mean the firewall and isolation it ships with are a starting point, not a substitute for the credential hygiene, skill vetting, and monitoring practices above.

The advantage of deploying through a marketplace stack rather than a manual install is mainly speed and a consistent baseline: a fresh, isolated instance with networking pre-configured, rather than OpenClaw sharing a machine with other workloads by default. Whichever route you choose, self-hosted VM, containerized deployment, or a marketplace image, the checklist does not change. Isolation, a locked-down firewall, vetted skills, and real logging are what determine whether an OpenClaw deployment is a productivity tool or a liability.

FAQ

Is OpenClaw safe to use? OpenClaw is not inherently unsafe, but its permission model, an agent with shell access, file access, and live credentials, means the consequences of a compromise are more severe than with typical software. Safety depends heavily on how it is deployed and which skills are installed, not just which version you run.

What is ClawHub and why does it matter for security? ClawHub is OpenClaw's community marketplace for skills, the packages that extend what the agent can do. Because anyone with a week-old GitHub account can publish and vetting has historically been limited, ClawHub was the primary vector for the ClawHavoc campaign and other malicious-skill incidents documented by Koi Security, Snyk, and Cisco.

Should I run OpenClaw on my personal computer? It is not recommended if that machine also holds sensitive personal accounts, saved passwords, or production credentials. A dedicated, isolated environment, whether a cloud VM, container, or preconfigured stack, limits the blast radius if something goes wrong.

Do skill scanners fully solve the malicious skill problem? No. Trail of Bits demonstrated bypasses against ClawHub's own scanning pipeline and several third-party scanners. Scanning is a useful first filter, not a guarantee, which is why limiting the number of installed skills and reviewing anything with credential or network access still matters.

Deploy OpenClaw on an isolated, firewall-configured instance in minutes with the OpenClaw preconfigured stack on TryDirect.

ClawHavoc, CVE-2026-25253, and 341 malicious skills: what the OpenClaw security research found, and a checklist to deploy it safely in 2026.

OpenClaw Security: Safe Deployment Guide

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

Matomo is an open-source, privacy-first web analytics platform you can self-host. Compared to Google Analytics 4, it gives you 100% data ownership, no data sampling, unlimited retention, and a path to cookieless tracking that the French data protection authority has accepted as consent-exempt. You can deploy a ready-made Matomo stack to your own cloud from try.direct in minutes.

Google Analytics is free, and that is exactly the problem. You are not the customer, your visitors' data is the product. In return for a powerful tool at no cash cost, your numbers get sampled, your data lives on Google's servers, and your visitors get one more cookie banner to dismiss. For a lot of teams in 2026 that trade no longer makes sense.

Matomo is the most established alternative, and the comparison is more even than Google would like. Let us be fair to both, then show you the part most articles skip: how to actually run it.

The first is ownership. GA4 processes and stores your analytics data on Google's infrastructure, largely on US servers. You can read it through dashboards, but ultimate control sits with Google. For EU businesses and regulated industries, that raises real data-residency questions that no setting inside GA4 fully answers.

The second is accuracy. On the free tier, GA4 applies sampling to exploration reports once queries exceed roughly 10 million events. Above that threshold you are looking at estimates, not exact counts. Matomo processes 100% of your data at every traffic level, with no sampling threshold, so the number you see is the number that happened.

The third is retention. GA4 caps event-data retention at 14 months on standard properties. Self-hosted Matomo keeps your data for as long as you want, on your own disk, which matters the moment you need a true year-over-year comparison.

The fourth is consent fatigue. GA4's tracking model generally requires consent in the EU, which means a banner on every visit and lost data every time a visitor clicks reject.

Put plainly, the two tools optimize for different things.

Matomo, self-hosted, gives you complete data ownership on your own server, no sampling at any traffic level, retention for as long as you choose, and a cookieless mode that France's CNIL has accepted as exempt from consent. The software core is free and open source, and it can even import your historical Universal Analytics data so you do not start from zero.

Google Analytics 4 stores your data on Google's servers, samples large exploration reports on the free tier, caps standard retention at 14 months, and generally requires consent in the EU. It does not import Universal Analytics history.

Two things deserve a fair word for Google, though. GA4 is genuinely strong if you live in the Google Ads ecosystem, because it feeds conversion data straight into automated bidding and remarketing, and Matomo does not replicate that natively. Its AI-assisted insights also lower the barrier for teams without an analyst. If paid search is your main channel, that integration alone may keep you on GA4. This is a real tradeoff, not a one-sided pitch.

The data ownership point that actually matters

When your analytics run on someone else's cloud, you have outsourced a piece of your own understanding of your business. Where your traffic comes from, which pages convert, how visitors behave: that is competitive insight, and with GA4 it sits in a third party's system under their terms.

Self-hosted Matomo keeps all of it on infrastructure you control, in the jurisdiction you choose. You decide who can access it, how long to keep it, and when to delete it. That is a posture you can defend to a regulator, a client, or your own security team.

Cookieless tracking and the consent banner

This is the feature that drives most self-hosted adoption. Matomo has a privacy mode that anonymizes IP addresses at ingestion and operates without cookies. EU data protection authorities, including France's CNIL, have explicitly named Matomo's cookieless configuration as one that can run without a consent banner, on the basis that it does not constitute personal data processing.

No banner means no rejected visitors, which means more complete data and a cleaner experience. One honest caveat: the moment you enable behavioral features like session recording, you can re-enter consent territory, because replay can capture personal data on screen. Privacy mode is a deliberate configuration, not an automatic guarantee, so confirm your specific setup against your obligations.

Switching analytics usually means starting from zero. Matomo is an exception, because it can import historical Universal Analytics data, so the years of context you built up do not vanish the way they do when moving cold into GA4. For anyone who still has that old data sitting around, this turns a painful migration into a clean continuation.

Matomo is not magic. The core self-hosted platform is free and complete for standard reporting, but some advanced features such as funnels, certain behavioral tools, and a few premium plugins are paid add-ons. And like any self-hosted app, it needs a server, a database, and basic upkeep. That operational step is the reason many teams stall before they start.

The try.direct Matomo stack ships the platform with everything a real deployment needs, then installs it on your own cloud account. You get Matomo itself, a MySQL database with phpMyAdmin for management, Redis for performance, MyDumper for automated database backups, Fail2ban for protection, and a status panel to keep an eye on the containers. No manual database setup, no PHP tuning, no guesswork.

Run it on Hetzner, DigitalOcean, AWS, Vultr, UpCloud, or any VPS with Docker, and your visitor data never leaves infrastructure you control.

Ready to own your analytics? Deploy the free Matomo stack to your own cloud here: 

Is Matomo a real alternative to Google Analytics 4?

Yes. Matomo has been an established analytics platform for nearly two decades and covers the core analytics needs of most sites: traffic sources, page views, events, goals, and e-commerce, with full data ownership on top.

No. Matomo processes 100% of your data at all traffic levels. GA4 applies sampling to large exploration reports on the free tier.

Can I run Matomo without a cookie consent banner?

In its cookieless privacy mode, yes, in many EU scenarios. France's CNIL has named Matomo's cookieless configuration as exempt from consent. Always confirm your specific configuration against your own legal requirements, especially if you enable behavioral features.

Do I keep my old Universal Analytics data?

Matomo can import historical Universal Analytics data, so you do not have to start from scratch the way you do moving into GA4.

The self-hosted core is free and open source. Some advanced and behavioral features are paid plugins. Your other cost is the server you run it on.

Use the try.direct Matomo stack. It deploys Matomo with its database, caching, and automated backups to your own cloud in minutes, so you skip the manual setup entirely.

Matomo is an open-source, privacy-first web analytics platform you can self-host. Compared to Google Analytics 4, it gives you 100% data ownership, no data sampling, unlimited retention, and a path to cookieless tracking that the French data protection authority has accepted as consent-exempt. You can deploy a ready-made Matomo stack to your own cloud from try.direct in minutes.
Google Analytics is free, and that is exactly the problem. You are not the customer, your visitors' data is the product. In return for a powerful tool at no cash cost, your numbers get sampled, your data lives on Google's servers, and your visitors get one more cookie banner to dismiss. For a lot of teams in 2026 that trade no longer makes sense.
Matomo is the most established alternative, and the comparison is more even than Google would like. Let us be fair to both, then show you the part most articles skip: how to actually run it.

Why teams are leaving GA4
Four reasons come up again and again.
The first is ownership. GA4 processes and stores your analytics data on Google's infrastructure, largely on US servers. You can read it through dashboards, but ultimate control sits with Google. For EU businesses and regulated industries, that raises real data-residency questions that no setting inside GA4 fully answers.
The second is accuracy. On the free tier, GA4 applies sampling to exploration reports once queries exceed roughly 10 million events. Above that threshold you are looking at estimates, not exact counts. Matomo processes 100% of your data at every traffic level, with no sampling threshold, so the number you see is the number that happened.
The third is retention. GA4 caps event-data retention at 14 months on standard properties. Self-hosted Matomo keeps your data for as long as you want, on your own disk, which matters the moment you need a true year-over-year comparison.
The fourth is consent fatigue. GA4's tracking model generally requires consent in the EU, which means a banner on every visit and lost data every time a visitor clicks reject.

The honest comparison
Put plainly, the two tools optimize for different things.
Matomo, self-hosted, gives you complete data ownership on your own server, no sampling at any traffic level, retention for as long as you choose, and a cookieless mode that France's CNIL has accepted as exempt from consent. The software core is free and open source, and it can even import your historical Universal Analytics data so you do not start from zero.
Google Analytics 4 stores your data on Google's servers, samples large exploration reports on the free tier, caps standard retention at 14 months, and generally requires consent in the EU. It does not import Universal Analytics history.
Two things deserve a fair word for Google, though. GA4 is genuinely strong if you live in the Google Ads ecosystem, because it feeds conversion data straight into automated bidding and remarketing, and Matomo does not replicate that natively. Its AI-assisted insights also lower the barrier for teams without an analyst. If paid search is your main channel, that integration alone may keep you on GA4. This is a real tradeoff, not a one-sided pitch.

The data ownership point that actually matters
When your analytics run on someone else's cloud, you have outsourced a piece of your own understanding of your business. Where your traffic comes from, which pages convert, how visitors behave: that is competitive insight, and with GA4 it sits in a third party's system under their terms.
Self-hosted Matomo keeps all of it on infrastructure you control, in the jurisdiction you choose. You decide who can access it, how long to keep it, and when to delete it. That is a posture you can defend to a regulator, a client, or your own security team.

Cookieless tracking and the consent banner
This is the feature that drives most self-hosted adoption. Matomo has a privacy mode that anonymizes IP addresses at ingestion and operates without cookies. EU data protection authorities, including France's CNIL, have explicitly named Matomo's cookieless configuration as one that can run without a consent banner, on the basis that it does not constitute personal data processing.
No banner means no rejected visitors, which means more complete data and a cleaner experience. One honest caveat: the moment you enable behavioral features like session recording, you can re-enter consent territory, because replay can capture personal data on screen. Privacy mode is a deliberate configuration, not an automatic guarantee, so confirm your specific setup against your obligations.

Migrating without losing history
Switching analytics usually means starting from zero. Matomo is an exception, because it can import historical Universal Analytics data, so the years of context you built up do not vanish the way they do when moving cold into GA4. For anyone who still has that old data sitting around, this turns a painful migration into a clean continuation.

The honest cons
Matomo is not magic. The core self-hosted platform is free and complete for standard reporting, but some advanced features such as funnels, certain behavioral tools, and a few premium plugins are paid add-ons. And like any self-hosted app, it needs a server, a database, and basic upkeep. That operational step is the reason many teams stall before they start.
It is also the step try.direct removes.

Deploy Matomo the easy way
The try.direct Matomo stack ships the platform with everything a real deployment needs, then installs it on your own cloud account. You get Matomo itself, a MySQL database with phpMyAdmin for management, Redis for performance, MyDumper for automated database backups, Fail2ban for protection, and a status panel to keep an eye on the containers. No manual database setup, no PHP tuning, no guesswork.
Run it on Hetzner, DigitalOcean, AWS, Vultr, UpCloud, or any VPS with Docker, and your visitor data never leaves infrastructure you control.
Ready to own your analytics? Deploy the free Matomo stack to your own cloud here: 
➞ Matomo

Frequently asked questions
Is Matomo a real alternative to Google Analytics 4?
Yes. Matomo has been an established analytics platform for nearly two decades and covers the core analytics needs of most sites: traffic sources, page views, events, goals, and e-commerce, with full data ownership on top.

Does Matomo sample data like GA4?
No. Matomo processes 100% of your data at all traffic levels. GA4 applies sampling to large exploration reports on the free tier.

Can I run Matomo without a cookie consent banner?
In its cookieless privacy mode, yes, in many EU scenarios. France's CNIL has named Matomo's cookieless configuration as exempt from consent. Always confirm your specific configuration against your own legal requirements, especially if you enable behavioral features.

Do I keep my old Universal Analytics data?
Matomo can import historical Universal Analytics data, so you do not have to start from scratch the way you do moving into GA4.

Is Matomo free?
The self-hosted core is free and open source. Some advanced and behavioral features are paid plugins. Your other cost is the server you run it on.

How do I deploy it quickly?
Use the try.direct Matomo stack. It deploys Matomo with its database, caching, and automated backups to your own cloud in minutes, so you skip the manual setup entirely.

Matomo vs GA4: the open-source, self-hosted analytics with 100% data ownership, zero sampling, and cookieless tracking. See the comparison and deploy it.

Matomo vs GA4: Own Your Analytics Data

Wazuh is a free, open-source platform that unifies SIEM and XDR in one place. It gives you threat detection, file integrity monitoring, vulnerability scanning, and compliance reporting across your servers and cloud workloads, with no license fees and no per-gigabyte pricing. You can deploy a production-ready Wazuh stack to your own cloud from try.direct in minutes.

Here is the uncomfortable truth about most commercial security monitoring: your bill scales with the volume of logs you ingest, not with the number of threats you actually catch. The more visibility you try to buy, the more you pay to store data you may never query. Teams end up filtering out logs to control cost, which quietly shrinks the exact coverage a SIEM is supposed to provide. You are paying more to see less.

Wazuh flips that model. The software is free, the architecture is yours, and the only thing you pay for is the infrastructure you already control.

Wazuh is an open-source security platform that combines two things teams usually buy separately.

The SIEM side collects, normalizes, and analyzes logs from your endpoints, servers, network devices, and cloud workloads. It correlates events in real time and raises alerts when something looks like an attempted or successful intrusion, a misconfiguration, or a policy violation.

The XDR side runs a lightweight agent on each monitored system. Instead of only reading logs after the fact, it watches what is happening on the host itself: file changes, suspicious processes, malware and rootkit indicators, and signs of compromise. When an alert fires, you do not just see a strange login, you see what happened on that machine before and after it.

Putting both in one platform is the point. A log line on its own is noise. A log line plus host context is an investigation you can actually close.

A default Wazuh deployment already covers most of what a small security team needs, and it covers it without a single license key.

On the detection side, Wazuh handles log collection and rule-based correlation across all your systems, flags attempted and successful intrusions, and watches for malware, rootkits, hidden files, and cloaked processes directly on each host. File integrity monitoring tracks changes to the files, permissions, and ownership you care about, and records which user or process made each change, which is exactly the kind of evidence you want during an incident.

On the prevention side, it continuously compares your installed software against updated CVE databases so you find vulnerable packages before an attacker does, and it runs configuration checks against hardening guides to catch risky settings early. When something does go wrong, active response can run automated countermeasures, such as blocking a source address when your criteria are met, and every detected event is mapped to the relevant MITRE ATT&CK tactics so your analysts spend less time guessing and more time responding.

Wazuh reports more than 15 million downloads per year and runs one of the largest open-source security communities in the world. It was also named a 2026 Cybersecurity Stars Awards winner for Best SIEM Platform and Best Cloud Security Platform. This is not a science project, it is a platform large organizations run in production.

If you have ever sat through a PCI DSS or ISO audit, you know that "we have logs somewhere" is not an acceptable answer. Auditors want centralized log collection, file integrity monitoring, and evidence that you review security events.

Wazuh ships with dashboards and reporting aligned to common frameworks including PCI DSS, GDPR, HIPAA, and NIST. File integrity monitoring alone satisfies a specific PCI DSS requirement that many teams scramble to meet at audit time. Because you self-host, the data lives on infrastructure you control, in a jurisdiction you choose, which is exactly the posture regulated buyers increasingly need.

Self-hosted vs managed: the honest tradeoff

Wazuh is free, but it is not effortless. The platform has real depth, and getting the indexer, server, dashboard, and agents wired together correctly takes time and Linux comfort. A managed cloud SIEM hands you a login and a bill. Self-hosted Wazuh hands you full control and a setup task.

That setup task is the friction that stops most teams from switching, even when the cost savings are obvious. It is also exactly the part try.direct removes.

The try.direct Wazuh stack packages the platform with the pieces a real deployment needs, then deploys the whole thing to your own cloud account. You get Wazuh for detection and monitoring, Fail2ban for an extra layer of brute-force protection, Netdata for host-level performance visibility, Portainer for container management, and baseline optimization applied during setup. No manual indexer tuning, no YAML marathon, no weekend lost to install docs.

You run it on Hetzner, DigitalOcean, AWS, Vultr, UpCloud, or any VPS with Docker. The data stays yours.

Ready to start? Deploy the free Wazuh stack to your own cloud here:

Yes. Wazuh is open source and free to download and self-host, even for large organizations. Your costs are the servers you run it on and any optional paid support, not the software itself.

For core SIEM work like log collection, correlation, detection, and dashboards, Wazuh is a credible replacement, and it avoids the per-gigabyte licensing that makes commercial tools expensive at scale. Very large enterprises with heavy advanced-analytics needs should evaluate against their specific requirements.

Endpoints, servers, virtual machines, containers, and cloud workloads. It handles log analysis, intrusion detection, file integrity monitoring, vulnerability detection, configuration assessment, and automated response.

Yes. It includes reporting and controls mapped to standards such as PCI DSS, GDPR, HIPAA, and NIST. Self-hosting also keeps your security data in a jurisdiction you control.

With the try.direct Wazuh stack, a working deployment to your own cloud takes minutes rather than the hours a manual install can require.

A VPS with Docker on a provider like Hetzner, DigitalOcean, AWS, Vultr, or UpCloud. The stack handles the rest.

Wazuh is a free, open-source platform that unifies SIEM and XDR in one place. It gives you threat detection, file integrity monitoring, vulnerability scanning, and compliance reporting across your servers and cloud workloads, with no license fees and no per-gigabyte pricing. You can deploy a production-ready Wazuh stack to your own cloud from try.direct in minutes.
Here is the uncomfortable truth about most commercial security monitoring: your bill scales with the volume of logs you ingest, not with the number of threats you actually catch. The more visibility you try to buy, the more you pay to store data you may never query. Teams end up filtering out logs to control cost, which quietly shrinks the exact coverage a SIEM is supposed to provide. You are paying more to see less.
Wazuh flips that model. The software is free, the architecture is yours, and the only thing you pay for is the infrastructure you already control.

What Wazuh actually is
Wazuh is an open-source security platform that combines two things teams usually buy separately.
The SIEM side collects, normalizes, and analyzes logs from your endpoints, servers, network devices, and cloud workloads. It correlates events in real time and raises alerts when something looks like an attempted or successful intrusion, a misconfiguration, or a policy violation.
The XDR side runs a lightweight agent on each monitored system. Instead of only reading logs after the fact, it watches what is happening on the host itself: file changes, suspicious processes, malware and rootkit indicators, and signs of compromise. When an alert fires, you do not just see a strange login, you see what happened on that machine before and after it.
Putting both in one platform is the point. A log line on its own is noise. A log line plus host context is an investigation you can actually close.

What you get out of the box
A default Wazuh deployment already covers most of what a small security team needs, and it covers it without a single license key.
On the detection side, Wazuh handles log collection and rule-based correlation across all your systems, flags attempted and successful intrusions, and watches for malware, rootkits, hidden files, and cloaked processes directly on each host. File integrity monitoring tracks changes to the files, permissions, and ownership you care about, and records which user or process made each change, which is exactly the kind of evidence you want during an incident.
On the prevention side, it continuously compares your installed software against updated CVE databases so you find vulnerable packages before an attacker does, and it runs configuration checks against hardening guides to catch risky settings early. When something does go wrong, active response can run automated countermeasures, such as blocking a source address when your criteria are met, and every detected event is mapped to the relevant MITRE ATT&CK tactics so your analysts spend less time guessing and more time responding.
Wazuh reports more than 15 million downloads per year and runs one of the largest open-source security communities in the world. It was also named a 2026 Cybersecurity Stars Awards winner for Best SIEM Platform and Best Cloud Security Platform. This is not a science project, it is a platform large organizations run in production.

The compliance angle
If you have ever sat through a PCI DSS or ISO audit, you know that "we have logs somewhere" is not an acceptable answer. Auditors want centralized log collection, file integrity monitoring, and evidence that you review security events.
Wazuh ships with dashboards and reporting aligned to common frameworks including PCI DSS, GDPR, HIPAA, and NIST. File integrity monitoring alone satisfies a specific PCI DSS requirement that many teams scramble to meet at audit time. Because you self-host, the data lives on infrastructure you control, in a jurisdiction you choose, which is exactly the posture regulated buyers increasingly need.

Self-hosted vs managed: the honest tradeoff
Wazuh is free, but it is not effortless. The platform has real depth, and getting the indexer, server, dashboard, and agents wired together correctly takes time and Linux comfort. A managed cloud SIEM hands you a login and a bill. Self-hosted Wazuh hands you full control and a setup task.
That setup task is the friction that stops most teams from switching, even when the cost savings are obvious. It is also exactly the part try.direct removes.

Deploy Wazuh the easy way
The try.direct Wazuh stack packages the platform with the pieces a real deployment needs, then deploys the whole thing to your own cloud account. You get Wazuh for detection and monitoring, Fail2ban for an extra layer of brute-force protection, Netdata for host-level performance visibility, Portainer for container management, and baseline optimization applied during setup. No manual indexer tuning, no YAML marathon, no weekend lost to install docs.
You run it on Hetzner, DigitalOcean, AWS, Vultr, UpCloud, or any VPS with Docker. The data stays yours.
Ready to start? Deploy the free Wazuh stack to your own cloud here:

➞ Wazuh

Frequently asked questions
Is Wazuh really free?
Yes. Wazuh is open source and free to download and self-host, even for large organizations. Your costs are the servers you run it on and any optional paid support, not the software itself.

Can Wazuh replace Splunk or Datadog?
For core SIEM work like log collection, correlation, detection, and dashboards, Wazuh is a credible replacement, and it avoids the per-gigabyte licensing that makes commercial tools expensive at scale. Very large enterprises with heavy advanced-analytics needs should evaluate against their specific requirements.

What does Wazuh monitor?
Endpoints, servers, virtual machines, containers, and cloud workloads. It handles log analysis, intrusion detection, file integrity monitoring, vulnerability detection, configuration assessment, and automated response.

Does Wazuh help with compliance?
Yes. It includes reporting and controls mapped to standards such as PCI DSS, GDPR, HIPAA, and NIST. Self-hosting also keeps your security data in a jurisdiction you control.

How long does it take to deploy?
With the try.direct Wazuh stack, a working deployment to your own cloud takes minutes rather than the hours a manual install can require.

What infrastructure do I need?
A VPS with Docker on a provider like Hetzner, DigitalOcean, AWS, Vultr, or UpCloud. The stack handles the rest.

Wazuh is a free, open-source SIEM and XDR you can self-host. Get threat detection, file integrity monitoring, and compliance, with no per-gigabyte fees.

Self-Host Wazuh: Free Open-Source SIEM/XDR

Effective date: 2026-06-24. Audience: marketplace creators. This policy defines what is allowed and what is not allowed on the TryDirect marketplace. Reviewers reject submissions that violate these rules and cite the specific section in feedback. Creators should review this before submitting. 1. Hard prohibitions - never allowed Templates in the following categories are rejected on sight and cannot be made compliant. Repeated submissions may result in creator account termination. Illegal or harmful software Malware, ransomware, spyware, stalkerware, rootkits, RATs (remote access trojans). Botnets, command-and-control frameworks for unauthorised use, DDoS tools. Credential-stuffing tools, password brute-forcers, account-cracking tools. Phishing kits, fake-login templates, credential-harvesting frontends. Exploit kits and weaponised vulnerability scanners targeting third parties. Cryptojackers - software that mines cryptocurrency without consent. Dual-use security tooling (pentesting frameworks, fuzzing tools, reverse engineering tools) is allowed if the template is clearly labelled for authorised security testing, includes a usage warning, and ships with safe defaults (no auto-exploitation, no scanning of arbitrary targets). Illegal content distribution Child sexual abuse material (CSAM) - zero tolerance, reported to authorities. Content promoting terrorism, mass violence, or genocide. Content inciting violence against a person or group. Stolen credentials, leaked databases, doxing tools. Trademark infringement (e.g. fake brand storefronts). Templates that exist primarily to distribute pirated software, media, or game keys. Fraud and financial crime Unlicensed financial services (lending, payment processing, crypto exchanges in jurisdictions that require licensing). Tools designed for tax evasion, money laundering, or sanctions evasion. Carding tools, fake-ID generators, synthetic identity tools. Multi-level marketing platforms that meet the FTC pyramid-scheme criteria. Templates that misrepresent TryDirect or another brand's identity. Debt-relief, debt-settlement, or debt-negotiation templates. Identity-theft protection or credit-repair service templates. Bail-bond or bankruptcy-lawyer service templates. Loan-repayment-by-credit-card platforms or credit-counselling services. Negative-option marketing, telemarketing, or door-to-door-sales management templates. Government-service templates that impersonate agencies or lack authorisation. Illegal marketplaces and listings Drug marketplaces (controlled substances). Weapons or ammunition sales platforms. Human trafficking, prostitution, escort booking platforms. Wildlife trafficking, endangered-species trade. Stolen-goods marketplaces. 2. Restricted - allowed only under specific conditions The following categories are allowed but require explicit conditions. Reviewers verify each condition before approval. Category Allowed if... Crypto mining software (consensual) Template makes mining the explicit primary purpose, deploys only to the creator's or buyer's own infrastructure, and includes electricity-cost disclosure. Email-sending platforms Designed for transactional email or owned-list newsletters; not optimised for cold outreach or list scraping; complies with CAN-SPAM and GDPR consent requirements. Web scrapers Respects robots.txt by default, includes rate-limiting, prominently documents the legal obligation to honour target-site Terms of Service. Proxy or VPN services Not anonymising for illegal activity; logs disclosure clear; includes abuse-handling contact in template config. Adult content platforms Legal in the deployment jurisdiction; ships with strict age-verification (18+ wall) enabled by default; not targeting jurisdictions where pornography is illegal. Gambling or poker platforms Licensed-operator-only (template enforces licence-key validation); ships with self-exclusion and responsible-gambling tooling enabled. Tobacco, alcohol, cannabis storefronts Legal in the deployment jurisdiction; age-verification on by default; complies with local advertising rules. AI agents with autonomous action capability Documented permission model; ships with sane defaults (no auto-execution of shell commands, no auto-transfer of funds). Forks of existing open-source projects Original licence preserved and visible; creator has the right to redistribute (or the original licence permits it); template attributes the original maintainer in the long description. 3. Security and quality rules Templates that compromise the security of the buyer's infrastructure are rejected. This is the most common rejection category in practice. Embedded credentials No hardcoded passwords, API keys, secrets, tokens, certificates, or SSH keys in any file shipped with the template (compose files, env files, configs, volumes, scripts). Use environment variable interpolation ( ${VAR} ) and document required variables in the template's long description. If a service needs a default password (for example, databases), the template must generate a random one at first boot, not ship with a known default. Insecure defaults No --api.insecure=true or equivalent insecure-mode flags. No services bound to 0.0.0.0 when 127.0.0.1 or a private network is appropriate. No services without authentication when authentication is available. No outdated versions of services with known CVEs at submission time. No docker.sock mounts unless absolutely required, and only with docker-socket-proxy or equivalent least-privilege wrapper. No containers running as root unless the underlying service requires it and the template documents why. Misleading metadata The listed services must match what is actually deployed (no bait-and-switch). The category and tags must reflect the actual purpose. The support URL must resolve to a real support channel. The pricing must match what the buyer is charged. The long description must not promise features the template does not deliver. Outdated and unmaintained software Service versions must be supported upstream at submission time. Templates relying on end-of-life software (for example, Python 2, Node 12, PostgreSQL 11 and earlier, MySQL 5.7 and earlier) are rejected unless the unsupported software is the explicit subject of the template (such as a security training lab) and is clearly labelled as such. Hidden network calls Templates must not phone home to the creator's infrastructure without the buyer's explicit knowledge. Any telemetry, license check, or update check call must be documented in the long description with the exact endpoints and data sent. Call-home patterns that would let the creator track buyer deployments, harvest data, or remotely disable a template are not allowed. 4. Required practices Every published template must: Deploy cleanly to a fresh server on at least one supported cloud provider. Include a clear long description explaining purpose, required environment variables, and customisation points. Include working SSL/TLS configuration when exposing services to the public internet (Let's Encrypt or equivalent, automated). Document any expected ongoing costs (third-party API usage, model hosting, storage growth). Include healthchecks for each long-running service. Document the reset and uninstall procedure. 5. Content moderation and takedown How we hear about violations TryDirect responds to credible reports from: Buyers via the in-app report button or support@try.direct . Rightsholders for IP-infringement claims (see section 6). Law enforcement requests valid under applicable law. Independent security researchers via the responsible-disclosure policy. Takedown process When a violation is confirmed: Template is delisted from /applications immediately. Existing buyers are notified within 7 days. Existing deployments continue to function. TryDirect does not remotely destroy buyer infrastructure. Creator is notified with the specific violation cited. Creator may appeal within 14 days via support@try.direct . Earnings from sales prior to delisting are paid out per the standard schedule. Repeated violations First violation: warning and delisting of the specific template. Second violation: 90-day publishing suspension. Third violation: permanent ban from publishing. Severe violations (CSAM, malware) result in immediate permanent ban without warning. 6. Intellectual property Creator representation By submitting a template, the creator represents that: They own the rights to all content in the template, or have permission to redistribute it. The template's use of open-source software complies with the relevant licences (MIT, Apache 2, GPL, AGPL, etc.) including attribution requirements. The template does not infringe any patent, trademark, or copyright. DMCA / IP takedown TryDirect honours valid DMCA-style takedown notices. Rightsholders may submit takedown requests to dmca@try.direct with: Identification of the copyrighted work claimed to be infringed. Identification of the specific template alleged to infringe. Contact information. Good-faith statement and statement under penalty of perjury. Creators receive counter-notice rights consistent with DMCA Section 512(g). AGPL and copyleft considerations Templates incorporating AGPL software must: Clearly state the AGPL licensing in the long description. Make any modifications to AGPL components publicly available per AGPL Section 13. Not strip AGPL notices from the bundled software. 7. Geographic and legal compliance Creators are responsible for the legality of their template in jurisdictions where they market and sell it. TryDirect may geofence specific templates if required by applicable law (sanctions, export controls, age verification). Templates that violate US, EU, or other major-jurisdiction law are removed regardless of where the creator is based. 8. Changes to this policy TryDirect may update this policy at any time. Material changes affecting already-listed templates are announced via email and in the creator dashboard at least 30 days before they take effect. Templates that become non-compliant due to a policy change are given the same 30-day window to either become compliant or be delisted. Questions Email support@try.direct for general questions, or dmca@try.direct for IP takedown notices. See the Marketplace Payout Terms for revenue share, payout schedule, and tax details.

What is allowed and what is not allowed on the TryDirect marketplace: hard prohibitions, restricted categories, security and quality requirements, and the takedown process.

Marketplace Acceptable Use Policy

Effective date: 2026-06-24. Audience: marketplace creators. This page defines how TryDirect pays marketplace creators. It is the authoritative source for revenue share, payout schedule, supported methods, chargebacks, taxes, and account closure. Anything stated in marketing copy, the creator dashboard, or support communication matches what is here. 1. Revenue share Creators keep 75% of every sale. TryDirect retains a 25% platform fee, which covers payment processing (around 3%), marketplace hosting and promotion, review work, and ongoing platform development. For subscription products, the 75/25 split applies to every renewal cycle , not only the first sale. To avoid rounding errors, the creator share is always calculated as the remainder: creator_payout = gross_sale - platform_fee , where platform_fee = round(gross_sale × 0.25, 2) . 2. Payout schedule Payouts are monthly, Net-30 . Sales that settle in a calendar month are paid out by the 30th of the following month. Sales settled in Paid out by January February 28 February March 30 March April 30 June July 30 December January 30 (next year) "Settled" means the payment has cleared the payment provider and the chargeback window has closed: typically 1-7 days after capture for cards, longer for disputed transactions. 3. Minimum payout threshold The minimum payout is $50 USD . If your available balance at the end of a settlement cycle is below $50, it rolls forward to the next cycle. This avoids transfer fees on tiny amounts and lets creators batch payouts efficiently. Creators with balances under $50 still see full earnings in the dashboard - they are simply not paid until the threshold is crossed. 4. Payout methods Pick one of two methods during onboarding at /dashboard/marketplace/submissions?tab=earnings . You can switch later from the same dashboard. Stripe Connect Express Available in 35+ countries (see Stripe's country list). Direct bank transfer in local currency where supported. Stripe Connect KYC required during onboarding (real name, address, tax ID). PayPal Available worldwide where PayPal operates. Paid to the creator's PayPal email. Recipient is responsible for PayPal's currency conversion fees. 5. Chargebacks, refunds, and disputes Before payout If a sale is refunded or charged back before the monthly payout, the sale is removed from that month's creator balance - no clawback needed. After payout If a buyer disputes a sale after the payout has been sent: The disputed amount is deducted from the creator's next available balance. TryDirect does not issue retroactive clawbacks from already-paid funds. If the next month's balance is insufficient, the negative balance carries forward until enough new sales offset it. Dispute window Card payment disputes can be filed up to 180 days after purchase. PayPal disputes: 180 days. Creators should account for this when reading their pending balance. Refund policy Buyers may request a refund within 14 days of purchase if the template fails to deploy and the creator has not resolved the issue. Refunds reverse the creator's share for that specific sale. 6. Taxes What TryDirect collects US creators: Form W-9 during onboarding. Annual 1099-NEC issued for creators earning $600+ in a calendar year. Non-US creators: Form W-8BEN (individuals) or W-8BEN-E (entities) during onboarding. Annual earnings statement provided on request. EU creators: VAT handling per the marketplace VAT regime; statements provided for VAT return purposes. What creators are responsible for Reporting marketplace income to their local tax authority. VAT registration in their jurisdiction if applicable. Sales tax in jurisdictions that require collection on digital goods (TryDirect handles US sales tax via the marketplace facilitator regime where applicable). TryDirect does not provide tax advice. Consult a local tax professional. 7. Currencies Pricing: USD only at launch. EUR pricing on roadmap. Payouts: in the currency Stripe Connect or PayPal supports for the creator's country. FX conversion is at the payment provider's published rate. Dashboard display: USD, with optional local currency conversion shown at the dashboard's current FX snapshot (informational only). 8. Changes to these terms TryDirect may update payout terms at any time. Changes that affect existing creators are announced via email and in the dashboard at least 30 days before they take effect. Active sales already in the pipeline at the time of a change continue under the previous terms. Future sales follow the new terms. 9. Account closure and final payout If a creator closes their account or TryDirect terminates the account: Voluntary closure: any balance at or above $50 is paid out in the next scheduled cycle. Balances below $50 are paid in a final manual payout within 60 days. Termination for cause (fraud, Terms of Service violation, illegal content): balances may be withheld up to the dispute window (180 days) and used to offset chargebacks, refunds, or restitution. Questions Email support@try.direct for help with onboarding, payouts, tax forms, or any clarifications. The Marketplace Acceptable Use Policy is the companion document defining what may and may not be sold.

How TryDirect pays marketplace creators: 75% revenue share, monthly Net-30 payouts via Stripe Connect or PayPal, $50 minimum threshold, and clear chargeback policy.

Marketplace Payout Terms

OpenClaw exploded to hundreds of thousands of GitHub stars, and its skill marketplace was hit by hundreds of malicious packages just as fast. Here is what the research found, and how to deploy it safely.

Google Analytics is free because your visitors' data is the product. Matomo is the open-source alternative you self-host: 100% data ownership, no sampling, unlimited retention, and cookieless tracking the CNIL accepts without a consent banner. Here is the honest GA4 comparison, and how to deploy it in minutes.

Most SIEMs bill you for the logs you store, not the threats you catch. Wazuh breaks that trade: a free, open-source SIEM and XDR you self-host, with threat detection, file integrity monitoring, vulnerability scanning, and compliance dashboards built in. Here is how to deploy it in minutes.

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

TryDirect blog