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

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

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

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

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

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

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

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

Connect Supabase to PostHog with Stacker PIPEs - Complete Setup Guide

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

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

Deploy Ghost CMS to Hetzner Cloud with One Stacker Command

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

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

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

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

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

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

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

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

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

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

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

Short answer. Open source license risk is the chance that software you already run changes its terms in a way that restricts how you deploy it. Between 2021 and 2026, Elastic, HashiCorp, Redis, Open WebUI and NocoDB all moved to licenses the Open Source Initiative does not recognize. Three of those changes produced forks that survived (OpenSearch, OpenTofu, Valkey), and two produced reversals with no visible reverse migration. You can evaluate the risk before you deploy by checking who holds the copyright, what the license text actually says, where the project's revenue comes from, whether a credible fork exists, and how long a migration would really take.

Who this is for. Teams and individuals who self host production services and pick their own components, rather than inheriting them from a procurement process.

In January 2026, someone opened a discussion on the NocoDB repository with a plain question: since version 0.301.0 is no longer published under an OSI approved license, should the project still be described as open source, or would "source available" be the more honest label?

The maintainers answered candidly, and the release notes say the same thing plainly: NocoDB transitioned from AGPL 3.0 to a fair code Sustainable Use License, following the path n8n took before it, framed as a way to keep giving more to the community edition while refusing to subsidize companies that take without contributing. The license text limits use to your own internal business purposes, or to non-commercial and personal use. The project also uses a contributor license agreement, which is why relicensing external contributions raised no legal obstacle. By the July 2026 release, self hosted deployments resolve their feature tier from the signed license key itself, so installs that had quietly been running Enterprise features they were not licensed for now fall back to the plan they actually hold.

Nothing about that is unusual any more. That is the point.

If you self host, the license file in a repository has become an operational input, not a legal footnote. It determines whether you can still pull the image you built your workflow around, whether the feature you demoed to your team is still in the free tier next quarter, and whether the project you standardized on will be maintained by the same people in two years. Choosing infrastructure in 2026 is a governance decision that happens to have a technical component, and most teams are still making it the other way round.

Open source vs source available: what the license labels actually mean

Open source is a defined term. The Open Source Initiative maintains the definition and the list of approved licenses, and a license that is not on that list is not open source no matter how the project markets itself. Source available means the code is published and usually modifiable, but with restrictions on deployment or commercial use that would disqualify it from the OSI definition.

Here is what you are likely to encounter in a self hosted stack, and what each one restricts.

BSD 3-Clause, MIT and Apache 2.0. Permissive. They restrict almost nothing beyond attribution. Valkey ships under BSD 3-Clause, OpenSearch under Apache 2.0.

MPL 2.0. Weak copyleft, applied file by file. Files you modify stay under MPL, the rest of your codebase does not. Used by OpenTofu.

AGPLv3. Strong copyleft. Network use triggers the obligation to publish modified source, which matters the moment you run a modified build as a service. Offered by Redis 8 and by Elasticsearch and Kibana, in each case as one option of three.

BSL 1.1. Source available. Blocks commercial use that competes with the licensor, until each release converts to a designated open license after a set period. HashiCorp set four years per release, converting to MPL 2.0. Used by Terraform, Vault, Consul and Nomad.

SSPL v1. Source available. You may offer the software as a service only if you publish the entire service management stack around it, which in practice nobody does. Used by MongoDB, and still offered alongside AGPLv3 by both Redis and Elastic.

Elastic License 2.0. Source available. Blocks offering the product as a managed service, and blocks circumventing license key functionality. Used in Elastic's default distributions.

Sustainable Use License and fair code variants. Source available. Limit you to your own internal business purposes and to non-commercial or personal use, which rules out offering the software as a service. Used by n8n, and by NocoDB from 0.301.0, previously AGPLv3.

BSD 3-Clause plus a branding clause. The base is permissive, but the added clause restricts removing or altering project branding above a usage threshold, which is enough to keep it off the approved list. Used by Open WebUI from v0.6.6.

The practical consequence: anything in the first group means you deploy and stop thinking about it. Anything in the second means somebody on your side needs to have read the specific clauses before the service goes into production.

What changed: a timeline of open source relicensing, 2021 to 2026

The relicensing wave is old enough now that we can stop arguing about motives and just look at outcomes.

2021. Elastic moved the Apache 2.0 source of Elasticsearch and Kibana to a dual SSPL and Elastic License 2.0 arrangement at the 7.11 release. AWS forked 7.10.2 in April 2021 and shipped it as OpenSearch under Apache 2.0.

August 2023. HashiCorp relicensed Terraform, Vault, Consul and Nomad from MPL 2.0 to the Business Source License 1.1. Within days a manifesto appeared on GitHub signed by a long list of companies. The Linux Foundation adopted the fork as OpenTofu in September 2023, the first stable release shipped on 10 January 2024, and the CNCF accepted the project in April 2025.

March 2024. Redis Ltd moved Redis from BSD 3-Clause to a dual SSPLv1 and RSALv2 license, which meant any cloud provider offering a managed Redis compatible service now needed a commercial agreement. Within weeks AWS, Google Cloud, Oracle, Ericsson and Snap backed a fork of Redis 7.2.4, the last BSD release, and the Linux Foundation accepted it as Valkey in late March 2024.

August 2024. Elastic added AGPLv3 alongside SSPL and ELv2, with the change targeted at the 8.16 release. Founder Shay Banon published a post titled "Elasticsearch Is Open Source. Again!"

April 2025. The wave reached the self hosted application layer rather than the infrastructure layer, and it arrived in a softer form. Open WebUI kept a BSD 3-Clause base at v0.6.6 but added a branding protection clause, plus a contributor license agreement for anything submitted after v0.6.5. Deployments of fifty users or fewer in a rolling thirty day window are exempt, as are substantive contributors with written permission and holders of an enterprise license. Everything up to v0.6.5 stays BSD 3-Clause and can still be forked freely.

May 2025. Redis added AGPLv3 as a third option from Redis 8, making the project OSI compliant again.

January 2026. NocoDB moved from AGPLv3 to a fair code Sustainable Use License at version 0.301.0.

Five departures and two returns in five years, and the most recent departure arrived after both returns. This is not a trend with a direction. It is a permanent condition of the ecosystem.

Do open source forks actually survive? What Valkey, OpenTofu and OpenSearch prove

Yes, but only under specific conditions, and by 2026 there is enough evidence to name them precisely.

AWS reported in May 2026 that Valkey had marked its second anniversary with more than 100 million Docker pulls and adoption across nearly every major cloud provider. AWS launched ElastiCache for Valkey in October 2024 with serverless priced 33 percent lower and node-based clusters 20 percent lower than the other supported engines, and it now recommends Valkey for new deployments. Google offers Memorystore for Valkey and Oracle supports it on OCI Cache. The release cadence is steady: ElastiCache picked up Valkey 9.0 in May 2026 and 9.1 in July 2026. When the largest clouds recommend a fork over the original and price it lower, the question of whether the fork survives is settled.

OpenTofu followed the same arc, and it has stopped being a renamed Terraform. Native state encryption and early variable evaluation shipped in OpenTofu with no equivalent in Terraform's open source CLI. The divergence runs both ways, which is worth stating plainly: Terraform introduced ephemeral values and ephemeral resources in version 1.10 in late 2024 and write-only arguments in 1.11, and OpenTofu added its own ephemerality support a year later in 1.11. Neither project is simply trailing the other. Meanwhile IBM completed its 6.4 billion dollar acquisition of HashiCorp on 27 February 2025, and Terraform's roadmap now runs through IBM's commercial priorities, including integration with watsonx, Ansible and OpenShift.

OpenSearch is the oldest of the three and the quietest, which is its own kind of evidence. AWS forked Elasticsearch 7.10.2 in 2021, kept it on Apache 2.0, and later moved it to the Linux Foundation under its own foundation structure, which retired the obvious objection that the project was one vendor's answer to another vendor.

Three forks, one pattern, and it is worth stating explicitly because it is the closest thing to a rule this whole story produced.

Funded backing at launch. A major cloud provider or a coalition of vendors put paid engineers on it from day one.

Neutral governance. The project sits with a foundation, so no single company can relicense it again.

An open license. Permissive or OSI approved, so downstream adoption carries no new legal analysis.

Forks that lack all three do not tend to survive contact with the second year. That is the test to apply when someone on your team says "there is already a fork" as if that settles the matter.

Redis is open source again. Elasticsearch is open source again. Neither reversal appears to have brought the migrated users back, and nobody publishes a number for reverse migration, so treat what follows as an argument from switching costs rather than as a measurement.

Once a team has swapped a binary, updated its runbooks, retrained its on call engineers and passed a procurement review on the new component, the cost of moving back is the same as the cost of moving out, and the motivation is far weaker. Migration is sticky in the direction it last moved. A vendor that relicenses is not making a reversible decision about its license. It is making an irreversible decision about its user base, and it usually finds this out about eighteen months later.

For you, the practical consequence is smaller and more useful: the moment to evaluate license risk is before deployment, not during the incident. Once a project is load bearing in your stack, you have already lost most of your options.

Why license risk hits self hosters harder than enterprises

Enterprise teams have a procurement function that reads license files, plus legal review, vendor risk registers and a person whose job is to notice that a component changed terms. It is slow and annoying and it mostly works. If you run your own infrastructure with a small team, none of that exists, and three things make your exposure worse.

You may be the distributor. The moment you host a service for anyone outside your organization, including clients, users of a product you sell, or a community instance, several source available licenses start to apply to you in ways they do not apply to a company running the same software internally. The trigger in most of these licenses is commercial activity and offering the software as a service, not company size.

Your upgrade path is a single command. Nobody reviews the license diff between two container tags. If a project gates a feature behind a paid tier in a minor release, you find out when something stops working, in production, usually on the day you least wanted to find out. The NocoDB July 2026 release is a clean example of the mechanism: same image, feature set resolved at runtime from a license key rather than from what the binary contains.

Open core creep is invisible until it isn't. Very few projects announce that they are becoming less open. They ship a release where SSO moved to the paid tier, then one where audit logs did, then one where the feature you actually needed did. Each individual step is defensible. The cumulative direction is a product decision that was never announced as one, and it is far more common than an outright license change.

A legal dimension is arriving from the other side too. The EU Cyber Resilience Act starts its vulnerability and incident reporting obligations on 11 September 2026, with full application in December 2027, and it introduces a defined role for open source stewards. Governance is becoming something regulators care about, which is a separate article, but it belongs in the same mental bucket.

How to evaluate license risk before you deploy: five questions

Short answer. Open source license risk is the chance that software you already run changes its terms in a way that restricts how you deploy it. Between 2021 and 2026, Elastic, HashiCorp, Redis, Open WebUI and NocoDB all moved to licenses the Open Source Initiative does not recognize. Three of those changes produced forks that survived (OpenSearch, OpenTofu, Valkey), and two produced reversals with no visible reverse migration. You can evaluate the risk before you deploy by checking who holds the copyright, what the license text actually says, where the project's revenue comes from, whether a credible fork exists, and how long a migration would really take.

Who this is for. Teams and individuals who self host production services and pick their own components, rather than inheriting them from a procurement process.

In January 2026, someone opened a discussion on the NocoDB repository with a plain question: since version 0.301.0 is no longer published under an OSI approved license, should the project still be described as open source, or would "source available" be the more honest label?

The maintainers answered candidly, and the release notes say the same thing plainly: NocoDB transitioned from AGPL 3.0 to a fair code Sustainable Use License, following the path n8n took before it, framed as a way to keep giving more to the community edition while refusing to subsidize companies that take without contributing. The license text limits use to your own internal business purposes, or to non-commercial and personal use. The project also uses a contributor license agreement, which is why relicensing external contributions raised no legal obstacle. By the July 2026 release, self hosted deployments resolve their feature tier from the signed license key itself, so installs that had quietly been running Enterprise features they were not licensed for now fall back to the plan they actually hold.

Nothing about that is unusual any more. That is the point.

If you self host, the license file in a repository has become an operational input, not a legal footnote. It determines whether you can still pull the image you built your workflow around, whether the feature you demoed to your team is still in the free tier next quarter, and whether the project you standardized on will be maintained by the same people in two years. Choosing infrastructure in 2026 is a governance decision that happens to have a technical component, and most teams are still making it the other way round.

Open source vs source available: what the license labels actually mean

Open source is a defined term. The Open Source Initiative maintains the definition and the list of approved licenses, and a license that is not on that list is not open source no matter how the project markets itself. Source available means the code is published and usually modifiable, but with restrictions on deployment or commercial use that would disqualify it from the OSI definition.

Here is what you are likely to encounter in a self hosted stack, and what each one restricts.

OSI approved

BSD 3-Clause, MIT and Apache 2.0. Permissive. They restrict almost nothing beyond attribution. Valkey ships under BSD 3-Clause, OpenSearch under Apache 2.0.

MPL 2.0. Weak copyleft, applied file by file. Files you modify stay under MPL, the rest of your codebase does not. Used by OpenTofu.

AGPLv3. Strong copyleft. Network use triggers the obligation to publish modified source, which matters the moment you run a modified build as a service. Offered by Redis 8 and by Elasticsearch and Kibana, in each case as one option of three.

Not OSI approved

BSL 1.1. Source available. Blocks commercial use that competes with the licensor, until each release converts to a designated open license after a set period. HashiCorp set four years per release, converting to MPL 2.0. Used by Terraform, Vault, Consul and Nomad.

SSPL v1. Source available. You may offer the software as a service only if you publish the entire service management stack around it, which in practice nobody does. Used by MongoDB, and still offered alongside AGPLv3 by both Redis and Elastic.

Elastic License 2.0. Source available. Blocks offering the product as a managed service, and blocks circumventing license key functionality. Used in Elastic's default distributions.

Sustainable Use License and fair code variants. Source available. Limit you to your own internal business purposes and to non-commercial or personal use, which rules out offering the software as a service. Used by n8n, and by NocoDB from 0.301.0, previously AGPLv3.

BSD 3-Clause plus a branding clause. The base is permissive, but the added clause restricts removing or altering project branding above a usage threshold, which is enough to keep it off the approved list. Used by Open WebUI from v0.6.6.

The practical consequence: anything in the first group means you deploy and stop thinking about it. Anything in the second means somebody on your side needs to have read the specific clauses before the service goes into production.

What changed: a timeline of open source relicensing, 2021 to 2026

The relicensing wave is old enough now that we can stop arguing about motives and just look at outcomes.

2021. Elastic moved the Apache 2.0 source of Elasticsearch and Kibana to a dual SSPL and Elastic License 2.0 arrangement at the 7.11 release. AWS forked 7.10.2 in April 2021 and shipped it as OpenSearch under Apache 2.0.

August 2023. HashiCorp relicensed Terraform, Vault, Consul and Nomad from MPL 2.0 to the Business Source License 1.1. Within days a manifesto appeared on GitHub signed by a long list of companies. The Linux Foundation adopted the fork as OpenTofu in September 2023, the first stable release shipped on 10 January 2024, and the CNCF accepted the project in April 2025.

March 2024. Redis Ltd moved Redis from BSD 3-Clause to a dual SSPLv1 and RSALv2 license, which meant any cloud provider offering a managed Redis compatible service now needed a commercial agreement. Within weeks AWS, Google Cloud, Oracle, Ericsson and Snap backed a fork of Redis 7.2.4, the last BSD release, and the Linux Foundation accepted it as Valkey in late March 2024.

August 2024. Elastic added AGPLv3 alongside SSPL and ELv2, with the change targeted at the 8.16 release. Founder Shay Banon published a post titled "Elasticsearch Is Open Source. Again!"

April 2025. The wave reached the self hosted application layer rather than the infrastructure layer, and it arrived in a softer form. Open WebUI kept a BSD 3-Clause base at v0.6.6 but added a branding protection clause, plus a contributor license agreement for anything submitted after v0.6.5. Deployments of fifty users or fewer in a rolling thirty day window are exempt, as are substantive contributors with written permission and holders of an enterprise license. Everything up to v0.6.5 stays BSD 3-Clause and can still be forked freely.

May 2025. Redis added AGPLv3 as a third option from Redis 8, making the project OSI compliant again.

January 2026. NocoDB moved from AGPLv3 to a fair code Sustainable Use License at version 0.301.0.

Five departures and two returns in five years, and the most recent departure arrived after both returns. This is not a trend with a direction. It is a permanent condition of the ecosystem.

Do open source forks actually survive? What Valkey, OpenTofu and OpenSearch prove

Yes, but only under specific conditions, and by 2026 there is enough evidence to name them precisely.

AWS reported in May 2026 that Valkey had marked its second anniversary with more than 100 million Docker pulls and adoption across nearly every major cloud provider. AWS launched ElastiCache for Valkey in October 2024 with serverless priced 33 percent lower and node-based clusters 20 percent lower than the other supported engines, and it now recommends Valkey for new deployments. Google offers Memorystore for Valkey and Oracle supports it on OCI Cache. The release cadence is steady: ElastiCache picked up Valkey 9.0 in May 2026 and 9.1 in July 2026. When the largest clouds recommend a fork over the original and price it lower, the question of whether the fork survives is settled.

OpenTofu followed the same arc, and it has stopped being a renamed Terraform. Native state encryption and early variable evaluation shipped in OpenTofu with no equivalent in Terraform's open source CLI. The divergence runs both ways, which is worth stating plainly: Terraform introduced ephemeral values and ephemeral resources in version 1.10 in late 2024 and write-only arguments in 1.11, and OpenTofu added its own ephemerality support a year later in 1.11. Neither project is simply trailing the other. Meanwhile IBM completed its 6.4 billion dollar acquisition of HashiCorp on 27 February 2025, and Terraform's roadmap now runs through IBM's commercial priorities, including integration with watsonx, Ansible and OpenShift.

OpenSearch is the oldest of the three and the quietest, which is its own kind of evidence. AWS forked Elasticsearch 7.10.2 in 2021, kept it on Apache 2.0, and later moved it to the Linux Foundation under its own foundation structure, which retired the obvious objection that the project was one vendor's answer to another vendor.

Three forks, one pattern, and it is worth stating explicitly because it is the closest thing to a rule this whole story produced.

Funded backing at launch. A major cloud provider or a coalition of vendors put paid engineers on it from day one.
Neutral governance. The project sits with a foundation, so no single company can relicense it again.
An open license. Permissive or OSI approved, so downstream adoption carries no new legal analysis.

Forks that lack all three do not tend to survive contact with the second year. That is the test to apply when someone on your team says "there is already a fork" as if that settles the matter.

Do license reversals bring users back?

Redis is open source again. Elasticsearch is open source again. Neither reversal appears to have brought the migrated users back, and nobody publishes a number for reverse migration, so treat what follows as an argument from switching costs rather than as a measurement.

Once a team has swapped a binary, updated its runbooks, retrained its on call engineers and passed a procurement review on the new component, the cost of moving back is the same as the cost of moving out, and the motivation is far weaker. Migration is sticky in the direction it last moved. A vendor that relicenses is not making a reversible decision about its license. It is making an irreversible decision about its user base, and it usually finds this out about eighteen months later.

For you, the practical consequence is smaller and more useful: the moment to evaluate license risk is before deployment, not during the incident. Once a project is load bearing in your stack, you have already lost most of your options.

Why license risk hits self hosters harder than enterprises

Enterprise teams have a procurement function that reads license files, plus legal review, vendor risk registers and a person whose job is to notice that a component changed terms. It is slow and annoying and it mostly works. If you run your own infrastructure with a small team, none of that exists, and three things make your exposure worse.

You may be the distributor. The moment you host a service for anyone outside your organization, including clients, users of a product you sell, or a community instance, several source available licenses start to apply to you in ways they do not apply to a company running the same software internally. The trigger in most of these licenses is commercial activity and offering the software as a service, not company size.

Your upgrade path is a single command. Nobody reviews the license diff between two container tags. If a project gates a feature behind a paid tier in a minor release, you find out when something stops working, in production, usually on the day you least wanted to find out. The NocoDB July 2026 release is a clean example of the mechanism: same image, feature set resolved at runtime from a license key rather than from what the binary contains.

Open core creep is invisible until it isn't. Very few projects announce that they are becoming less open. They ship a release where SSO moved to the paid tier, then one where audit logs did, then one where the feature you actually needed did. Each individual step is defensible. The cumulative direction is a product decision that was never announced as one, and it is far more common than an outright license change.

A legal dimension is arriving from the other side too. The EU Cyber Resilience Act starts its vulnerability and incident reporting obligations on 11 September 2026, with full application in December 2027, and it introduces a defined role for open source stewards. Governance is becoming something regulators care about, which is a separate article, but it belongs in the same mental bucket.

How to evaluate license risk before you deploy: five questions

Avoiding single vendor projects is not the answer. Plenty of excellent software is built by companies that need revenue, and refusing to run any of it would leave you with a very short list. The answer is pricing the risk instead of ignoring it. Ask these five questions before a service becomes load bearing.

1. Who can relicense this tomorrow?
Look for a copyright assignment or a contributor license agreement that transfers rights to one company. If a single legal entity holds the rights, a relicense is a board decision rather than a community negotiation. Projects governed by the Linux Foundation, the CNCF or the Apache Software Foundation cannot do this unilaterally, and that is the entire value of the arrangement. NocoDB is the clean illustration: when the license changed, the discussion thread noted that the project uses a CLA, so relicensing contributed code raised no legal obstacle at all.

2. What is the actual license, not the label on the README?
"Open source" is now used to describe BSL, SSPL, the Elastic License, Sustainable Use licenses, fair code and a range of bespoke variants, none of which the OSI recognizes. Read the file. Look specifically for a competition clause, a service provider clause, and any time delay before the code converts to an open license.

3. Where is the revenue coming from?
A project funded by managed hosting has a structural reason to restrict competitors and very little reason to gate features you use on your own server. A project funded by an enterprise tier has a structural reason to move features out of the free tier over time. Neither is wrong. They fail differently, and knowing which one you are dealing with tells you what to watch for.

4. If it forks, does the fork clear all three bars?
Funded backing, neutral governance, open license. Two out of three describes a project that will be alive next year and quiet the year after.

5. How long would migration actually take?
Not the binary swap. The runbooks, the monitoring, the backup and restore procedure you have never tested, the integration that nobody documented, the client who has to be told. Write the number down. That number is the real cost of the license risk you are accepting, and it is the only one that will matter when you need it.

If you are already thinking in these terms about the tooling layer, our comparison of Stacker, Coolify, CapRover, Vercel and Railway applies the same lens to deployment platforms, and the real cost of self hosting in 2026 covers the economic half of the same decision.

How to spot a relicense before it happens: six early warning signals

Relicensing is almost never a surprise to people who were paying attention. The signals are consistent across almost every case in the timeline above.

A contributor license agreement or copyright assignment requirement appears, or is tightened, for new contributors.
Funding news lands, particularly a growth round or an acquisition. Investors ask about monetization, and the license is the easiest lever.
The word "sustainability" starts appearing in release notes and maintainer posts.
Features move from the community edition to a paid tier in consecutive releases.
The commercial hosted offering starts shipping features that never reach the self hosted build.
Trademark policy is published or tightened. This is often the first move, because it is the least controversial one, and it frequently precedes a license change by several months.

Tooling helps. Pin your images by digest rather than by tag so an upgrade is a decision rather than an accident. Keep an SBOM so you can answer "where does this component appear" in minutes instead of days. GitHub moved open source license compliance into public preview on 30 June 2026. It lets an enterprise define a central license policy and block noncompliant dependencies at the pull request, with an Evaluate mode that annotates without blocking. Read the eligibility line before you get excited: it is limited to GitHub Enterprise Cloud customers holding GitHub Advanced Security Code Security licenses, so most small self hosting teams cannot use it, and it covers dependencies rather than the services you deploy. For everyone else the equivalent is a license field in your own SBOM and the discipline to look at it.

What to do when a project you run changes its license

It will happen eventually to something in your stack. The response that works is boring, and it has four steps.

Do not migrate on the day of the announcement. The first forty eight hours produce the loudest takes and the worst decisions, and a fork announced in that window has not yet demonstrated any of the three qualities that predict survival.

Establish whether the change affects you at all. A large share of relicensing changes are aimed squarely at cloud providers and managed service vendors. If you run a service internally, or for a fixed set of clients under contract, many source available licenses leave you exactly where you were. Read the text before you act on the headline.

Pin your current version. You are entitled to keep using the release you already have under the license it shipped with. Prior releases do not retroactively change terms. That buys you months, and months is all you need.

Then evaluate, budget and decide. Score the fork against the three criteria, cost the migration honestly, and choose. Sometimes the answer is to stay and pay, and that is a legitimate outcome rather than a defeat.

The mechanics are the same ones that apply to any component reaching end of life, which is why the Gateway API migration playbook we published for ingress-nginx reads like a template for this situation as well.

Why infrastructure choice is now a governance decision

For a long time, choosing infrastructure was a technical exercise with a compliance checkbox attached. Benchmarks, feature matrices, operational complexity, and then somebody confirmed the license was permissive and everyone moved on.

The five years since Elastic's first relicense have inverted that. The technical comparison between Redis and Valkey, or between Terraform and OpenTofu, is genuinely close. The governance comparison is not close at all, and it is the one that predicts where you will be in three years. Engineers who learned this the hard way in 2024 now check the governance model before they check the benchmarks, and they are right to.

Own the infrastructure, and you own the decision about what runs on it. That is worth something on the day someone else's board meeting changes the terms.

Redis, Terraform and NocoDB all changed license terms. How to judge license risk before you deploy, and what the forks proved by 2026.

Open Source or Source Available in 2026

Five license changes in five years, two of them later reversed. If you self host, the license file is an operational input now, not a legal footnote. Here is how to judge a project before it becomes load bearing in your stack.

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

Dashboard

TryDirect blog