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

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

SSH with PEM Key File

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

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

Docker Compose: Deploy Multi-Container Applications

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

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

Fail2Ban: Block SSH Brute Force Attacks

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

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

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

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

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

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

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

Put plainly, the two tools optimize for different things.

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

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

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

The data ownership point that actually matters

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

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

Cookieless tracking and the consent banner

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

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

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

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

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

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

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

Is Matomo a real alternative to Google Analytics 4?

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

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

Can I run Matomo without a cookie consent banner?

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

Do I keep my old Universal Analytics data?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Matomo vs GA4: Own Your Analytics Data

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

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

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

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

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

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

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

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

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

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

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

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

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

Self-hosted vs managed: the honest tradeoff

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

➞ Wazuh

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

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

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

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

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

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

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

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

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

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

Marketplace Acceptable Use Policy

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

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

Marketplace Payout Terms

The 15-minute setup that takes three months to finish

Every MCP server has the same origin story. Someone runs a one-line install, connects it to Claude or another agent, and within fifteen minutes it's pulling data from a ticketing system or a database. It works. It feels like magic.

Then someone asks an obvious question: who else can use this, and what happens when it touches production data?

That question is where the real work begins. The gap between "MCP server running on my laptop" and "MCP infrastructure my whole team can trust" isn't a gap in features. It's a gap in everything that doesn't show up in a quickstart guide: authentication, access control, logging, and isolation.

Here's what actually closes that gap, and how to get there without turning it into a months-long infrastructure project.

The Model Context Protocol (MCP) is a standard that lets AI agents connect to external tools and data sources through a common interface. Instead of writing custom integration code for every tool an agent needs, MCP gives agents a consistent way to discover and call tools.

An MCP gateway sits between AI agents and the MCP servers they talk to. It acts as a single entry point that handles authentication, routing, logging, and policy enforcement for all MCP traffic, instead of leaving every individual MCP server to handle these concerns on its own.

Put simply, an MCP server exposes one set of tools, while an MCP gateway manages access to many MCP servers at once and makes that access auditable and controllable.

Why "it works locally" isn't the same as "it's ready for production"

A local MCP setup usually has no authentication beyond a config file, no logging beyond stdout, and no isolation between what the agent can technically do and what it should be allowed to do. That's fine for one developer testing one tool.

It stops being fine the moment more than one person, one agent, or one environment is involved. At that point, four questions need real answers:

Who is allowed to call which tools? Without role-based access control, every agent that connects to the gateway can call every tool behind it. That's a problem the moment one of those tools can delete records, send emails, or push code.

What did an agent actually do, and when? If an agent takes an unexpected action, "check the logs" needs to mean something. An audit trail that records every tool call, its parameters, and its result is the difference between debugging an incident in minutes and not being able to reconstruct it at all.

Can a tool be restricted without forking it? Sometimes a third-party MCP server exposes more than you want agents to use. Production setups need a way to create a restricted variant of a tool, limiting parameters or disabling specific actions, without modifying the original server's code.

What happens if an agent goes off-script? Sandboxing and short-lived, isolated execution environments contain the blast radius of a misbehaving agent or a malicious prompt injection, so a single bad action doesn't cascade into the rest of the stack.

None of these are exotic requirements. They're the same operational basics that any internal API has had to deal with for years. MCP just brings them back into focus, because the "client" calling your tools is now an autonomous agent making its own decisions about what to call and when.

Self-hosted vs managed: what actually changes

Managed MCP gateway platforms exist for a reason: they hide most of the operational work behind a dashboard. But "hidden" doesn't mean "gone." Someone is still running the gateway, patching it, and deciding what data passes through a third party's infrastructure.

For teams with data residency requirements, contractual restrictions on where data can flow, or simply a preference for owning their stack, self-hosting an MCP gateway makes more sense. The tradeoff has traditionally been operational burden: setting up the gateway, the MCP servers behind it, networking, and monitoring all became someone's part-time job.

That tradeoff is exactly what container orchestration was built to remove. An MCP gateway and the MCP servers it routes to are, from an infrastructure point of view, just another set of containers with defined dependencies, networking rules, and environment variables. The same multi-container patterns used for web app stacks apply directly.

What a self-hosted MCP gateway stack looks like

A practical self-hosted MCP setup is typically composed of a small number of services working together:

A gateway container handles incoming connections from agents, authenticates them, and routes requests to the correct MCP server based on policy.

One or more MCP server containers each expose a specific set of tools: a database connector, a ticketing system integration, a documentation search tool, and so on.

A policy and logging layer stores access rules and writes an audit trail of every tool call, often backed by a small database or log aggregation service.

A network boundary restricts which containers can reach which internal resources, so an MCP server connecting to a ticketing system has no path to, say, a production database it has no business touching.

Defined as a Compose file, this is a handful of services with clear roles and explicit connections between them. The complexity isn't in any single piece. It's in getting all the pieces configured correctly together, and keeping them that way as MCP servers get added or updated.

This is precisely the kind of stack try.direct is built for: multiple containers that need to work together, deployed on infrastructure you control, without hand-assembling configuration from scratch every time.

Instead of provisioning a server, installing Docker, writing a Compose file from a half-finished tutorial, and debugging networking between containers, a pre-composed MCP gateway stack can be deployed and reused as a unit. The gateway, the MCP servers behind it, and the network rules connecting them are defined once and deployed consistently, whether that's a single environment for testing or separate environments for different teams.

For organizations that need their AI agent infrastructure to stay on infrastructure they own, whether for compliance reasons, data residency, or simply control, this turns "self-hosted MCP gateway" from a multi-week infrastructure project into something that can be stood up, modified, and redeployed in the time it takes to review a Compose file.

Is MCP only useful for large enterprises? 

No. The protocol itself is lightweight and works for a single developer connecting one agent to one tool. The gateway layer, with authentication, access control, and audit logging, becomes important once more than one person or one agent depends on the same tools.

Can a self-hosted MCP gateway connect to cloud-based AI models?

Yes. Self-hosting the gateway and the MCP servers behind it controls where your data and tool access live. It doesn't restrict which AI models or agent platforms connect to that gateway; the gateway is the boundary, not the model.

What's the difference between an MCP server and an MCP gateway?

An MCP server exposes a specific set of tools, for example a connector to a single database or ticketing system. A gateway sits in front of one or more MCP servers and handles shared concerns: authentication, routing, access policy, and logging across all of them.

Do I need Kubernetes to run an MCP gateway in production?

Not necessarily. Docker Compose is sufficient for many production deployments, particularly for small to mid-sized teams. Kubernetes adds value at larger scale or when workloads need to scale dynamically, but it isn't a requirement to have authentication, audit logging, and isolation in place.

The hard part of MCP was never the protocol itself. It's everything that surrounds it once the question shifts from "does this work" to "can I trust this in production." Self-hosting closes that gap without handing your data and tool access over to a third party. And with the right deployment approach, it doesn't have to cost you months of infrastructure work either.

The 15-minute setup that takes three months to finish

Every MCP server has the same origin story. Someone runs a one-line install, connects it to Claude or another agent, and within fifteen minutes it's pulling data from a ticketing system or a database. It works. It feels like magic.
Then someone asks an obvious question: who else can use this, and what happens when it touches production data?
That question is where the real work begins. The gap between "MCP server running on my laptop" and "MCP infrastructure my whole team can trust" isn't a gap in features. It's a gap in everything that doesn't show up in a quickstart guide: authentication, access control, logging, and isolation.
Here's what actually closes that gap, and how to get there without turning it into a months-long infrastructure project.

What is an MCP gateway?

The Model Context Protocol (MCP) is a standard that lets AI agents connect to external tools and data sources through a common interface. Instead of writing custom integration code for every tool an agent needs, MCP gives agents a consistent way to discover and call tools.
An MCP gateway sits between AI agents and the MCP servers they talk to. It acts as a single entry point that handles authentication, routing, logging, and policy enforcement for all MCP traffic, instead of leaving every individual MCP server to handle these concerns on its own.
Put simply, an MCP server exposes one set of tools, while an MCP gateway manages access to many MCP servers at once and makes that access auditable and controllable.

Why "it works locally" isn't the same as "it's ready for production"

A local MCP setup usually has no authentication beyond a config file, no logging beyond stdout, and no isolation between what the agent can technically do and what it should be allowed to do. That's fine for one developer testing one tool.
It stops being fine the moment more than one person, one agent, or one environment is involved. At that point, four questions need real answers:
Who is allowed to call which tools? Without role-based access control, every agent that connects to the gateway can call every tool behind it. That's a problem the moment one of those tools can delete records, send emails, or push code.
What did an agent actually do, and when? If an agent takes an unexpected action, "check the logs" needs to mean something. An audit trail that records every tool call, its parameters, and its result is the difference between debugging an incident in minutes and not being able to reconstruct it at all.
Can a tool be restricted without forking it? Sometimes a third-party MCP server exposes more than you want agents to use. Production setups need a way to create a restricted variant of a tool, limiting parameters or disabling specific actions, without modifying the original server's code.
What happens if an agent goes off-script? Sandboxing and short-lived, isolated execution environments contain the blast radius of a misbehaving agent or a malicious prompt injection, so a single bad action doesn't cascade into the rest of the stack.
None of these are exotic requirements. They're the same operational basics that any internal API has had to deal with for years. MCP just brings them back into focus, because the "client" calling your tools is now an autonomous agent making its own decisions about what to call and when.

Self-hosted vs managed: what actually changes

Managed MCP gateway platforms exist for a reason: they hide most of the operational work behind a dashboard. But "hidden" doesn't mean "gone." Someone is still running the gateway, patching it, and deciding what data passes through a third party's infrastructure.
For teams with data residency requirements, contractual restrictions on where data can flow, or simply a preference for owning their stack, self-hosting an MCP gateway makes more sense. The tradeoff has traditionally been operational burden: setting up the gateway, the MCP servers behind it, networking, and monitoring all became someone's part-time job.
That tradeoff is exactly what container orchestration was built to remove. An MCP gateway and the MCP servers it routes to are, from an infrastructure point of view, just another set of containers with defined dependencies, networking rules, and environment variables. The same multi-container patterns used for web app stacks apply directly.

What a self-hosted MCP gateway stack looks like

A practical self-hosted MCP setup is typically composed of a small number of services working together:
A gateway container handles incoming connections from agents, authenticates them, and routes requests to the correct MCP server based on policy.
One or more MCP server containers each expose a specific set of tools: a database connector, a ticketing system integration, a documentation search tool, and so on.
A policy and logging layer stores access rules and writes an audit trail of every tool call, often backed by a small database or log aggregation service.
A network boundary restricts which containers can reach which internal resources, so an MCP server connecting to a ticketing system has no path to, say, a production database it has no business touching.
Defined as a Compose file, this is a handful of services with clear roles and explicit connections between them. The complexity isn't in any single piece. It's in getting all the pieces configured correctly together, and keeping them that way as MCP servers get added or updated.

Where try.direct fits in

This is precisely the kind of stack try.direct is built for: multiple containers that need to work together, deployed on infrastructure you control, without hand-assembling configuration from scratch every time.
Instead of provisioning a server, installing Docker, writing a Compose file from a half-finished tutorial, and debugging networking between containers, a pre-composed MCP gateway stack can be deployed and reused as a unit. The gateway, the MCP servers behind it, and the network rules connecting them are defined once and deployed consistently, whether that's a single environment for testing or separate environments for different teams.
For organizations that need their AI agent infrastructure to stay on infrastructure they own, whether for compliance reasons, data residency, or simply control, this turns "self-hosted MCP gateway" from a multi-week infrastructure project into something that can be stood up, modified, and redeployed in the time it takes to review a Compose file.

Frequently asked questions

Is MCP only useful for large enterprises? 
No. The protocol itself is lightweight and works for a single developer connecting one agent to one tool. The gateway layer, with authentication, access control, and audit logging, becomes important once more than one person or one agent depends on the same tools.

Can a self-hosted MCP gateway connect to cloud-based AI models?
Yes. Self-hosting the gateway and the MCP servers behind it controls where your data and tool access live. It doesn't restrict which AI models or agent platforms connect to that gateway; the gateway is the boundary, not the model.

What's the difference between an MCP server and an MCP gateway?
An MCP server exposes a specific set of tools, for example a connector to a single database or ticketing system. A gateway sits in front of one or more MCP servers and handles shared concerns: authentication, routing, access policy, and logging across all of them.

Do I need Kubernetes to run an MCP gateway in production?
Not necessarily. Docker Compose is sufficient for many production deployments, particularly for small to mid-sized teams. Kubernetes adds value at larger scale or when workloads need to scale dynamically, but it isn't a requirement to have authentication, audit logging, and isolation in place.

The takeaway

The hard part of MCP was never the protocol itself. It's everything that surrounds it once the question shifts from "does this work" to "can I trust this in production." Self-hosting closes that gap without handing your data and tool access over to a third party. And with the right deployment approach, it doesn't have to cost you months of infrastructure work either.

What a self-hosted MCP gateway needs for production: auth, RBAC, audit logs, and sandboxing. Deploy one on your own infrastructure with Docker.

Self-Hosted MCP Gateways: From Demo to Production

AI agents are no longer confined to chat windows. They read files, call APIs, write to databases, and execute code autonomously. That changes the security model entirely. A misconfigured agent is not just a buggy service; it is a privileged process that handles untrusted input and has broad tool access by design.

This guide covers three layers that actually matter: why standard Docker containers are not enough, how gVisor and Kata Containers raise the isolation floor, and how Docker's MCP Toolkit lets you enforce least-privilege at the tool layer.

1. Why Standard Docker Containers Are Not Enough

Docker containers isolate through Linux namespaces, cgroups, and seccomp, but they share the host kernel. Every container on a host calls into the same kernel. That is a fine trade-off for a trusted web server. It is a significant one for a process that dynamically generates and executes code based on external input.

The threat model for an AI agent looks like this:

Container escape (MITRE ATT&CK T1611): a kernel vulnerability or misconfiguration gives an attacker host-level access, reaching every other container on the machine.

Prompt injection leading to RCE: an agent receives a malicious instruction and executes it through a shell tool.

Tool poisoning: hidden directives embedded in MCP tool metadata are visible to the model but not to the user.

Credential exfiltration: an agent with filesystem access can read .env files, ~/.aws/credentials, or service account tokens.

Real-world baseline: A 2025 academic survey of over 1,800 deployed MCP server implementations found that more than 30% had at least one exploitable vulnerability. Endor Labs analysis of 2,614 MCP implementations found that 82% use file operations prone to path traversal and 34% use APIs susceptible to command injection.

CVE-2024-21626 ("Leaky Vessels") showed the concrete risk of shared-kernel runtimes: a process inside a container could set its working directory to /proc/self/fd/7, a leaked file descriptor pointing at the host filesystem, and achieve a full container escape. Affected all runc versions up to 1.1.11, patched in 1.1.12.

2. Stronger Runtimes: gVisor and Kata Containers

gVisor is a Google open-source project that implements the Linux kernel in user-space. A component called Sentry intercepts all syscalls before they reach the host kernel and handles them in an isolated process. From the container's perspective everything looks normal. From the host's perspective, no direct kernel calls ever happen.

Installation requires a single binary (runsc) registered in daemon.json. Any existing image runs without changes since it is OCI-compatible. The overhead is roughly 10 to 30% on I/O-heavy workloads and minimal on compute-heavy ones.

Kata Containers: a micro-VM per container

Kata Containers wraps each container in a lightweight VM with its own Linux kernel via KVM. The hardware boundary eliminates an entire class of kernel-based attacks since there is no shared kernel to escape to. It is OCI-compatible and works with Docker Compose with a single runtime field change.

The trade-offs are cold starts of roughly 100 to 300ms, around 100 MB of extra RAM per container, and no support on macOS or WSL2 (you need bare metal or a cloud instance with nested virtualization). GPU passthrough works with Kata 3.x via VFIO.

How to choose: use gVisor for high-I/O agents where simpler setup matters and a user-space kernel boundary is sufficient. Use Kata Containers when agents execute untrusted, LLM-generated code in production, since the dedicated kernel eliminates the kernel escape vector entirely. Standard runc is appropriate only for agents running fully trusted, reviewed code.

3. Docker MCP Toolkit: Least Privilege at the Tool Layer

Model Context Protocol (MCP) is Anthropic's open standard for connecting LLMs to external tools and data sources. Docker's MCP Toolkit, announced in April 2025 and released in beta in June 2025, solves three problems at once: tool discovery through a catalog of 300+ verified servers on Docker Hub, isolation where each MCP server runs as its own container, and credential management through a Gateway proxy rather than environment variables.

MCP Catalog is a curated registry on Docker Hub with automated testing and scanning. Currently over 300 verified servers including Stripe, Elastic, Neo4j, New Relic, Grafana, and many others.

MCP Toolkit is a Docker Desktop extension for managing server profiles and launching containers. Credentials are stored in Docker Desktop's secure store rather than in environment variables, reducing the risk of accidental exposure through logs or environment dumps.

MCP Gateway is an open-source proxy between MCP clients and servers that enforces policy on every tool call. It handles server lifecycle management, request routing, authentication, logging, and call tracing.

Key principle: By treating each tool as a separate MCP server container, you re-introduce least privilege. Instead of giving an agent broad access, you allow only the smallest set of capabilities it needs. The Gateway enforces this per-call and provides full audit visibility over every tool invocation.

Tool poisoning is a demonstrated attack class first documented publicly by Invariant Labs in April 2025. An attacker who controls an MCP server writes directives directly into tool descriptions or JSON Schema metadata. The model reads this as trusted configuration and executes hidden commands while the user sees nothing unusual. Because these fields arrive at boot as what looks like system configuration, they bypass the mental model most developers have of injection attacks.

The rug pull variant is subtler: a tool's description looks benign on day one, then quietly changes on day seven to redirect API keys to an attacker. MCP clients should alert on any change to tool descriptions after installation.

MCPoison (CVE-2025-54136, CVSS 7.2) is a related but distinct vulnerability discovered by Check Point Research in Cursor IDE. Once a user approved an MCP configuration file, Cursor never re-validated it on subsequent opens. An attacker with write access to a shared repository could commit a benign config, wait for approval, then silently swap in a malicious payload. Every subsequent Cursor launch would execute the attacker's commands with no warning. Fixed in Cursor 1.3, released July 29, 2025.

mcp-remote is a popular OAuth proxy for connecting local MCP clients to remote servers. JFrog Security Research discovered a critical OS command injection flaw (CVSS 9.6/10) in all versions from 0.0.5 up to 0.1.16. A malicious MCP server could send a crafted authorization_endpoint URL that mcp-remote passed directly to the system shell, achieving RCE on the client machine. The package had been downloaded over 437,000 times at the time of disclosure. Fixed in version 0.1.16.

Mitigation: Pin all images by sha256 digest, not by tag. Use only servers from the Docker MCP Catalog with passed verification. Enable signature verification in MCP Gateway. Alert on any change to tool descriptions. Keep mcp-remote at 0.1.16 or later.

When multiple MCP servers connect to the same agent, a malicious server can attempt to override or intercept calls to a trusted one through the model's context window. Network isolation between servers through an internal Docker network with gateway routing limits this attack surface structurally, since servers cannot reach each other without going through the Gateway policy layer.

5. Kubernetes: RuntimeClass for Per-Workload Isolation

For teams running agents on Kubernetes, RuntimeClass lets you assign an isolation level per Pod without changing container images.

Google's Agent Sandbox, a project contributed to CNCF under Kubernetes SIG, is building a standard for agentic workload isolation with gVisor and Kata Containers as pluggable backends. Not yet GA, but worth tracking if you already operate Kubernetes at scale.

Use gVisor or Kata Containers. Never use standard runc for code-executing agents.

Never run containers with --privileged. Drop ALL capabilities and add back only what is needed.

Set read_only: true on the container filesystem. Mount tmpfs for /tmp with noexec.

Bind MCP services to 127.0.0.1 only. Use an internal Docker network with no default egress.

Pin every image by sha256 digest. Never deploy from a mutable tag in production.

Store credentials in Docker Secrets or an external vault, not in environment variables.

Log all tool calls through MCP Gateway. Redact secrets before they reach the model.

Alert on changes to tool descriptions. This is your rug pull detector.

Keep mcp-remote at version 0.1.16 or later. Audit all MCP-related npm packages regularly.

What is Docker MCP and why does it matter for AI agents?

Docker MCP Toolkit is Docker's solution for running MCP servers as isolated containers with managed credentials and policy enforcement. Without it, MCP servers typically run directly on the host with access to the full filesystem. The Toolkit adds a catalog of 300+ verified servers, per-server container isolation, and an open-source Gateway proxy that enforces policy on every tool call and provides full call tracing.

What is the difference between gVisor and Kata Containers?

gVisor implements a Linux kernel in user-space so syscalls are intercepted by an isolated process instead of reaching the host kernel directly. Kata Containers goes further: each container gets its own micro-VM with a dedicated Linux kernel via KVM. gVisor is simpler to set up and works on most environments including cloud VMs; Kata gives stronger, hardware-enforced isolation and is the right choice when agents run untrusted, LLM-generated code in production.

Do I need a different container image for gVisor or Kata?

No. Both runtimes are OCI-compatible. Your existing images run without any changes. You only add a single runtime field to your Compose file or daemon.json.

Tool poisoning embeds malicious instructions in an MCP tool's descriptions or JSON Schema metadata rather than in user input. The model reads this as trusted system configuration and executes the hidden directives. Invariant Labs first documented this attack class in April 2025. Defense includes using only catalog-verified servers pinned by digest, enabling Gateway policy enforcement, and monitoring for any changes to tool descriptions after initial installation.

AI agents are no longer confined to chat windows. They read files, call APIs, write to databases, and execute code autonomously. That changes the security model entirely. A misconfigured agent is not just a buggy service; it is a privileged process that handles untrusted input and has broad tool access by design.
This guide covers three layers that actually matter: why standard Docker containers are not enough, how gVisor and Kata Containers raise the isolation floor, and how Docker's MCP Toolkit lets you enforce least-privilege at the tool layer.

1. Why Standard Docker Containers Are Not Enough

Docker containers isolate through Linux namespaces, cgroups, and seccomp, but they share the host kernel. Every container on a host calls into the same kernel. That is a fine trade-off for a trusted web server. It is a significant one for a process that dynamically generates and executes code based on external input.
The threat model for an AI agent looks like this:
Container escape (MITRE ATT&CK T1611): a kernel vulnerability or misconfiguration gives an attacker host-level access, reaching every other container on the machine.
Prompt injection leading to RCE: an agent receives a malicious instruction and executes it through a shell tool.
Tool poisoning: hidden directives embedded in MCP tool metadata are visible to the model but not to the user.
Credential exfiltration: an agent with filesystem access can read .env files, ~/.aws/credentials, or service account tokens.

Real-world baseline: A 2025 academic survey of over 1,800 deployed MCP server implementations found that more than 30% had at least one exploitable vulnerability. Endor Labs analysis of 2,614 MCP implementations found that 82% use file operations prone to path traversal and 34% use APIs susceptible to command injection.

CVE-2024-21626 ("Leaky Vessels") showed the concrete risk of shared-kernel runtimes: a process inside a container could set its working directory to /proc/self/fd/7, a leaked file descriptor pointing at the host filesystem, and achieve a full container escape. Affected all runc versions up to 1.1.11, patched in 1.1.12.

2. Stronger Runtimes: gVisor and Kata Containers

gVisor: a kernel in user-space
gVisor is a Google open-source project that implements the Linux kernel in user-space. A component called Sentry intercepts all syscalls before they reach the host kernel and handles them in an isolated process. From the container's perspective everything looks normal. From the host's perspective, no direct kernel calls ever happen.
Installation requires a single binary (runsc) registered in daemon.json. Any existing image runs without changes since it is OCI-compatible. The overhead is roughly 10 to 30% on I/O-heavy workloads and minimal on compute-heavy ones.

 

 

Kata Containers: a micro-VM per container
Kata Containers wraps each container in a lightweight VM with its own Linux kernel via KVM. The hardware boundary eliminates an entire class of kernel-based attacks since there is no shared kernel to escape to. It is OCI-compatible and works with Docker Compose with a single runtime field change.
The trade-offs are cold starts of roughly 100 to 300ms, around 100 MB of extra RAM per container, and no support on macOS or WSL2 (you need bare metal or a cloud instance with nested virtualization). GPU passthrough works with Kata 3.x via VFIO.

 
How to choose: use gVisor for high-I/O agents where simpler setup matters and a user-space kernel boundary is sufficient. Use Kata Containers when agents execute untrusted, LLM-generated code in production, since the dedicated kernel eliminates the kernel escape vector entirely. Standard runc is appropriate only for agents running fully trusted, reviewed code.

3. Docker MCP Toolkit: Least Privilege at the Tool Layer

Model Context Protocol (MCP) is Anthropic's open standard for connecting LLMs to external tools and data sources. Docker's MCP Toolkit, announced in April 2025 and released in beta in June 2025, solves three problems at once: tool discovery through a catalog of 300+ verified servers on Docker Hub, isolation where each MCP server runs as its own container, and credential management through a Gateway proxy rather than environment variables.

The three components
MCP Catalog is a curated registry on Docker Hub with automated testing and scanning. Currently over 300 verified servers including Stripe, Elastic, Neo4j, New Relic, Grafana, and many others.
MCP Toolkit is a Docker Desktop extension for managing server profiles and launching containers. Credentials are stored in Docker Desktop's secure store rather than in environment variables, reducing the risk of accidental exposure through logs or environment dumps.
MCP Gateway is an open-source proxy between MCP clients and servers that enforces policy on every tool call. It handles server lifecycle management, request routing, authentication, logging, and call tracing.

Key principle: By treating each tool as a separate MCP server container, you re-introduce least privilege. Instead of giving an agent broad access, you allow only the smallest set of capabilities it needs. The Gateway enforces this per-call and provides full audit visibility over every tool invocation.

Hardened Compose config

 

4. MCP Attack Patterns You Need to Know

Tool poisoning
Tool poisoning is a demonstrated attack class first documented publicly by Invariant Labs in April 2025. An attacker who controls an MCP server writes directives directly into tool descriptions or JSON Schema metadata. The model reads this as trusted configuration and executes hidden commands while the user sees nothing unusual. Because these fields arrive at boot as what looks like system configuration, they bypass the mental model most developers have of injection attacks.
The rug pull variant is subtler: a tool's description looks benign on day one, then quietly changes on day seven to redirect API keys to an attacker. MCP clients should alert on any change to tool descriptions after installation.

MCPoison: CVE-2025-54136
MCPoison (CVE-2025-54136, CVSS 7.2) is a related but distinct vulnerability discovered by Check Point Research in Cursor IDE. Once a user approved an MCP configuration file, Cursor never re-validated it on subsequent opens. An attacker with write access to a shared repository could commit a benign config, wait for approval, then silently swap in a malicious payload. Every subsequent Cursor launch would execute the attacker's commands with no warning. Fixed in Cursor 1.3, released July 29, 2025.

Supply chain: CVE-2025-6514
mcp-remote is a popular OAuth proxy for connecting local MCP clients to remote servers. JFrog Security Research discovered a critical OS command injection flaw (CVSS 9.6/10) in all versions from 0.0.5 up to 0.1.16. A malicious MCP server could send a crafted authorization_endpoint URL that mcp-remote passed directly to the system shell, achieving RCE on the client machine. The package had been downloaded over 437,000 times at the time of disclosure. Fixed in version 0.1.16.

Mitigation: Pin all images by sha256 digest, not by tag. Use only servers from the Docker MCP Catalog with passed verification. Enable signature verification in MCP Gateway. Alert on any change to tool descriptions. Keep mcp-remote at 0.1.16 or later.

Cross-server hijacking
When multiple MCP servers connect to the same agent, a malicious server can attempt to override or intercept calls to a trusted one through the model's context window. Network isolation between servers through an internal Docker network with gateway routing limits this attack surface structurally, since servers cannot reach each other without going through the Gateway policy layer.

5. Kubernetes: RuntimeClass for Per-Workload Isolation

For teams running agents on Kubernetes, RuntimeClass lets you assign an isolation level per Pod without changing container images.

 

 
Google's Agent Sandbox, a project contributed to CNCF under Kubernetes SIG, is building a standard for agentic workload isolation with gVisor and Kata Containers as pluggable backends. Not yet GA, but worth tracking if you already operate Kubernetes at scale.

6. Production Security Checklist

Use gVisor or Kata Containers. Never use standard runc for code-executing agents.
Never run containers with --privileged. Drop ALL capabilities and add back only what is needed.
Set read_only: true on the container filesystem. Mount tmpfs for /tmp with noexec.
Bind MCP services to 127.0.0.1 only. Use an internal Docker network with no default egress.
Pin every image by sha256 digest. Never deploy from a mutable tag in production.
Store credentials in Docker Secrets or an external vault, not in environment variables.
Log all tool calls through MCP Gateway. Redact secrets before they reach the model.
Alert on changes to tool descriptions. This is your rug pull detector.
Keep mcp-remote at version 0.1.16 or later. Audit all MCP-related npm packages regularly.

FAQ

What is Docker MCP and why does it matter for AI agents?
Docker MCP Toolkit is Docker's solution for running MCP servers as isolated containers with managed credentials and policy enforcement. Without it, MCP servers typically run directly on the host with access to the full filesystem. The Toolkit adds a catalog of 300+ verified servers, per-server container isolation, and an open-source Gateway proxy that enforces policy on every tool call and provides full call tracing.

What is the difference between gVisor and Kata Containers?
gVisor implements a Linux kernel in user-space so syscalls are intercepted by an isolated process instead of reaching the host kernel directly. Kata Containers goes further: each container gets its own micro-VM with a dedicated Linux kernel via KVM. gVisor is simpler to set up and works on most environments including cloud VMs; Kata gives stronger, hardware-enforced isolation and is the right choice when agents run untrusted, LLM-generated code in production.

Do I need a different container image for gVisor or Kata?
No. Both runtimes are OCI-compatible. Your existing images run without any changes. You only add a single runtime field to your Compose file or daemon.json.

What is MCP tool poisoning?
Tool poisoning embeds malicious instructions in an MCP tool's descriptions or JSON Schema metadata rather than in user input. The model reads this as trusted system configuration and executes the hidden directives. Invariant Labs first documented this attack class in April 2025. Defense includes using only catalog-verified servers pinned by digest, enabling Gateway policy enforcement, and monitoring for any changes to tool descriptions after initial installation.

What was CVE-2025-6514?
CVE-2025-6514 was a critical (CVSS 9.6) OS command injection vulnerability in mcp-remote, a widely used npm package for connecting MCP clients to remote servers via OAuth. A malicious MCP server could craft an authorization_endpoint URL that mcp-remote passed directly to the system shell. Discovered by JFrog Security Research, disclosed July 9, 2025, and fixed in mcp-remote version 0.1.16.

Conclusion

AI agents are privileged processes that handle untrusted input. Standard Docker container isolation was not designed for this threat model.
The practical floor for production in 2026 is gVisor for I/O-heavy agents, Kata Containers for anything executing untrusted code, Docker MCP Gateway as the policy enforcement point for every tool call, and digest-pinned images throughout. The MCP ecosystem is maturing fast and so is its CVE list. The tools to defend it exist today. The gap is architectural decisions, not missing technology.

How to run AI agents securely in Docker using gVisor, Kata Containers, and MCP Toolkit. Real CVEs, attack patterns, and hardened Compose configs included.

Docker AI Agents: Isolation, Security & MCP

In 2026, running your own AI stack is no longer a weekend experiment for power users. A $8/month VPS, three open-source tools, and one Docker Compose file is all it takes to replace $100+/month in SaaS subscriptions with full control over your data, no rate limits, and no per-token costs.

This guide walks you through deploying Ollama (local LLM inference), Open WebUI (ChatGPT-like interface), n8n (AI workflow automation), and PostgreSQL on your own server (production-ready), SSL-secured, and running in under 30 minutes.

Ollama - local LLM inference (Llama 3, Mistral, Qwen)

Open WebUI - ChatGPT-like interface connected to your models

n8n - AI workflow automation with 1,400+ integrations

PostgreSQL - persistent storage for workflows and chat history

Traefik - reverse proxy with automatic SSL

Total cost: $6-20/month on Hetzner, DigitalOcean, or any Linux VPS.

Data sovereignty. Your prompts, documents, and workflow logic never leave your server.

Cost at scale. ChatGPT Plus runs $20/user/month. Zapier hits $100+/month at moderate usage. One VPS replaces both for your entire team.

No rate limits. Your inference, your rules.

VPS with Ubuntu 22.04+, minimum 8GB RAM, 4 vCPUs (Hetzner CX32 = ~$8/month)

Your AI interface is live at https://ai.yourdomain.com and your automation engine at https://n8n.yourdomain.com.

First Workflow: AI-Powered Document Summarizer

Once n8n is running, create this workflow in 5 minutes:

HTTP Request node → call Ollama's API at http://ollama:11434/api/generate

Send Email / Slack — deliver the summary

n8n and Ollama run on the same Docker network, so no external API calls - zero latency, zero cost per token.

Model	              RAM Required	     Best For

Llama 3.2 3B	      4 GB	             Fast responses, basic tasks

Mistral 7B	      6 GB	             General purpose, good quality

Qwen 2.5 14B	     12 GB	             High quality, needs 16GB+ VPS

Start with llama3.2 on any 8GB server. Upgrade when you hit quality limits.

Never expose Ollama port 11434 publicly , it has no auth by default. Restrict IP access with iptables.

Use .env files, never hardcode passwords in compose.yml

Enable Open WebUI's user management for team access

Set up automatic backups for the postgres_data and n8n_data volumes

Yes. CPU inference works for models up to 7B parameters. Responses are slower (5-15 seconds) but fully functional. A GPU (even a used RTX 3090) drops response time to under 1 second.

What's the difference from using the OpenAI API?

Your data stays on your server. No per-token costs. Models run offline. Tradeoff: frontier models like GPT-4o are still ahead in reasoning quality, use the self-hosted stack for 90% of tasks, keep a cloud API key for edge cases.

In 2026, running your own AI stack is no longer a weekend experiment for power users. A $8/month VPS, three open-source tools, and one Docker Compose file is all it takes to replace $100+/month in SaaS subscriptions with full control over your data, no rate limits, and no per-token costs.

This guide walks you through deploying Ollama (local LLM inference), Open WebUI (ChatGPT-like interface), n8n (AI workflow automation), and PostgreSQL on your own server (production-ready), SSL-secured, and running in under 30 minutes.

What You'll Build

A fully functional AI stack you own:
Ollama - local LLM inference (Llama 3, Mistral, Qwen)
Open WebUI - ChatGPT-like interface connected to your models
n8n - AI workflow automation with 1,400+ integrations
PostgreSQL - persistent storage for workflows and chat history
Traefik - reverse proxy with automatic SSL
Total cost: $6-20/month on Hetzner, DigitalOcean, or any Linux VPS.

Why Self-Host in 2026?

Data sovereignty. Your prompts, documents, and workflow logic never leave your server.
Cost at scale. ChatGPT Plus runs $20/user/month. Zapier hits $100+/month at moderate usage. One VPS replaces both for your entire team.
No rate limits. Your inference, your rules.

Prerequisites

VPS with Ubuntu 22.04+, minimum 8GB RAM, 4 vCPUs (Hetzner CX32 = ~$8/month)
Docker and Docker Compose v2 installed
A domain pointing to your server

The Stack: docker-compose.yml

 

Deploy in 4 Commands

 

Your AI interface is live at https://ai.yourdomain.com and your automation engine at https://n8n.yourdomain.com.

First Workflow: AI-Powered Document Summarizer

Once n8n is running, create this workflow in 5 minutes:
Trigger: webhook or email
HTTP Request node → call Ollama's API at http://ollama:11434/api/generate
Set: format the response
Send Email / Slack — deliver the summary
n8n and Ollama run on the same Docker network, so no external API calls - zero latency, zero cost per token.

Model Recommendations for This Hardware

Model	              RAM Required	     Best For
Llama 3.2 3B	      4 GB	             Fast responses, basic tasks
Mistral 7B	      6 GB	             General purpose, good quality
Qwen 2.5 14B	     12 GB	             High quality, needs 16GB+ VPS

Start with llama3.2 on any 8GB server. Upgrade when you hit quality limits.

Security Checklist

Never expose Ollama port 11434 publicly , it has no auth by default. Restrict IP access with iptables.
Use .env files, never hardcode passwords in compose.yml
Enable Open WebUI's user management for team access
Set up automatic backups for the postgres_data and n8n_data volumes

Frequently Asked Questions

Can I run this without a GPU?
Yes. CPU inference works for models up to 7B parameters. Responses are slower (5-15 seconds) but fully functional. A GPU (even a used RTX 3090) drops response time to under 1 second.
What's the difference from using the OpenAI API?
Your data stays on your server. No per-token costs. Models run offline. Tradeoff: frontier models like GPT-4o are still ahead in reasoning quality, use the self-hosted stack for 90% of tasks, keep a cloud API key for edge cases.
Can I connect n8n to external AI APIs too?
Yes. n8n has native OpenAI, Anthropic, and Google AI nodes. Mix local and cloud inference in the same workflow.

Ready to Deploy Your Own AI Stack?

This tutorial covers the foundation. If you want a pre-configured, production-ready version of this stack with management, monitoring, and one-click deployment explore our ready-made Docker stacks:
→ Browse AI Self-Hosting Stacks

Self-host Ollama, Open WebUI, and n8n on your own VPS for under $20/month. Full Docker Compose setup with SSL, PostgreSQL, and step-by-step deployment guide.

Dashboard

TryDirect blog