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

Marketing pages show base prices. Invoices tell a different story, especially on managed platforms where the bill grows through usage-based add-ons rather than the sticker price.

Self-hosting has its own cost story, and it's usually told as "you save money but pay in time." That framing deserves a closer look with actual, published numbers rather than rough estimates.

For a single web app with a database and light traffic, a 2 vCPU / 4 GB RAM instance is the standard starting point. Published pricing from the two most commonly compared VPS providers looks like this as of mid-2026:

Hetzner CX22 (2 vCPU, 4 GB RAM, 40 GB NVMe SSD, 20 TB of included traffic): €7.99 a month, roughly $9.49, following Hetzner's April 2026 price adjustment. The 20 TB traffic allowance is bundled in at no extra charge.

DigitalOcean Basic Droplet (2 vCPU, 4 GB RAM): $24 a month, with a smaller included transfer allowance and overage billed per gigabyte beyond that.

Both figures come from the providers' own published pricing, cross-checked against independent benchmarking comparisons. The gap between them isn't a rounding error. It reflects a genuine difference in positioning: Hetzner competes almost entirely on raw compute-per-dollar, while DigitalOcean's higher price includes a broader ecosystem (managed databases from $15/month, App Platform, integrated CDN, and more extensive documentation for teams that want to self-manage less).

What a dedicated, production-grade instance costs

Once traffic grows enough that shared-CPU noisy-neighbor effects start to matter, teams typically move to dedicated-core instances. DigitalOcean's own pricing page lists CPU-Optimized Droplets starting at $42/month for 4 GB of memory, scaling up to $168/month for an 8 vCPU / 16 GB configuration. These are dedicated-core instances built for sustained CPU workloads rather than the shared-core Basic tier.

Hetzner's dedicated-vCPU line (CCX) targets the same use case at meaningfully lower list prices, though the two providers structure their tiers differently enough that a precise like-for-like comparison at this spec level needs to be checked against current pricing pages rather than quoted as a fixed figure here.

Where managed PaaS costs actually come from

Modern PaaS platforms rarely charge a flat fee for real workloads. The base subscription (commonly around $20/month per seat on platforms like Vercel's Pro tier) covers a baseline allowance. Beyond that, cost accumulates through several separate meters:

Function execution time, billed once you exceed the included compute-hours

Bandwidth, billed per gigabyte beyond an included allowance

Build minutes, billed once CI/CD usage exceeds the free tier

Because each of these is metered independently, and because platforms with multiple services (an API, a background worker, an admin panel) often meter each service separately, the total can grow substantially beyond the advertised base price. The exact dollar impact depends heavily on actual traffic and usage patterns, which is why platform pricing pages show ranges and calculators rather than single numbers, and why it's worth running your own workload through a provider's current calculator before comparing costs.

The usual counterargument is that self-hosting costs engineering hours that managed platforms save. That's true, but it isn't the full comparison. The realistic tradeoff isn't "self-hosting time versus zero time." It's "self-hosting time versus PaaS-debugging time": working around usage-based billing surprises, tuning cold-start latency, hitting platform-specific limitations, or migrating everything when a vendor changes its pricing tiers, as Hetzner itself did in April 2026 with advance notice, and as most providers do periodically without much notice at all.

Setting up a bare VPS still requires configuring a reverse proxy, provisioning SSL, and wiring up container networking by hand, work that a deployment platform like try.direct automates. That's the layer where self-hosting's time cost concentrates, and it's largely a one-time setup cost rather than an ongoing one.

Neither model is free of costs that don't show up on the pricing page:

Per-service metering that doesn't consolidate, so several small services can cost more together than one larger one on the same infrastructure

Vendor-specific limitations (cold start behavior, execution time caps) that still require engineering workarounds despite the platform being "managed"

Migration risk when a vendor changes pricing tiers; moving a production workload afterward takes real effort

Initial setup time for reverse proxy, SSL, and container networking, mostly a one-time cost rather than a recurring one

Backup and monitoring discipline: a self-hosted stack is only as reliable as the backup schedule someone actually maintains

No default uptime SLA on budget VPS providers (Hetzner, for instance, does not publish a formal SLA or credit-backed compensation for cloud downtime), which matters more for workloads where uptime carries real business or compliance weight

Not every workload belongs on infrastructure you manage. A good self-hosting candidate has predictable usage, a clear owner, and a straightforward backup and recovery plan the team actually understands. Compliance-heavy systems, or anything where the operational risk of a mistake is high and the team lacks the experience to catch it early, are usually better left on a managed platform, at least until that experience exists in-house.

The right question isn't "can we self-host this." It's "should we own the operation of this".

Is self-hosting actually cheaper than managed cloud hosting? For a comparable spec, published VPS pricing (Hetzner, DigitalOcean) is consistently lower than managed PaaS once usage-based overages are factored in. The gap narrows for highly variable or spiky traffic, where managed autoscaling and included support can offset some of the difference.

Why is Hetzner so much cheaper than DigitalOcean for the same specs? The two providers are positioned differently. Hetzner competes primarily on raw compute price and bundles a large traffic allowance; DigitalOcean's higher price includes a broader managed-service ecosystem (managed databases, App Platform, CDN) and more extensive support documentation.

What's the biggest hidden cost of managed PaaS platforms? Usage-based billing across separate meters, execution time, bandwidth, build minutes, and per-service charges that aren't obvious from the base subscription price.

What's the biggest hidden cost of self-hosting? Operational setup time for tasks that deployment tooling can automate: reverse proxy configuration, SSL certificate renewal, container networking, and ongoing backup scheduling.

Manage your self-hosted Docker Compose stacks the easy way ➞ deploy Dockge on try.direct

Marketing pages show base prices. Invoices tell a different story, especially on managed platforms where the bill grows through usage-based add-ons rather than the sticker price.

Self-hosting has its own cost story, and it's usually told as "you save money but pay in time." That framing deserves a closer look with actual, published numbers rather than rough estimates.

What a small VPS actually costs today

For a single web app with a database and light traffic, a 2 vCPU / 4 GB RAM instance is the standard starting point. Published pricing from the two most commonly compared VPS providers looks like this as of mid-2026:
Hetzner CX22 (2 vCPU, 4 GB RAM, 40 GB NVMe SSD, 20 TB of included traffic): €7.99 a month, roughly $9.49, following Hetzner's April 2026 price adjustment. The 20 TB traffic allowance is bundled in at no extra charge.
DigitalOcean Basic Droplet (2 vCPU, 4 GB RAM): $24 a month, with a smaller included transfer allowance and overage billed per gigabyte beyond that.

Both figures come from the providers' own published pricing, cross-checked against independent benchmarking comparisons. The gap between them isn't a rounding error. It reflects a genuine difference in positioning: Hetzner competes almost entirely on raw compute-per-dollar, while DigitalOcean's higher price includes a broader ecosystem (managed databases from $15/month, App Platform, integrated CDN, and more extensive documentation for teams that want to self-manage less).

What a dedicated, production-grade instance costs

Once traffic grows enough that shared-CPU noisy-neighbor effects start to matter, teams typically move to dedicated-core instances. DigitalOcean's own pricing page lists CPU-Optimized Droplets starting at $42/month for 4 GB of memory, scaling up to $168/month for an 8 vCPU / 16 GB configuration. These are dedicated-core instances built for sustained CPU workloads rather than the shared-core Basic tier.

Hetzner's dedicated-vCPU line (CCX) targets the same use case at meaningfully lower list prices, though the two providers structure their tiers differently enough that a precise like-for-like comparison at this spec level needs to be checked against current pricing pages rather than quoted as a fixed figure here.

Where managed PaaS costs actually come from

Modern PaaS platforms rarely charge a flat fee for real workloads. The base subscription (commonly around $20/month per seat on platforms like Vercel's Pro tier) covers a baseline allowance. Beyond that, cost accumulates through several separate meters:
Function execution time, billed once you exceed the included compute-hours
Bandwidth, billed per gigabyte beyond an included allowance
Build minutes, billed once CI/CD usage exceeds the free tier

Because each of these is metered independently, and because platforms with multiple services (an API, a background worker, an admin panel) often meter each service separately, the total can grow substantially beyond the advertised base price. The exact dollar impact depends heavily on actual traffic and usage patterns, which is why platform pricing pages show ranges and calculators rather than single numbers, and why it's worth running your own workload through a provider's current calculator before comparing costs.

The part the "time cost" argument misses

The usual counterargument is that self-hosting costs engineering hours that managed platforms save. That's true, but it isn't the full comparison. The realistic tradeoff isn't "self-hosting time versus zero time." It's "self-hosting time versus PaaS-debugging time": working around usage-based billing surprises, tuning cold-start latency, hitting platform-specific limitations, or migrating everything when a vendor changes its pricing tiers, as Hetzner itself did in April 2026 with advance notice, and as most providers do periodically without much notice at all.

Setting up a bare VPS still requires configuring a reverse proxy, provisioning SSL, and wiring up container networking by hand, work that a deployment platform like try.direct automates. That's the layer where self-hosting's time cost concentrates, and it's largely a one-time setup cost rather than an ongoing one.

Hidden costs on both sides

Neither model is free of costs that don't show up on the pricing page:

Hidden costs of managed PaaS:
Per-service metering that doesn't consolidate, so several small services can cost more together than one larger one on the same infrastructure
Vendor-specific limitations (cold start behavior, execution time caps) that still require engineering workarounds despite the platform being "managed"
Migration risk when a vendor changes pricing tiers; moving a production workload afterward takes real effort

Hidden costs of self-hosting:
Initial setup time for reverse proxy, SSL, and container networking, mostly a one-time cost rather than a recurring one
Backup and monitoring discipline: a self-hosted stack is only as reliable as the backup schedule someone actually maintains
No default uptime SLA on budget VPS providers (Hetzner, for instance, does not publish a formal SLA or credit-backed compensation for cloud downtime), which matters more for workloads where uptime carries real business or compliance weight

When self-hosting doesn't make sense

Not every workload belongs on infrastructure you manage. A good self-hosting candidate has predictable usage, a clear owner, and a straightforward backup and recovery plan the team actually understands. Compliance-heavy systems, or anything where the operational risk of a mistake is high and the team lacks the experience to catch it early, are usually better left on a managed platform, at least until that experience exists in-house.

The right question isn't "can we self-host this." It's "should we own the operation of this".

FAQ

Is self-hosting actually cheaper than managed cloud hosting? For a comparable spec, published VPS pricing (Hetzner, DigitalOcean) is consistently lower than managed PaaS once usage-based overages are factored in. The gap narrows for highly variable or spiky traffic, where managed autoscaling and included support can offset some of the difference.

Why is Hetzner so much cheaper than DigitalOcean for the same specs? The two providers are positioned differently. Hetzner competes primarily on raw compute price and bundles a large traffic allowance; DigitalOcean's higher price includes a broader managed-service ecosystem (managed databases, App Platform, CDN) and more extensive support documentation.

What's the biggest hidden cost of managed PaaS platforms? Usage-based billing across separate meters, execution time, bandwidth, build minutes, and per-service charges that aren't obvious from the base subscription price.

What's the biggest hidden cost of self-hosting? Operational setup time for tasks that deployment tooling can automate: reverse proxy configuration, SSL certificate renewal, container networking, and ongoing backup scheduling.

Manage your self-hosted Docker Compose stacks the easy way ➞ deploy Dockge on try.direct

Managed PaaS base prices hide the real bill. A numbers-first look at self-hosting costs versus managed platforms, using published VPS pricing.

The Real Cost of Self-Hosting in 2026

For a decade, the deal was simple: ship every log, metric, and trace to a vendor, pay per gigabyte, and get a dashboard in return. That deal worked when most systems were monoliths producing a predictable, modest stream of data.

It doesn't work anymore, and the reason isn't pricing. It's volume.

The workload changed, the pricing model didn't

Kubernetes clusters, ephemeral pods, serverless functions, and agentic AI workflows generate telemetry at a scale monoliths never approached. Every pod restart is a log entry. Every microservice hop is a trace. Every LLM call adds token counts, latency, and outcome data that can't be sampled down without losing the signal entirely. Once you sample an AI request, you no longer know what the model actually did.

Observability vendors responded the way SaaS vendors usually do: not by rearchitecting the platform, but by adding more dashboards, more SKUs, and higher tiers. The bill grows faster than the insight.

Bring Your Own Cloud (BYOC) describes an architecture where the data plane, meaning the actual compute that stores and processes your logs, metrics, and traces, runs inside your own cloud account or VPC, while the vendor manages the control plane: upgrades, configuration, orchestration. Your data doesn't leave your environment; the vendor's software runs on top of infrastructure you own.

Worth noting: some BYOC vendors argue the term gets applied loosely, to private connectivity options or dedicated instances that still route data through a shared, vendor-owned pipeline behind the scenes. That's a fair distinction to watch for, though it's also a claim made by vendors competing on exactly this point, so it's worth verifying against a specific platform's architecture documentation rather than taking any single vendor's framing at face value.

Zero trust becomes structural, not aspirational. Data never leaves your environment, so a whole category of compliance questions disappears before it's asked.

Costs track actual usage. You pay for the compute and storage you run, not for an ingestion quota set by someone else's pricing page.

You own the relationship. When the platform runs inside your infrastructure, you're not a tenant negotiating for your own data back. You're the owner deciding what stays and what gets deleted.

AI observability lives where the AI does. As inference and agent workloads move into private VPCs for latency and compliance reasons, the monitoring for those workloads needs to move there too.

The same pattern is playing out across adjacent categories: managed databases deployed inside customer VPCs, AI sandboxes that keep code execution inside the customer's own cloud account, platform-as-a-service tools that deploy CI/CD and GPU workloads directly into AWS, GCP, or bare metal instead of a shared vendor cluster. Observability is simply the latest domain to make the same move, for the same reason: as infrastructure gets more distributed, the tools that watch it need to be distributed too.

You don't need an enterprise BYOC contract to get the benefits. A self-hosted observability stack, Prometheus for metrics, Grafana for dashboards, Loki for logs, running as a Docker Compose stack on infrastructure you control, gives you the same core properties: your telemetry never leaves your environment, your cost scales with your actual usage, and you're not waiting on a vendor's roadmap to support a metric you care about.

The tradeoff historically was operational burden. Someone has to write the compose file, wire up the networks and volumes, manage the reverse proxy, keep the images patched. That's exactly the layer try.direct removes.

You don't have to start with the full metrics-and-logs stack, either. If your team is still relying on a SaaS status page or an external uptime checker, a self-hosted uptime monitor like Uptime Kuma is a reasonable first move: it tells you whether your services are actually up, without sending that data to a third party. It's not a replacement for Prometheus or Grafana, and it won't give you metrics or log correlation, but it's a real, working piece of self-hosted observability you can have running in minutes, before deciding how much further to take the migration.

How the pieces map to what you're replacing

It helps to think in terms of what each self-hosted component replaces, rather than as a generic "monitoring stack":

Prometheus replaces the metrics-ingestion layer of tools like Datadog or New Relic. It scrapes and stores time-series data (CPU, memory, request rates, custom application metrics) at whatever retention you configure, not whatever retention your pricing tier allows.

Grafana replaces the dashboard layer. It reads from Prometheus (and from Loki, and from most common databases) and gives you the same kind of visual drill-down, without a per-seat license.

Loki replaces centralized log aggregation. It's built to index metadata rather than full text, which keeps storage costs down even at high log volume, a meaningful difference once Kubernetes or agentic workloads start generating thousands of log lines a minute.

Alertmanager (bundled with Prometheus) replaces the alerting and on-call routing layer, feeding into whatever notification channel your team already uses.

None of this requires Kubernetes. A single Docker Compose file describing these four services, with the right volumes and a shared network, is enough for most small and mid-sized teams.

Moving off a SaaS observability platform doesn't have to happen in one step:

Start with metrics. Point Prometheus at your existing services alongside your current SaaS tool, running both in parallel for two to four weeks. This gives you a baseline without any risk of losing visibility.

Move dashboards next. Rebuild your most-used SaaS dashboards in Grafana once the underlying metrics are flowing. This is usually the fastest part; most teams only actively use a handful of dashboards.

Migrate logs last. Log pipelines tend to have the most downstream dependencies (existing search queries, saved filters, alert rules), so give this stage the most buffer time.

Cut over alerting once confidence is established. Only redirect on-call alerting to the self-hosted stack after it's been running in parallel long enough to trust it under real incident conditions.

The point of running both in parallel isn't caution for its own sake. It's that observability is the one system you don't want to be debugging blind during a migration.

What is BYOC in simple terms? BYOC (Bring Your Own Cloud) means the vendor's software runs inside your own cloud account or VPC instead of theirs. Your data stays in your environment; the vendor manages the software layer on top of it.

Is BYOC the same as self-hosting? Not quite. Self-hosting means you deploy and operate everything yourself. BYOC means a vendor manages the platform, but the compute and data live in your infrastructure. Both keep data under your control; they differ in who carries the operational load.

Why is AI workload observability different from traditional monitoring? AI workloads produce telemetry, like token usage, latency, and output quality, that represents the actual outcome of the system, not a proxy for it. Sampling this data the way you might sample a web server's access logs means losing information you can't recover.

Do I need Kubernetes to benefit from self-hosted observability? No. Docker Compose stacks benefit just as much. The core issue, vendor lock-in on your own telemetry, applies regardless of orchestration layer.

Start with a real first step ➞ deploy Uptime Kuma in one click on try.direct

For a decade, the deal was simple: ship every log, metric, and trace to a vendor, pay per gigabyte, and get a dashboard in return. That deal worked when most systems were monoliths producing a predictable, modest stream of data.

It doesn't work anymore, and the reason isn't pricing. It's volume.

The workload changed, the pricing model didn't

Kubernetes clusters, ephemeral pods, serverless functions, and agentic AI workflows generate telemetry at a scale monoliths never approached. Every pod restart is a log entry. Every microservice hop is a trace. Every LLM call adds token counts, latency, and outcome data that can't be sampled down without losing the signal entirely. Once you sample an AI request, you no longer know what the model actually did.

Observability vendors responded the way SaaS vendors usually do: not by rearchitecting the platform, but by adding more dashboards, more SKUs, and higher tiers. The bill grows faster than the insight.

What BYOC actually means

Bring Your Own Cloud (BYOC) describes an architecture where the data plane, meaning the actual compute that stores and processes your logs, metrics, and traces, runs inside your own cloud account or VPC, while the vendor manages the control plane: upgrades, configuration, orchestration. Your data doesn't leave your environment; the vendor's software runs on top of infrastructure you own.

Worth noting: some BYOC vendors argue the term gets applied loosely, to private connectivity options or dedicated instances that still route data through a shared, vendor-owned pipeline behind the scenes. That's a fair distinction to watch for, though it's also a claim made by vendors competing on exactly this point, so it's worth verifying against a specific platform's architecture documentation rather than taking any single vendor's framing at face value.

Under this model:
Zero trust becomes structural, not aspirational. Data never leaves your environment, so a whole category of compliance questions disappears before it's asked.
Costs track actual usage. You pay for the compute and storage you run, not for an ingestion quota set by someone else's pricing page.
You own the relationship. When the platform runs inside your infrastructure, you're not a tenant negotiating for your own data back. You're the owner deciding what stays and what gets deleted.
AI observability lives where the AI does. As inference and agent workloads move into private VPCs for latency and compliance reasons, the monitoring for those workloads needs to move there too.

This isn't a niche trend anymore

The same pattern is playing out across adjacent categories: managed databases deployed inside customer VPCs, AI sandboxes that keep code execution inside the customer's own cloud account, platform-as-a-service tools that deploy CI/CD and GPU workloads directly into AWS, GCP, or bare metal instead of a shared vendor cluster. Observability is simply the latest domain to make the same move, for the same reason: as infrastructure gets more distributed, the tools that watch it need to be distributed too.

What this looks like in practice

You don't need an enterprise BYOC contract to get the benefits. A self-hosted observability stack, Prometheus for metrics, Grafana for dashboards, Loki for logs, running as a Docker Compose stack on infrastructure you control, gives you the same core properties: your telemetry never leaves your environment, your cost scales with your actual usage, and you're not waiting on a vendor's roadmap to support a metric you care about.

The tradeoff historically was operational burden. Someone has to write the compose file, wire up the networks and volumes, manage the reverse proxy, keep the images patched. That's exactly the layer try.direct removes.

You don't have to start with the full metrics-and-logs stack, either. If your team is still relying on a SaaS status page or an external uptime checker, a self-hosted uptime monitor like Uptime Kuma is a reasonable first move: it tells you whether your services are actually up, without sending that data to a third party. It's not a replacement for Prometheus or Grafana, and it won't give you metrics or log correlation, but it's a real, working piece of self-hosted observability you can have running in minutes, before deciding how much further to take the migration.

How the pieces map to what you're replacing

It helps to think in terms of what each self-hosted component replaces, rather than as a generic "monitoring stack":
Prometheus replaces the metrics-ingestion layer of tools like Datadog or New Relic. It scrapes and stores time-series data (CPU, memory, request rates, custom application metrics) at whatever retention you configure, not whatever retention your pricing tier allows.
Grafana replaces the dashboard layer. It reads from Prometheus (and from Loki, and from most common databases) and gives you the same kind of visual drill-down, without a per-seat license.
Loki replaces centralized log aggregation. It's built to index metadata rather than full text, which keeps storage costs down even at high log volume, a meaningful difference once Kubernetes or agentic workloads start generating thousands of log lines a minute.
Alertmanager (bundled with Prometheus) replaces the alerting and on-call routing layer, feeding into whatever notification channel your team already uses.

None of this requires Kubernetes. A single Docker Compose file describing these four services, with the right volumes and a shared network, is enough for most small and mid-sized teams.

A practical migration path

Moving off a SaaS observability platform doesn't have to happen in one step:
Start with metrics. Point Prometheus at your existing services alongside your current SaaS tool, running both in parallel for two to four weeks. This gives you a baseline without any risk of losing visibility.
Move dashboards next. Rebuild your most-used SaaS dashboards in Grafana once the underlying metrics are flowing. This is usually the fastest part; most teams only actively use a handful of dashboards.
Migrate logs last. Log pipelines tend to have the most downstream dependencies (existing search queries, saved filters, alert rules), so give this stage the most buffer time.
Cut over alerting once confidence is established. Only redirect on-call alerting to the self-hosted stack after it's been running in parallel long enough to trust it under real incident conditions.

The point of running both in parallel isn't caution for its own sake. It's that observability is the one system you don't want to be debugging blind during a migration.

FAQ

What is BYOC in simple terms? BYOC (Bring Your Own Cloud) means the vendor's software runs inside your own cloud account or VPC instead of theirs. Your data stays in your environment; the vendor manages the software layer on top of it.

Is BYOC the same as self-hosting? Not quite. Self-hosting means you deploy and operate everything yourself. BYOC means a vendor manages the platform, but the compute and data live in your infrastructure. Both keep data under your control; they differ in who carries the operational load.

Why is AI workload observability different from traditional monitoring? AI workloads produce telemetry, like token usage, latency, and output quality, that represents the actual outcome of the system, not a proxy for it. Sampling this data the way you might sample a web server's access logs means losing information you can't recover.

Do I need Kubernetes to benefit from self-hosted observability? No. Docker Compose stacks benefit just as much. The core issue, vendor lock-in on your own telemetry, applies regardless of orchestration layer.

Start with a real first step ➞ deploy Uptime Kuma in one click on try.direct

SaaS monitoring pricing was built for monoliths. Kubernetes and AI workloads broke it. Here is why teams are self-hosting observability instead.

Why SaaS Observability Is Hitting a Wall

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

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

The Fastest Way to Test Any GitHub Project Locally

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

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

Deploy 5 Useful Self-Hosted Apps in 10 Minutes

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

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

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

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

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

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

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

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

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

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.

A managed platform's $20/month base price rarely stays $20. Here's what self-hosting actually costs against published VPS pricing from Hetzner and DigitalOcean, and where each model hides its real costs.

Kubernetes, serverless, and AI agents generate more telemetry than SaaS observability pricing was ever built for. Here's what BYOC actually means, and how to self-host your own metrics, dashboards, and logs without an enterprise contract.

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