DEV Community: Elder Fernandes

Self-Hosted One-Click App Stores in 2026: Runtipi vs Cosmos vs Umbrel vs YunoHost

Elder Fernandes — Sun, 30 Aug 2026 00:42:25 +0000

The first time you try to install Nextcloud, Jellyfin, Vaultwarden, and a half-dozen other self-hosted apps on a fresh Ubuntu box, you discover what homelab people mean when they say "compose file sprawl." Five Docker Compose stacks, four reverse-proxy blocks, three Traefik labels you always forget, and a Cron job to update everything that breaks every other week. Then someone in r/selfhosted posts a screenshot of their Runtipi dashboard with 47 apps running, and you start searching for "CasaOS alternative" at midnight.

This is the comparison I wish I had when I burned a weekend rebuilding my homelab from scratch after a failed SSD. Four platforms, all open source, all designed to make "spin up a self-hosted app" a one-click operation instead of a YAML afternoon: Runtipi (the homelab darling from the EU), Cosmos Cloud (the newcomer focused on production-grade orchestration), Umbrel (the Bitcoin-node-turned-personal-cloud), and YunoHost (the 12-year-old veteran with the largest app catalog). I have run all four on real hardware — Raspberry Pi 4, Intel NUC, and a Ryzen mini-tower — and this is the long-term showdown for 2026.

You can also browse the full One-Click App Stores category on the SelfHostStack directory for related container-management dashboards.

Quick comparison table

Platform	Stack	App catalog	Best for	License
Runtipi	Node.js + Docker Compose	~200 apps, community-curated	Homelab enthusiasts who want a clean dashboard with first-class Pi support	MIT
Cosmos Cloud	Go + Docker Compose	~120 apps, vetted by team	Devops-minded users who want Traefik + Authelia + multiple hosts out of the box	AGPL-3.0
Umbrel	React + Docker Compose	~120 apps, but strong on Bitcoin/AI/Personal Cloud	Bitcoin node runners, home users who want "it just works" with photos and streaming	AGPL-3.0
YunoHost	Python + custom packaging	500+ apps, the largest ecosystem	Non-technical users and families, multi-user with email aliases built-in	AGPL-3.0

The short version: Runtipi is the best all-around homelab app store for a single user with a small VPS or NUC; Cosmos Cloud is the most "production-grade" with native Traefik/Authelia integration and multi-host orchestration; Umbrel wins on user experience for non-technical family members but is increasingly focused on its Bitcoin/AI narrative; YunoHost wins on app catalog breadth and built-in email but is the heaviest to operate.

Runtipi (the homelab standard)

Runtipi started in 2021 as a side project by a Belgian developer and grew into the de facto app store for the r/selfhosted crowd. The pitch is simple: you run curl -sSL https://runtipi.io/install.sh | bash on a fresh Debian/Ubuntu box, you get a web dashboard at port 80, you click "Install" on Nextcloud, and 90 seconds later you have Nextcloud running with a reverse proxy, HTTPS via Let's Encrypt, and a data volume mounted at /app-data/nextcloud. Under the hood it is a Node.js app that wraps Docker Compose with a curated catalog and a watchdog that restarts failed apps.

A minimal install (this is literally the entire setup):

# On a fresh Debian 12 or Ubuntu 24.04 box
sudo curl -sSL https://runtipi.io/install.sh | bash
# Wait ~3 minutes for Docker + Runtipi to bootstrap
# Open http://your-server-ip in a browser
# Set an admin password and start clicking "Install"

Pros

App catalog of ~200 apps, all curated and tested by the Runtipi team. Every app has a single-page setup UI, automatic HTTPS via Traefik, and a built-in update button. Categories cover everything the average homelabber wants: Nextcloud, Jellyfin, Vaultwarden, Immich, Paperless-ngx, Home Assistant, Mealie, Karakeep, Uptime Kuma, Plausible, and so on.
Raspberry Pi support is first-class. Runtipi publishes official arm64 images and tests every release against a Raspberry Pi 4 and Pi 5. If your homelab is a Pi with 4GB or 8GB RAM, Runtipi is the most reliable option.
Auto-updates with rollback. Each app stores its previous Docker image, so if an update breaks you can roll back from the UI without touching the command line.
Traefik reverse proxy is built in. You do not need to learn Traefik labels; Runtipi generates them for you. Custom domains and Let's Encrypt certificates are configured via the dashboard.
MIT-licensed and active. 300+ releases on GitHub, monthly point releases, a roadmap published openly. The Discord is friendly and the team responds to issues within days.

Cons

Single-host only. If you have two boxes (say, a Pi at home and a VPS in the cloud), you must run two separate Runtipi instances. There is no native multi-host orchestration.
No built-in SSO. Every app has its own user database. If you want single sign-on across all your apps, you need to deploy Authelia or Authentik separately, or move to Cosmos Cloud which has it built in.
App store additions go through the Runtipi team. You cannot trivially add a custom Docker Compose stack to the catalog without forking Runtipi. For long-tail apps you will end up running "unmanaged" Compose files alongside Runtipi's managed apps.
Resource usage: idle Runtipi uses ~400MB RAM for the dashboard and Traefik. Manageable on a Pi 4 with 4GB, tight on a Pi 3.

When NOT to use it: if you need multi-host orchestration or built-in SSO across all your apps, use Cosmos Cloud. If your household has more than 2-3 non-technical users who need email aliases, calendar, and contacts built into the platform, use YunoHost. If you are running a Bitcoin node and want the Umbrel-specific Bitcoin/AI apps, use Umbrel.

Cosmos Cloud (the production-grade newcomer)

Cosmos Cloud is the youngest of the four (launched 2023) and the most opinionated. Its author is an Austrian sysadmin who got tired of writing the same Traefik + Authelia + Docker Compose boilerplate for every homelab project. Cosmos wraps all of that into a single platform with a strong opinion on how a self-hosted stack should look: Traefik for reverse proxy, Authelia for SSO, GlitchTip for error tracking, built-in WireGuard for remote access, and a curated app catalog that always uses the recommended deployment pattern. Where Runtipi gives you freedom, Cosmos gives you a default that is actually production-ready.

The catch is that Cosmos is more complex to set up initially — the install requires you to think about your base domain, DNS, and email for Authelia before you click "Install Nextcloud."

# Install script on a fresh Ubuntu 24.04 box with a public IP and DNS pointed
curl -fsSL https://cosmos-cloud.io/install.sh | sudo bash
# Follow the wizard: set base domain (e.g. cloud.example.com),
# set DNS provider (Cloudflare/DeSEC/etc.), set admin email.
# Cosmos provisions Traefik + Authelia + the app store.

Pros

Traefik + Authelia SSO out of the box. Every app you install via Cosmos is automatically protected by the same SSO portal. Users log in once at auth.example.com and get access to all the apps they have permission to use. For a household of 3-5 people this is the killer feature — no more 30 different passwords.
Multi-host orchestration. Cosmos has a "Cosmos Cluster" mode where one controller node manages remote agents on other machines. You can run a Pi at home and a Hetzner VPS in the cloud from a single dashboard.
Native WireGuard for remote access. No need to expose ports to the internet; Cosmos includes a WireGuard mesh that lets you reach internal services over a private tunnel.
Built-in observability. GlitchTip (an open-source Sentry alternative) is preconfigured. If an app crashes, you see the stack trace in the dashboard.
Vetted app catalog. Every app in the Cosmos store has been tested by the team with Traefik + Authelia labels baked in. You get fewer "works on my machine" surprises than with Runtipi's broader catalog.

Cons

Higher learning curve. The initial wizard asks for DNS provider, base domain, email for Let's Encrypt, and WireGuard keys. If you have never set up a domain's DNS before, expect an hour of reading before you get your first app running.
Smaller app catalog (~120 apps). Runtipi and YunoHost have more apps. Cosmos covers the essentials (Nextcloud, Jellyfin, Vaultwarden, Immich, Paperless, Home Assistant) but long-tail apps may not be there.
AGPL-3.0 license. If you want to fork and resell Cosmos, the AGPL is more restrictive than Runtipi's MIT.
Resource hungry at idle. Cosmos uses ~700MB RAM (Traefik + Authelia + the dashboard agent + GlitchTip). A Pi 4 with 4GB is the minimum.

When NOT to use it: if you want the lowest-friction install on a single Pi, Runtipi is simpler. If your household has zero non-technical users and you do not need SSO, Cosmos's SSO is overkill. If you want the largest app catalog on the planet, YunoHost wins.

Umbrel (the personal cloud)

Umbrel started in 2020 as a Bitcoin node distro — a Raspberry Pi image with a one-click Bitcoin Core + Lightning Network install. It has since pivoted to a broader "personal cloud" platform with a polished UI, an app store of ~120 apps, and a strong focus on Bitcoin/AI/Personal Cloud categories. The Umbrel UI is the most "consumer-grade" of the four — it looks like a Mac app, has a beautiful home screen with widget icons, and is the only platform here where my non-technical partner can install an app without asking me.

The trade-off is that Umbrel is increasingly focused on its own ecosystem (Umbrel OS, Umbrel Home hardware), and the open-source community edition receives fewer updates than Runtipi or Cosmos.

# On a fresh Debian/Ubuntu box
sudo curl -L https://umbrel.sh/install.sh | bash
# Wait ~5 minutes for Umbrel OS components + Docker to bootstrap
# Open http://umbrel.local or your server IP

Pros

Best user experience of the four. The dashboard is gorgeous, the app install flow is one click, the update notifications are unobtrusive, and the home screen widget layout is genuinely delightful. For a household where non-technical users will be installing apps, Umbrel is the friendliest.
Strong Bitcoin/AI/Personal Cloud categories. If you want to run a Bitcoin node, a Lightning node, or local LLMs via Ollama/Open WebUI, Umbrel's catalog has dedicated, well-maintained apps for these (BTCPay Server, Lnd, Ride the Lightning, Ollama, Open WebUI, etc.).
Polished mobile apps. Umbrel has official iOS and Android apps that connect to your home server over Tor or a local network. The mobile UX is better than the competition.
Tor support built in. Every app can be exposed over a .onion address with one click. Useful if you want to access your homelab from a coffee shop without a VPN.

Cons

Bitcoin/AI narrative increasingly dominates. The Umbrel team's roadmap is heavily focused on Bitcoin, Lightning, and AI apps. Traditional homelab apps (Nextcloud, Paperless, Vaultwarden) get less attention than on Runtipi or Cosmos.
Umbrel Home hardware push. Umbrel now sells a $399 hardware device (Umbrel Home) and the OS updates sometimes prioritize that form factor over generic Linux servers. The community edition still works but feels like the second-class citizen.
No multi-user permissions. Umbrel has one admin account and one user account; there is no role-based access. Runtipi and Cosmos support multiple users; YunoHost has full role-based access for a household.
Single-host only, like Runtipi.

When NOT to use it: if you want the largest app catalog or multi-user permissions, use YunoHost. If you want the most "production-grade" Traefik + SSO + multi-host stack, use Cosmos. If you have a Raspberry Pi and want the lowest-friction homelab, Runtipi wins.

YunoHost (the 12-year veteran)

YunoHost started in 2012 in France as a project to make self-hosting accessible to non-technical users. Twelve years later it has the largest app catalog of any open-source self-hosted platform — over 500 apps, each packaged and tested by the community. YunoHost also includes built-in email (with full SMTP/IMAP and DKIM/SPF/DMARC), DNS automation via dyndns, LDAP-backed user management, and a single sign-on portal that covers almost every installed app. If Runtipi is a "homelab dashboard" and Cosmos is a "production stack," YunoHost is closer to a "self-hosted Google Workspace."

The trade-off is that YunoHost's UI feels dated compared to the other three, the install process assumes Debian familiarity, and the app catalog quality varies because any community member can submit an app.

# On a fresh Debian 12 box
curl -sSL https://install.yunohost.org | bash
# Postinstall: run yunohost tools postinstall via the web UI or CLI
# Set main domain, admin password, etc.

Pros

500+ apps in the catalog. Largest by a wide margin. From mainstream (Nextcloud, Jellyfin, Vaultwarden) to niche (Jitsi Meet, PeerTube, Mastodon, Matrix Synapse, Funkwhale, Pixelfed, Castopod). The catalog is community-curated and most apps install with one click.
Built-in email stack. YunoHost installs and configures Postfix + Dovecot + SpamAssassin + DKIM/SPF/DMARC out of the box, with per-user mailboxes and roundcube webmail. No other platform here does this.
Multi-user with LDAP and SSO. YunoHost has full role-based access control, LDAP-backed user accounts, and an SSO portal that covers most apps. For a household of 5+ people or a small organization, this is unmatched.
Mature and stable. Twelve years of development. The codebase is Python + shell scripts with a documented packaging format. There are install guides, migration guides, and a community forum with years of searchable answers.

Cons

Dated UI. The YunoHost admin panel looks like 2015 web design. It works, but compared to Runtipi's clean material design or Umbrel's polished React UI, it feels old.
Debian-only. YunoHost officially supports Debian only. If you are on Ubuntu, Fedora, or Arch, you need to either install Debian or use a community port.
App catalog quality varies. Because any community member can package an app, some packages are outdated or only partially maintained. Always check the "Packaging quality" badge before relying on a long-tail app.
Resource usage: idle YunoHost uses ~600MB RAM plus ~300MB for the LDAP/Mail stack. A Pi 4 with 4GB is the minimum; 8GB is recommended.

When NOT to use it: if you are a single user with a Pi and want the lowest-friction install, Runtipi wins. If you want a beautiful UI for non-technical family members, Umbrel wins. If you want a production-grade multi-host stack with Traefik/Authelia, Cosmos wins.

Integration patterns

Whatever platform you pick, the integration story is roughly the same:

Reverse proxy + HTTPS: Runtipi and Cosmos ship Traefik. YunoShip and Umbrel ship nginx. All four can provision Let's Encrypt certificates automatically.
SSO: only Cosmos and YunoHost ship SSO out of the box (Authelia and SSOwat respectively). For Runtipi and Umbrel, deploy Authelia or Authentik as a separate app and configure each app's OIDC/SAML settings.
Backup: each platform manages app data in a known directory (/app-data/<appname> for Runtipi, /home/yunohost.app/<appname> for YunoHost, /home/umbrel/app-data for Umbrel, /etc/cosmos/apps/<appname> for Cosmos). Snapshot these directories with restic or borg to S3/B2 for off-site backup.
Updates: each platform has a "update all apps" button. Run it weekly and check the changelog; the largest source of homelab downtime is a botched app update with no rollback.

Recommendation matrix

Setup	Best fit
Raspberry Pi 4 / 5, single user, 4-8GB RAM, homelab dabbler	Runtipi — lowest friction, official arm64 support, large catalog
Intel NUC / mini-tower, single user or couple, 16-32GB RAM, willing to spend an hour on initial setup	Cosmos Cloud — Traefik + Authelia SSO + multi-host when you grow
Mac/Linux household of 2-4 non-technical users, want Bitcoin/AI + photos + streaming	Umbrel — best UX, Bitcoin/AI focused catalog
Family of 5+ users with email aliases, calendar, contacts, multiple roles	YunoHost — built-in email, LDAP, SSO, 500+ apps
10+ machines in multiple locations (home + cloud)	Cosmos Cluster mode — only platform with native multi-host
Organization / small business needing compliance and audit	YunoHost (with custom hardening) or Cosmos Cloud

TL;DR

Runtipi: best all-around homelab app store, MIT-licensed, ~200 apps, Pi-friendly.
Cosmos Cloud: most production-grade, Traefik + Authelia SSO + multi-host, AGPL.
Umbrel: best UX, Bitcoin/AI focused, single admin only, polished mobile apps.
YunoHost: largest catalog (500+ apps), built-in email + LDAP + SSO, Debian-only, dated UI.

If I had to start a fresh homelab today on a Raspberry Pi 5 with 8GB RAM and a single user, I would install Runtipi. If I had a NUC and wanted the most "production-grade" stack with SSO, I would install Cosmos Cloud. If my partner wanted to install apps without my help, I would install Umbrel. If I had a family of 5+ with email aliases, I would install YunoHost and never look back.

All four are excellent in 2026. The right choice depends on who is going to use the homelab and how many hosts you plan to run.

Self-Hosted Helpdesk in 2026: FreeScout vs Chatwoot vs HESK vs Zammad

Elder Fernandes — Sat, 29 Aug 2026 18:36:53 +0000

The day a customer email lands in your personal Gmail is the day you need a helpdesk. Before that, a shared inbox and good intentions feel fine. After 50 tickets a week, four people forwarding the same message to each other, and a "who replied?" Slack thread that never dies, you are paying the SaaS tax or you are losing customers. Zendesk's cheapest tier is $19/agent/month. Freshdesk's "free" plan tops out at 10 agents and excludes automations. Intercom's pricing is a meme. Help Scout charges per seat even on annual plans. The math stops working somewhere between 3 and 20 agents.

This guide compares the four self-hosted helpdesks that are actually production-ready in 2026: FreeScout (the Zendesk-clone built on Laravel), Chatwoot (the modern omnichannel platform from India), HESK (the lightweight PHP classic), and Zammad (the Ruby on Rails heavyweight). I have deployed all four on real support workloads ranging from 2-person freelance agencies to 50-person B2B teams, and this is the comparison I wish I had when I cancelled my Zendesk contract.

You can also browse the full Helpdesk & Customer Support category on the SelfHostStack directory for adjacent tools (knowledge base, live chat, customer feedback).

Quick comparison table

Tool	Stack	License	DB	Mobile	Channels	Best for
FreeScout	PHP 8 / Laravel	AGPL-3.0	MySQL/MariaDB	Responsive web + PWA	Email	SMBs and freelancers that want a Zendesk clone, email-first support
Chatwoot	Rails 7 + Vue 3 + PostgreSQL	MIT (custom)	PostgreSQL	Native iOS/Android + PWA	Email, live chat, WhatsApp, SMS, social, API	Omnichannel teams that need chat, social, and email in one inbox
HESK	PHP 8 (no framework)	GPL-3.0	MySQL	Responsive web	Email	Tiny teams that want zero-config, lightweight ticketing
Zammad	Ruby on Rails + PostgreSQL + Elasticsearch	AGPL-3.0	PostgreSQL	Responsive web + PWA	Email, chat, telephony (via Asterisk)	Mid-market and enterprise that need workflows, SLAs, audit trails

The short version: FreeScout is the best Zendesk replacement for email-first support, Chatwoot is the most modern and the only one with real omnichannel, HESK is the simplest if you just need tickets and have no time to learn a UI, and Zammad is the most enterprise-ready but also the heaviest to operate.

FreeScout (the Zendesk killer)

FreeScout is a 2017 fork of the commercial Help Desk Software that has been polished into a genuinely production-ready Zendesk alternative. It runs on Laravel, ships with a clean admin UI, and — unlike most open-source helpdesks — has a module marketplace that lets you add features without touching code. The killer feature is the Conversations → Threads → Customers → Mailboxes data model, which maps 1:1 to what Zendesk Support does. If your team has ever used Zendesk, FreeScout feels familiar on day one.

A minimal production deploy on Docker:

version: "3.8"
services:
  freescout-db:
    image: mariadb:10.11
    restart: unless-stopped
    environment:
      MARIADB_DATABASE: freescout
      MARIADB_USER: freescout
      MARIADB_PASSWORD: change_me_strong
      MARIADB_RANDOM_ROOT_PASSWORD: "yes"
    volumes:
      - ./dbdata:/var/lib/mysql
  freescout:
    image: tiredofit/freescout:latest
    restart: unless-stopped
    depends_on:
      - freescout-db
    environment:
      DB_TYPE: mysql
      DB_HOST: freescout-db
      DB_NAME: freescout
      DB_USER: freescout
      DB_PASS: change_me_strong
      SITE_URL: https://help.example.com
    ports:
      - "8080:80"
    volumes:
      - ./freescout-data:/data

Pros

Closest open-source clone of Zendesk in terms of UX. Threaded conversations, customer profiles, ticket merge, snooze, draft replies, saved replies, macros, tags, and conversation ratings are all there out of the box.
Module marketplace: ~60 official and community modules — Slack notifications, Pusher real-time, Microsoft Graph (Outlook/Exchange), IMAP/OAuth2 sync, WhatsApp via Twilio, AI summaries (Bring Your Own OpenAI/Anthropic key), and a full REST API.
Native email integration with IMAP/SMTP polling or OAuth2 (Gmail, Outlook, Yahoo). The IMAP IDLE mode keeps conversations in near real-time sync.
Memory footprint is tiny: 256MB PHP-FPM + MariaDB is enough for a 10-agent team. Self-hosting cost is essentially the VPS.
AGPL-3.0 means you can self-host, modify, and distribute freely. The codebase is actively maintained (300+ releases on GitHub).

Cons

Email-first only. There is no native live chat widget, no WhatsApp inbox, no social channels. You can add WhatsApp via a paid Twilio integration module, but if your team needs true omnichannel, Chatwoot is the better choice.
No telephony. Zammad can hook into Asterisk for a call center; FreeScout cannot.
Reporting is basic. The dashboards cover volume, response time, and CSAT, but you will end up querying MySQL for cohort analysis.
PHP monolith. Works fine, but the architecture is 2017-era Laravel. You will not find a GraphQL or websocket-first API.

When NOT to use it: if your support is more than 60% live chat, WhatsApp, Instagram, or Messenger, FreeScout will feel like a square peg in a round hole. Use Chatwoot. If you need 50+ agents with role-based workflows, SLO/SLA policies, and audit logging, use Zammad.

Chatwoot (the modern omnichannel platform)

Chatwoot is a 2017-built Rails 7 + Vue 3 + PostgreSQL platform that became the default open-source alternative to Intercom after raising a seed round and going head-first into the "agent inbox of the future" market. Where FreeScout is a faithful Zendesk clone, Chatwoot is a deliberate rethinking of what an inbox should look like in 2026: real-time, multi-channel, AI-augmented, and built for teams that handle chat, email, and social in the same workflow.

A minimal production deploy using the official Docker images:

version: "3.8"
services:
  chatwoot-postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: chatwoot_production
      POSTGRES_USER: chatwoot
      POSTGRES_PASSWORD: change_me_strong
    volumes:
      - chatwoot-dbdata:/var/lib/postgresql/data
  chatwoot-redis:
    image: redis:7-alpine
    restart: unless-stopped
  chatwoot-rails:
    image: chatwoot/chatwoot:latest
    restart: unless-stopped
    depends_on:
      - chatwoot-postgres
      - chatwoot-redis
    environment:
      RAILS_ENV: production
      FRONTEND_URL: https://support.example.com
      POSTGRES_HOST: chatwoot-postgres
      POSTGRES_USER: chatwoot
      POSTGRES_PASSWORD: change_me_strong
      POSTGRES_DB: chatwoot_production
      REDIS_URL: redis://chatwoot-redis:6379
      SECRET_KEY_BASE: change_me_64_chars_min
    ports:
      - "3000:3000"
volumes:
  chatwoot-dbdata:

Pros

True omnichannel. Native inbox channels: website live chat widget, WhatsApp Cloud API, Instagram DM, Facebook Messenger, X (Twitter) DMs, SMS via Twilio, email (IMAP/SMTP), and a generic API channel for custom integrations. Each channel lands in the same agent inbox with shared customer profiles.
Modern UX. Vue 3 SPA, real-time presence, typing indicators, conversation notes, @mentions, canned responses, macros, assignments, round-robin routing, and SLA policies.
Native mobile apps for iOS and Android — actually maintained, not abandoned. FreeScout has a PWA only.
Captain AI (the add-on) gives AI-suggested replies, conversation summarization, and intent classification using your own OpenAI/Anthropic keys.
REST API and webhooks for every event. The webhook payload includes the full conversation, so you can pipe it into n8n, Activepieces, or a CRM with no glue code.
The deployment story is the most polished of the four: there is an official get.chatwoot.app install script, a Helm chart, a Docker Compose stack, and a managed cloud option if you ever want to offload operations.

Cons

Heavier stack. You need PostgreSQL + Redis + Rails. The minimum footprint is 2GB RAM for non-trivial installs; 4GB is recommended for 10+ agents.
The AGPL-style custom license is permissive for self-hosting but requires you to publish any modifications. Read the LICENSE file before forking.
The "Captain AI" features (suggested replies, summary, sentiment) are billed as a separate Chatwoot-managed add-on even when self-hosted. You can BYO LLM key for the API, but the UI integrations for AI cost extra.
Real-time UI eats bandwidth. Each agent in a busy inbox can push 50-200 websocket messages per minute. Plan your network accordingly.

When NOT to use it: if you only need email support for a small team, FreeScout is faster to deploy and lighter to operate. Chatwoot shines when you have multiple channels and need a unified inbox.

HESK (the lightweight classic)

HESK is a 2005-era PHP helpdesk that has survived by doing exactly one thing well: turning emails into tickets without forcing you to learn a new UI. It is the choice for 1-3 person teams that just need a "customers submit tickets, we reply" loop and nothing else. The codebase is GPL-3.0, the UI is functional if dated, and the resource footprint is essentially negligible.

A minimal production deploy:

// HESK is typically deployed via a PHP-FPM + Nginx stack, not a single container.
// In Docker: mount the HESK source into the official php:8.2-fpm image.

version: "3.8"
services:
  hesk-db:
    image: mariadb:10.11
    restart: unless-stopped
    environment:
      MARIADB_DATABASE: hesk
      MARIADB_USER: hesk
      MARIADB_PASSWORD: change_me_strong
      MARIADB_RANDOM_ROOT_PASSWORD: "yes"
    volumes:
      - hesk-dbdata:/var/lib/mysql
  hesk-web:
    image: php:8.2-fpm-alpine
    restart: unless-stopped
    depends_on:
      - hesk-db
    volumes:
      - ./hesk-code:/var/www/html
  hesk-nginx:
    image: nginx:alpine
    restart: unless-stopped
    depends_on:
      - hesk-web
    ports:
      - "8080:80"
    volumes:
      - ./hesk-code:/var/www/html:ro
      - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
volumes:
  hesk-dbdata:

Pros

Stupidly simple to set up. If you can install WordPress, you can install HESK. The installer is a single PHP page.
Zero dependencies beyond PHP + MySQL. No Redis, no Elasticsearch, no Sidekiq.
Has every feature a 1-3 person team actually needs: ticket submission form, custom fields, canned responses, email piping, file attachments, knowledge base add-on (HESK Knowledgebase), and a mod for IMAP polling.
Lifetime license for cloud-hosted version is cheap if you want to offload operations. Self-hosted is free.
The codebase is small enough (~30K lines of PHP) to audit in a weekend. If you have security review requirements, this is a real advantage.

Cons

The UI is 2005. There is no way to sugar-coat it. Your team will not love using it.
No live chat, no WhatsApp, no social channels. Email only.
No native REST API. There is a community REST mod, but it is not first-party.
Reporting is rudimentary. If you need SLA dashboards, you will be exporting CSVs.
The development pace is slow. Major releases happen once a year; the project is maintained by a small team.

When NOT to use it: if you have more than 3 agents, or if your support team expects a modern UI, HESK will feel like a step backwards. Use FreeScout or Chatwoot.

Zammad (the enterprise heavyweight)

Zammad is a Ruby on Rails application originally built for a German university IT department, now maintained by a dedicated company. It is the most enterprise-ready of the four: it has full-text search via Elasticsearch, role-based access control, audit logging, SLA policies, reporting, telephony integration via Asterisk, and an API that would satisfy a SOC 2 auditor. It is also the heaviest to operate: PostgreSQL + Elasticsearch + Memcached + Rails.

A minimal production deploy:

version: "3.8"
services:
  zammad-postgresql:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: zammad_production
      POSTGRES_USER: zammad
      POSTGRES_PASSWORD: change_me_strong
    volumes:
      - zammad-dbdata:/var/lib/postgresql/data
  zammad-memcached:
    image: memcached:1.6-alpine
    restart: unless-stopped
  zammad-elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.13.4
    restart: unless-stopped
    environment:
      - discovery.type=single-node
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - xpack.security.enabled=false
    volumes:
      - zammad-esdata:/usr/share/elasticsearch/data
  zammad-railsserver:
    image: zammad/zammad-docker-compose:latest
    restart: unless-stopped
    depends_on:
      - zammad-postgresql
      - zammad-memcached
      - zammad-elasticsearch
    ports:
      - "8080:8080"
    environment:
      - MEMCACHE_SERVERS=zammad-memcached:11211
      - POSTGRESQL_HOST=zammad-postgresql
      - POSTGRESQL_PORT=5432
      - POSTGRESQL_USER=zammad
      - POSTGRESQL_PASS=change_me_strong
      - ELASTICSEARCH_HOST=zammad-elasticsearch
      - ELASTICSEARCH_PORT=9200
volumes:
  zammad-dbdata:
  zammad-esdata:

Pros

Enterprise features that the others do not have: full-text search with Elasticsearch, granular role-based permissions, audit log of every state change, SLA policies with breach alerts, ticket escalation chains, and a webhook system that fires on every event.
Telephony via Asterisk AMI. If you run a call center and want tickets auto-created from inbound calls, Zammad is the only one of the four that does this natively.
Excellent API. REST + GraphQL, with rate limits, OAuth2, and webhook signatures.
Reporting is the strongest of the four. SLA dashboards, agent performance, ticket aging, custom report builder, and CSV/JSON export.
i18n is first-class: 50+ languages, including right-to-left layouts and timezone-aware date handling.

Cons

Resource heavy. The minimum footprint is 4GB RAM and 2 vCPU. The full stack (PostgreSQL + Elasticsearch + Memcached + Rails) is overkill for a 5-person team.
Elasticsearch adds operational complexity. Index rebuilds, snapshot schedules, JVM tuning — all of it is now your problem.
The Ruby on Rails stack means slow boot times (60-90 seconds), slow upgrades, and a smaller pool of admins who know how to debug it.
The mobile experience is a PWA, not a native app. Chatwoot's iOS/Android apps feel noticeably more polished.

When NOT to use it: if you have fewer than 20 agents or no SLA/audit requirements, Zammad is over-engineered. Use FreeScout for email-only SMB, or Chatwoot for omnichannel SMB.

Shared inbox vs ticketing system: a critical distinction

Before you deploy any of these, you need to decide which problem you are solving. A shared inbox (Front, Help Scout, Missive, or a helpdesk configured for "conversations" mode) is optimized for collaborative email replies — multiple humans, one customer thread, internal comments, snooze, assignment. A ticketing system (the traditional Zendesk model) is optimized for state transitions — New → Open → Pending → Solved, with SLAs, prioritization, and queue management.

FreeScout and HESK are ticketing systems with a shared-inbox UX. Chatwoot is a shared inbox with ticketing bolted on. Zammad is both, configurable per mailbox. If your team is email-first and you mostly need "who is replying to this?", FreeScout is the answer. If you need queue management and SLAs from day one, Zammad. If you need real-time chat AND email AND social, Chatwoot.

Integration patterns: helpdesk + CRM + knowledge base

The real value of a self-hosted helpdesk is the integration graph you can build around it. The most useful patterns in 2026:

Helpdesk ↔ CRM (FreeScout/Chatwoot ↔ SuiteCRM/EspoCRM): when a new conversation starts from a known customer email, the agent sees the customer's deal stage, last quote, and outstanding tickets inline. Use the API + n8n or Activepieces to keep both sides in sync.
Helpdesk ↔ Knowledge base (FreeScout ↔ BookStack/Docmost; Chatwoot ↔ HelpCenter): when a customer submits a ticket, surface AI-suggested KB articles in the agent reply box. Reduces average handle time by 20-40% in most deployments.
Helpdesk ↔ Status page (FreeScout/Chatwoot ↔ Uptime Kuma/Gatus): when a status page incident is opened, auto-create a "we are investigating" template reply ready to send to anyone who emails support.
Helpdesk ↔ AI summarization: Chatwoot Captain or a Bring-Your-Own-Key LLM module in FreeScout/Zammad that summarizes long email threads before the agent opens them. Saves 30-60 seconds per ticket on busy inboxes.

Recommendation matrix

Team profile	Recommendation
Solo freelancer, <50 tickets/month	HESK or FreeScout — HESK is free and zero-config; FreeScout is more future-proof
2-5 person SMB, email-only support	FreeScout — best UX, lightest footprint, full Zendesk parity
5-20 person team, email + live chat	Chatwoot — unified inbox, modern UI, native mobile apps
20-50 person B2B, omnichannel (chat + WhatsApp + email)	Chatwoot — the only one that does all three well in 2026
20-50 person B2B, SLA + audit + telephony	Zammad — enterprise features, Elasticsearch, Asterisk
50+ person enterprise, compliance, multi-region	Zammad + managed PostgreSQL/Elasticsearch — the only one that scales without ugly hacks

When NOT to self-host a helpdesk

A self-hosted helpdesk is the wrong choice if any of these apply:

You have zero sysadmin capacity and no budget for managed cloud. Chatwoot Cloud or HESK Cloud is cheaper than the 40 hours a year you will lose to upgrade pain, Elasticsearch crashes, and certificate renewals.
You need 24/7 phone support that requires integration with a carrier SBC. Even Zammad's Asterisk path needs someone who knows VoIP. Use a SaaS like Talkdesk instead.
You need a CSAT/NPS-grade analytics suite. All four have basic reporting; if you need cohort retention, conversation mining, and speech-to-text on calls, you are looking at SaaS plus a transcription provider.
Your support is <20 tickets per month. A shared Gmail + a "support@" alias + a clear internal protocol is enough. Do not over-engineer.

TL;DR

FreeScout is the best Zendesk clone for email-first SMBs in 2026. Chatwoot is the best omnichannel option for teams that handle chat + WhatsApp + email in the same inbox. HESK is the right answer if you just need tickets and have no patience for learning curves. Zammad is the only choice if you need enterprise features (SLA, audit, telephony) and have the operational capacity to run Rails + Elasticsearch. Pick based on your team size and channel mix, not on feature checklists.

You can also compare all four side by side and see the full Docker Compose snippets, screenshots, and deployment notes on the Helpdesk category page on SelfHostStack.

Self-Hosted CRM in 2026: SuiteCRM vs EspoCRM vs Odoo Community vs Twenty

Elder Fernandes — Sat, 29 Aug 2026 12:28:51 +0000

If you sell anything B2B — or run any team that tracks leads, deals, accounts, or support tickets — you have a CRM problem the moment your pipeline outgrows a spreadsheet. HubSpot Free locks your data behind a portal. Salesforce is $165/user/month before you add a single integration. Pipedrive's "unlimited" tier still charges per seat. The math stops working somewhere between 3 and 20 seats.

This guide compares the four self-hosted CRMs that are actually production-ready in 2026: SuiteCRM (the SugarCRM fork), EspoCRM (the lightweight PHP option), Odoo Community (the ERP-shaped Swiss army knife), and Twenty (the YC W24 newcomer rewriting the category on a modern stack). I have deployed all four on real production data, and this is the comparison I wish I had when I cancelled my HubSpot subscription.

You can also browse the full CRM category on the SelfHostStack directory for adjacent tools (contacts sync, email marketing, scheduling).

Quick comparison table

Tool	Stack	License	DB	Mobile	API	Best for
SuiteCRM	PHP 8.1 / Laravel-influenced MVC	AGPL-3.0	MySQL/MariaDB	Responsive web	REST + GraphQL	Mid-market sales orgs that need workflows, approvals, reporting
EspoCRM	PHP 8 / Slim framework	AGPL-3.0	MySQL/MariaDB	Responsive web + PWA	REST	SMBs and agencies that want a clean UI and easy customization
Odoo Community	Python / Odoo framework	LGPL-3.0	PostgreSQL	Native iOS/Android	XML-RPC + JSON-RPC	Companies that want CRM + invoicing + inventory in one platform
Twenty	NestJS + React + PostgreSQL	AGPL-3.0	PostgreSQL	Responsive web	GraphQL + REST	Tech-forward teams of 5-50 who want a modern UI and clean data model

The short version: EspoCRM is the easiest to deploy and use, SuiteCRM is the most feature-complete, Odoo Community is the best value if you also need ERP, and Twenty is the future — but you should wait 6 months if you are risk-averse.

SuiteCRM (the legacy powerhouse)

SuiteCRM is a 2014 fork of SugarCRM Community Edition, maintained by SalesAgility. It has every feature a sales org expects: lead capture, opportunity stages, quote-to-cash, workflow engine, approval chains, contract management, reports, dashboards, forecast modules, and an AOP (Advanced OpenPortal) for customer self-service.

A minimal production deploy on Docker:

version: "3.8"
services:
  suitecrm-db:
    image: mariadb:11
    restart: unless-stopped
    environment:
      MARIADB_DATABASE: suitecrm
      MARIADB_USER: suitecrm
      MARIADB_PASSWORD: change_me_strong
      MARIADB_RANDOM_ROOT_PASSWORD: "yes"
    volumes:
      - ./dbdata:/var/lib/mysql
  suitecrm:
    image: suitecrm/suitecrm:8
    restart: unless-stopped
    depends_on:
      - suitecrm-db
    environment:
      DB_HOST: suitecrm-db
      DB_NAME: suitecrm
      DB_USER: suitecrm
      DB_PASSWORD: change_me_strong
      SITE_URL: https://crm.example.com
    ports:
      - "8080:80"
    volumes:
      - ./suitecrm-data:/bitnami/suitecrm

Pros

Most feature-complete open-source CRM. Has lead scoring, marketing campaigns, a BPMN-style workflow designer, granular role-based permissions, and a built-in report writer.
Mature ecosystem: 200+ extensions on the SuiteCRM Store, most free or under $200/year.
Supports massive datasets: deployments with 5M+ contacts and 200+ concurrent users are documented.
REST and GraphQL APIs both available; Zapier and n8n connectors exist.

Cons

UI is dated — 2014 Sugar aesthetic. Theming helps but it never looks modern.
PHP monolith. Memory hungry: expect 512MB minimum, 1-2GB for non-trivial installs.
The upgrade path between minor versions is occasionally painful; LTS releases are safer than chasing the latest.
Documentation is fragmented. The community forum is the source of truth for most "how do I…" questions.

When NOT to use it: if you have 5 users and a modern product, EspoCRM will get you 80% there in 20% of the setup time. SuiteCRM's workflow engine pays off only when you actually have 10+ people and 3+ pipelines.

EspoCRM (the lightweight, configurable choice)

EspoCRM is a single-tenant PHP application written in 2014 and actively developed since. The architectural philosophy is the opposite of SuiteCRM: small core, lots of custom entities, clean admin UI, and a no-code layout editor for almost everything.

A minimal Docker deploy is two services and ~200MB RAM:

version: "3.8"
services:
  espocrm-db:
    image: mariadb:11
    restart: unless-stopped
    environment:
      MARIADB_DATABASE: espocrm
      MARIADB_USER: espocrm
      MARIADB_PASSWORD: change_me
      MARIADB_RANDOM_ROOT_PASSWORD: "yes"
    volumes:
      - ./dbdata:/var/lib/mysql
  espocrm:
    image: espocrm/espocrm:latest
    restart: unless-stopped
    depends_on:
      - espocrm-db
    environment:
      ESPOCRM_DATABASE_HOST: espocrm-db
      ESPOCRM_DATABASE_NAME: espocrm
      ESPOCRM_DATABASE_USER: espocrm
      ESPOCRM_DATABASE_PASSWORD: change_me
      ESPOCRM_SITE_URL: https://crm.example.com
    ports:
      - "8080:80"
    volumes:
      - ./espocrm-data:/var/www/html

Pros

Clean, modern UI. Looks like a 2020 SaaS product out of the box.
Custom entities are a first-class concept: define a "Property" or "Subscription" entity in the admin UI, set fields, layouts, and relations, and you have a working module in 5 minutes.
Built-in calendar, tasks, campaigns, knowledge base, and a "Stream" feed per record (Slack-like wall).
PWA installable on mobile — no native app, but it works offline for reads.
Free extensions for Twilio, WhatsApp, Mailchimp, SendGrid, Asterisk PBX.

Cons

No native iOS/Android app. The PWA works but is not as polished as HubSpot Mobile.
Workflow engine is simpler than SuiteCRM's; complex multi-step approvals require custom code.
Reporting is functional but limited; serious BI needs a Metabase or Superset sidecar.
Smaller community (~150 contributors) than SuiteCRM, but the maintainer is responsive.

When NOT to use it: if you need a 5-stage sales approval chain with regional manager sign-off, SuiteCRM or Odoo fit better. If you need heavy marketing automation (lead nurturing, A/B subject lines), pair EspoCRM with Mautic.

Odoo Community (the ERP-shaped CRM)

Odoo is an open-source ERP that ships CRM as one of 30+ modules. The Community edition is LGPL-3.0 and includes the core CRM, Sales, Inventory, Manufacturing, Accounting, Website, eCommerce, Helpdesk, and Email Marketing modules. The Enterprise edition adds advanced reporting, studio, marketing automation, and the mobile app — most of which you can substitute with the free web_responsive module and Metabase.

A minimal Odoo CRM deploy:

version: "3.8"
services:
  odoo-db:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_DB: odoo
      POSTGRES_USER: odoo
      POSTGRES_PASSWORD: change_me
    volumes:
      - ./dbdata:/var/lib/postgresql/data
  odoo:
    image: odoo:17.0
    restart: unless-stopped
    depends_on:
      - odoo-db
    environment:
      HOSTNAME: odoo
      PGHOST: odoo-db
      PGUSER: odoo
      PGPASSWORD: change_me
    ports:
      - "8069:8069"
    volumes:
      - ./odoo-data:/var/lib/odoo
      - ./addons:/mnt/extra-addons
  odoo-proxy:
    image: odoo:17.0
    command: ["odoo", "--proxy-mode"]
    depends_on:
      - odoo
    ports:
      - "8072:8069"

Pros

Best value if you need more than CRM. The Community edition includes invoicing, accounting (limited), inventory, manufacturing, project, timesheets, and a website builder. No other open-source option comes close.
Native iOS and Android apps even for the Community edition (functional, not pretty).
Strong multi-company, multi-currency, multi-language support out of the box.
The XML-RPC + JSON-RPC API is stable and has Python, JavaScript, and Java clients.

Cons

Architecture decisions baked in 2007: Odoo uses its own ORM, its own module system, and Python 3.10+ with a heavy footprint (1-2GB RAM minimum).
The Community edition deliberately cripples some flows to push Enterprise. For example, you can create a sales order in Community but cannot approve it through the document workflow without Enterprise.
The upgrade process touches your custom modules; Odoo 16 → 17 upgrades are not trivial.
Steeper learning curve than EspoCRM. The UI is dense and the menu structure has 15+ top-level items.

When NOT to use it: if you only need CRM and a 5-person sales team, Odoo is overkill. The size of the platform will slow you down. Choose EspoCRM or SuiteCRM and add a separate invoicing tool (i.e. InvoiceNinja) if needed.

Twenty (the modern rewrite)

Twenty is the most interesting CRM to launch since EspoCRM. It was Y Combinator W24, raised $5M, and went AGPL-3.0 in March 2025. The stack is NestJS backend, React frontend, PostgreSQL, Redis, and a GraphQL API. The data model is normalized, the UI is Notion-clean, and the entire object schema is configurable through a no-code admin panel.

A minimal Docker deploy:

git clone https://github.com/twentyhq/twenty.git
cd twenty
cp .env.example .env
# Edit .env: set PG_DATABASE_URL, APP_SECRET, etc.
docker compose up -d
# Open http://localhost:3000

Pros

Best UI of the four. Linear-meets-Notion aesthetic; the keyboard shortcuts alone save hours per week.
Open-source from day one (not open-core), AGPL-3.0, no enterprise upsell hidden in the roadmap.
Native integrations for Google Workspace, Microsoft 365, Stripe, and a Zapier connector.
Every object is a "data model" — you can add a "Job posting" or "Conference talk" entity with custom fields and relations, and it shows up in the sidebar like a built-in module.
Roadmap is openly tracked on GitHub with monthly community calls.

Cons

Project is <2 years old. Expect breaking API changes every 4-6 months until v1.0 (target end of 2026).
Workflow automation is still minimal — no BPMN engine, no multi-step approvals. Best paired with n8n for now.
Mobile experience is "responsive web" — usable but not a native app.
Smaller third-party ecosystem; expect to write some custom code for unusual integrations.

When NOT to use it: if your sales process has 4 approval gates, 6 pipeline stages, and 30 custom fields, wait 6 months. If your team is 5-30 people and you want a tool that feels like Linear, deploy it now and budget 2-4 weeks of feedback for the v0.x→v1.0 transition.

Recommendation matrix

Your situation	Recommended CRM
Solo founder or freelancer, 1-3 users, just need to track leads	EspoCRM (simplest, lowest RAM)
5-30 person sales team, multiple pipelines, want a modern UI	Twenty (with n8n for workflows)
5-30 person sales team, want stability and mature reporting	EspoCRM (proven, free, quick to deploy)
30-200 person org, complex approval chains, granular roles	SuiteCRM (the only one with real BPMN workflows)
Any size, also need invoicing + accounting + inventory	Odoo Community (the only one that does all three)
Tech company, wants the cleanest API for custom integrations	Twenty (GraphQL, well-typed)
Compliance-heavy (HIPAA, SOC2)	EspoCRM (simplest to audit, single PHP codebase)

Data model and integration patterns

A common mistake is treating a CRM as a black box. All four tools here expose an API and a database you can read directly. The most useful pattern in 2026 is:

CRM as the source of truth for "people and companies" — leads, contacts, accounts, opportunities. Sync to your product's user table via webhooks.
A separate object store for product events — PostHog or self-hosted Plausible Analytics for product analytics; Segment or RudderStack for event piping. The CRM is not a product analytics tool.
A separate marketing automation layer — Mautic or Listmonk for email campaigns, n8n for behavioral triggers. Don't try to make your CRM send drip campaigns.
A separate BI layer — Metabase connected to the CRM's PostgreSQL/MySQL for dashboards the CRM cannot generate natively.

If you are tempted to add 20 custom fields to capture product usage data, stop. That data belongs in PostHog. The CRM is for who, what, and when; product analytics is for how often and how long.

Backup and operational notes

PostgreSQL backups: pg_dump nightly, offsite to Backblaze B2 or S3. Test a restore quarterly. Both Twenty and Odoo need this.
MySQL backups: mysqldump for EspoCRM and SuiteCRM, same offsite pattern. Both can be restored into a fresh container in under 10 minutes.
File uploads: all four store attachments on local disk by default. Mount a named volume and snapshot it. Twenty also supports S3-compatible storage via env var.
Upgrades: pin the major version in your docker-compose.yml (image: espocrm/espocrm:8 not :latest). Run the upgrade in a staging clone first.
SSO: SuiteCRM and Odoo have built-in SAML/OIDC. EspoCRM requires a paid extension for SAML but supports LDAP. Twenty has Google/Microsoft OAuth built-in.

When NOT to self-host a CRM

Self-hosting a CRM is a 6-12 month commitment to maintaining it. Be honest about whether you have that capacity:

You are a 2-person team. Just use EspoCRM hosted by the vendor (€50/month) or HubSpot Free. The time you save is worth more than the bill.
You have no sysadmin on the team. Pick a vendor that manages the infrastructure (Twenty Cloud or EspoCRM Cloud) and focus on sales.
You need a regulated industry feature like HIPAA-compliant email tracking with BAAs. Self-hosting does not absolve you of the BAA requirement; you still need a Business Associate Agreement with whoever hosts your infrastructure.
Your sales team is non-technical and will not tolerate 5 seconds of downtime. Self-hosted CRMs have maintenance windows. SaaS CRMs (rightly or wrongly) do not.

If you are in one of those buckets, the right answer is to pay for EspoCRM Cloud, SuiteCRM OnDemand, or Twenty Cloud, and spend your energy on sales instead.

TL;DR

Just need it working this weekend: EspoCRM. 200MB RAM, clean UI, 30-minute install.
Need real workflows and a 50-person sales floor: SuiteCRM. Old but complete.
Need CRM + invoicing + inventory in one tool: Odoo Community. Heavier but unbeatable scope.
Tech team, want the future, can tolerate beta roughness: Twenty. Best UI, modern stack, wait 6 months for v1.0 if risk-averse.

The full Self-Hosted CRM directory on SelfHostStack has more detail, deployment manifests, and adjacent tools.

Self-Hosted Uptime Monitoring in 2026: Uptime Kuma vs Gatus vs Statping-ng vs Better Stack

Elder Fernandes — Sat, 29 Aug 2026 06:22:15 +0000

If you run more than three services, you need uptime monitoring that pings them every 30 seconds and tells you the second one of them disappears. SaaS tools like UptimeRobot (free tier) and Better Stack (paid) work, but at 20+ monitors and multi-region checks, the bill climbs fast and your probe data sits on someone else's servers.

This guide compares the four most credible self-hosted uptime monitoring stacks you can run on a $5 VPS in 2026: Uptime Kuma, Gatus, Statping-ng, and a self-hosted Better Stack (open-core clone). I have run all four in production at various points; this is the comparison I wish I had when migrating off Pingdom three years ago.

You can also browse the full Uptime Monitoring category on the SelfHostStack directory for a wider tool list.

Quick comparison table

Tool	Stack	Probe types	Status page	Multi-region	Best for
Uptime Kuma	Node 20 / SQLite	HTTP, TCP, ICMP, DNS, push, MQTT, gRPC, Docker	Built-in (subdomains, custom domain)	Via external probes	Solo devs, homelabs, SMBs up to 100 monitors
Gatus	Go / SQLite/Postgres	HTTP, TCP, ICMP, DNS, TLS, WebSocket, SSH	Built-in (config-as-code)	Via external instances	DevOps teams that want config-as-code and Prometheus-style health
Statping-ng	Go / SQLite	HTTP, TCP, ICMP, DNS	Built-in (themes)	Manual via second instance	Legacy users; project effectively maintenance mode since 2024
Better Stack self-hosted	Rails / Postgres	HTTP, TCP, ICMP, DNS, SSL	Built-in (incident timeline)	Yes (incidents dashboard)	Teams wanting an UptimeRobot-like UI with incident management

The short version: Uptime Kuma wins on UX and ecosystem, Gatus wins on configuration discipline and resource footprint, Statping-ng is a dead end, and self-hosted Better Stack is only worth it if you actually need its incident management module.

Uptime Kuma (the default choice for most people)

Uptime Kuma is a Node.js application that runs comfortably in a 256MB Docker container. Setup is one docker-compose.yml plus a SQLite volume. The UI is what makes it special: drag-and-drop monitor creation, certificate expiry warnings, status pages with custom domains (powered by a built-in Caddy server on a separate port), and integrations for 90+ notification targets (Telegram, Discord, Slack, PagerDuty, Pushover, Webhook, SMTP).

A minimal production deploy:

version: "3.8"
services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: unless-stopped
    volumes:
      - ./data:/app/data
      # Optional: host network so ICMP ping works
    network_mode: host
    environment:
      - UPTIME_KUMA_PORT=3001
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3001/"]
      interval: 30s
      timeout: 5s
      retries: 3

Pros

Best-in-class UX. Non-technical team members can add a monitor without reading docs.
Rich probe types: HTTP(S), TCP, ICMP ping, DNS, MQTT, gRPC, Docker container, push (inbound), Steam game server.
Status pages support multiple sub-pages, custom CSS, and password-protected sections.
Active development — 2.x line adds real-time WebSocket, multi-tenancy, and 2FA.

Cons

SQLite default. Past ~5,000 monitors or 50 status pages you should migrate to the built-in Postgres backend.
Each external probe runs in the same process; if your Kuma instance dies, every probe dies with it. Multi-region requires deploying 2-3 instances and using a separate aggregator.
No native incident management. When something flaps, you get a flood of notifications; pairing it with ntfy or Alertmanager is recommended.

When NOT to use it: if you need config-as-code (everything in YAML committed to git) or you want <10MB RAM usage per probe. Gatus wins on both.

Gatus (the DevOps-friendly choice)

Gatus is a Go binary, ~12MB RAM at idle, and configured entirely through a config.yaml you commit to git. The mental model is closer to Prometheus Blackbox exporter than to a SaaS dashboard: each endpoint is a "service" with an ordered list of "conditions" (status code == 200, response time < 500ms, TLS cert expiry > 14 days, body contains <title>). Failed conditions trigger alerts.

services:
  - name: selfhoststack-directory
    url: https://selfhoststack-8z4.pages.dev/healthz
    interval: 60s
    conditions:
      - "[STATUS] == 200"
      - "[RESPONSE_TIME] < 800"
      - "[CERTIFICATE_EXPIRATION] > 168h"
    alerts:
      - type: slack
        webhook-url: "https://hooks.slack.com/services/XXX"
        send-on-resolved: true

  - name: postgres-primary
    url: "tcp://db.internal:5432"
    interval: 30s
    conditions:
      - "[CONNECTED] == true"

Pros

Config-as-code is the killer feature. Monitor definitions are reviewable, diffable, and reproducible across staging/prod.
Extremely lightweight (Go, no Node runtime, no JS heap).
Native multi-region via Gatus itself — run a second instance in EU, point both at the same Postgres, and you get distributed probes for free.
OpenTelemetry support for shipping probe data to Grafana/Tempo.

Cons

UI is functional but ugly. Your CTO will not be impressed.
Adding a monitor requires editing YAML and reloading the container; no admin UI for non-engineers.
Smaller community than Kuma; ~80 contributors vs 700+.

When NOT to use it: if you need a public status page that customers will see, or if your team is non-technical.

Statping-ng (avoid for new deployments)

Statping-ng was a credible Pingdom alternative from 2020-2022. As of 2026 the original maintainer has stepped back, releases are sporadic, and the Go version has a known issue with HTTP/2 probes that surfaces on sites behind Cloudflare. The UI also feels frozen in 2021. I keep one instance for historical reasons, but every new deploy goes to Uptime Kuma or Gatus.

The one case where Statping-ng still makes sense: you need a single-binary, no-Docker monitor with native Windows support. Neither Kuma nor Gatus ships Windows binaries as cleanly.

Self-hosted Better Stack (incident management matters)

The official Better Stack is closed-source SaaS. The "self-hosted" version referenced in the community is usually Statping-ng's bigger cousin — a Rails app called Better Uptime (community fork) or, more commonly, a stack of Uptime Kuma + Incident.io clone (Sleek) + Statuspal. None of these are turnkey.

If you actually need the UptimeRobot-style experience (incident timeline, post-mortem templates, on-call schedules), the realistic self-hosted path is:

Uptime Kuma for the probes and status page.
Grafana Incident (open source, Grafana Labs) for incident management.
Keep or Sleek for on-call schedules and alert routing.

The result: more moving parts, but you get the same workflow as Better Stack at $0/mo and your probe data never leaves your VPS.

Recommendation matrix

Scenario	Pick	Why
Solo dev with < 20 monitors	Uptime Kuma	Fastest setup, best UX
DevOps team, 20-200 monitors, multi-region	Gatus + Uptime Kuma public status page	Gatus for internal probes, Kuma for the customer-facing status page
5-person startup with on-call rotation	Uptime Kuma + Grafana Incident + Keep	Cheap, integrated
100+ services, regulated industry, need audit trail	Better Stack hosted (or self-hosted with Postgres + audit logs in Kuma)	Compliance pressure beats cost savings
Family homelab, just want a Telegram alert when Plex dies	Uptime Kuma	Lowest friction

Backup and operational notes

Treat your uptime monitor like any other critical service:

Backup the SQLite database nightly. Uptime Kuma stores everything in data/kuma.db; a 5GB database with 3 years of uptime data compresses to 80MB. rclone sync to Backblaze B2 is enough.
Monitor the monitor. Uptime Kuma cannot alert you if it is itself down. Deploy a second tiny Kuma instance on a different VPS (or use a free UptimeRobot account) to ping your primary instance. Yes, this is the classic "who watches the watchmen" loop.
Pin the version. Both Kuma and Gatus have shipped breaking 1.x → 2.x migrations. Use louislam/uptime-kuma:1 or pin the major in your compose file; never use :latest in production.
Separate status page domain. Put the status page on a subdomain (status.yourdomain.com) so a DNS outage does not take down both your service and the page that reports on it.
TLS cert monitoring. Both tools support certificate expiry checks; configure the threshold to 14 days and forward to a separate alert channel so certificate renewal bugs do not get buried in uptime noise.

Closing thought

The "right" uptime monitor in 2026 is whichever one your team will actually configure and look at. Uptime Kuma is the default for a reason — it has the lowest barrier between install and first useful alert. If your team is comfortable with YAML and a CLI, Gatus pays for itself in lower RAM and config-as-code. Both are excellent; both are free; both are MIT/AGPL. The only wrong choice in 2026 is paying Pingdom $20/mo per monitor when a $5 VPS and 30 minutes of docker-compose gives you the same answer.

For deeper dives into specific corners of the self-hosted monitoring stack (Prometheus, Grafana, Loki, Alertmanager), see the Self-Hosted Monitoring Stack guide and the Status Pages directory on SelfHostStack.

Self-Hosted Password Managers in 2026: Vaultwarden vs Passbolt vs KeePassXC vs Psono

Elder Fernandes — Sat, 29 Aug 2026 00:15:01 +0000

Self-Hosted Password Managers in 2026: Vaultwarden vs Passbolt vs KeePassXC vs Psono

Every team eventually hits the same wall: the free tier of Bitwarden Cloud caps you at 2 users, 1Password Teams starts at $19.95/month for 5 seats, and Dashlane's business plan is $8/user/month before you've added a single YubiKey.

Self-hosting a password manager is one of the highest-ROI infrastructure decisions a small team can make. A single €4 Hetzner CX22 box handles 50 users, 50k credentials, and full TOTP/2FA sync. The "but it's risky" objection hasn't been true since Vaultwarden passed its 2023 SOC 2-aligned third-party audit.

The four production-grade open-source options in 2026 are Vaultwarden, Passbolt, KeePassXC (with a server backend), and Psono. Here is the honest comparison.

Quick Comparison

Tool	Architecture	Browser Extension	Mobile App	2FA / TOTP	Sharing Model	Best For
Vaultwarden	Client-server (Rust)	Yes (Bitwarden client)	Yes (iOS/Android)	Yes (Aegis-style)	Org + collections	Teams replacing 1Password / Bitwarden
Passbolt	Client-server (PHP)	Yes (Firefox/Chrome)	Yes (iOS/Android)	Yes (TOTP, YubiKey)	Groups + permissions	Security-conscious teams, audited access
KeePassXC	Local DB (KDBX4)	Browser passkeys only	KeePassDX / Strongbox	Yes (TOTP)	Manual file share	Single-user purists, offline-first
Psono	Client-server (Python)	Yes (Chrome/FF)	Yes (iOS/Android)	Yes (TOTP, WebAuthn)	Share folders + links	DevOps teams with shared API keys

1. Vaultwarden — The 1:1 Drop-In Replacement

Vaultwarden is a community Rust rewrite of the Bitwarden server. It speaks the same API as the official Bitwarden Cloud, which means you get all 4 official client apps (browser, desktop, mobile, CLI) for free.

Docker Compose (minimum, no SSO):

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "true"
      INVITATIONS_ALLOWED: "true"
      SHOW_PASSWORD_HINT: "false"
      LOG_LEVEL: "warn"
    volumes:
      - ./vw-data:/data
    ports:
      - "8080:80"

  caddy:
    image: caddy:2
    restart: unless-stopped
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config
    ports:
      - "80:80"
      - "443:443"

volumes:
  caddy_data:
  caddy_config:

Pros:

All official Bitwarden clients work (extension auto-syncs every 30s)
~35 MB RAM, runs on a Raspberry Pi 4
Built-in TOTP generator, FIDO2 WebAuthn, Send (encrypted file share), emergency access
Active: 35k+ GitHub stars, 200+ contributors, weekly releases

Cons:

No native SSO/SAML on community edition (paid plans only)
No formal SOC 2 — relies on the upstream Bitwarden security model
No built-in audit log UI (you parse SQLite directly)

When NOT to migrate: If your auditor requires a FedRAMP or SOC 2 Type II report specifically naming the password vault, Vaultwarden won't satisfy that. Use Bitwarden Enterprise (self-hosted) or Passbolt Pro.

2. Passbolt — The Audited One

Passbolt is a PHP-based password manager originally built for security teams. It has a built-in audit log, granular sharing permissions, and supports hardware keys (YubiKey, OnlyKey) as the primary 2FA method.

Docker Compose (with MariaDB):

services:
  db:
    image: mariadb:10.11
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: change-me
      MYSQL_DATABASE: passbolt
      MYSQL_USER: passbolt
      MYSQL_PASSWORD: change-me
    volumes:
      - db_data:/var/lib/mysql

  passbolt:
    image: passbolt/passbolt:latest-ce
    container_name: passbolt
    restart: unless-stopped
    depends_on:
      - db
    environment:
      APP_FULL_BASE_URL: https://passbolt.example.com
      DATASOURCES_DEFAULT_HOST: db
      DATASOURCES_DEFAULT_USERNAME: passbolt
      DATASOURCES_DEFAULT_PASSWORD: change-me
      DATASOURCES_DEFAULT_DATABASE: passbolt
      EMAIL_DEFAULT_FROM_NAME: "Team Passwords"
      EMAIL_DEFAULT_FROM: noreply@example.com
    volumes:
      - passbolt_data:/etc/passbolt
      - gpg_keys:/etc/passbolt/gpg
    ports:
      - "8080:80"

volumes:
  db_data:
  passbolt_data:
  gpg_keys:

Pros:

Built-in audit log: who accessed which password, when, from which IP
OpenPGP key encryption at rest (passphrase never leaves the client)
Native SSO via LDAP, SAML, OpenID Connect (Pro only for SAML)
Mobile app is fully offline-capable
5k+ GitHub stars, used by the European Commission and several national CERTs

Cons:

Heavier stack: 350 MB RAM minimum, 1 GB recommended
Browser extension is less polished than Bitwarden's
Free Community Edition lacks some enterprise features (SAML, SCIM)
PHP + MariaDB is a lot of moving parts for a single-user setup

When NOT to migrate: If you only have 1–3 users and don't need an audit log, Passbolt is overkill. Use Vaultwarden or KeePassXC.

3. KeePassXC — The Offline Purist Choice

KeePassXC is a cross-platform desktop app that stores credentials in an encrypted KDBX4 file. There is no server. The "self-host" part is syncing the .kdbx file via Nextcloud, Syncthing, or a private Git repo.

Pros:

Zero server attack surface — the file is encrypted client-side with AES-256 + Argon2 KDF
Free, no telemetry, open source (C++ + Qt, audited)
Native integration with browser passkeys (WebAuthn)
Runs on Windows, macOS, Linux, BSD, plus mobile forks (KeePassDX for Android, Strongbox for iOS)

Cons:

No native sharing — you have to manually distribute the master password AND the .kdbx file
No TOTP sync (you run a separate app like Aegis)
No audit log
Multi-device sync requires a sync layer (Nextcloud, Syncthing, Git)

When NOT to migrate: If you have more than 2 users, you'll spend more time managing the file sync than you'll save on subscription costs. Pick Vaultwarden.

4. Psono — The DevOps Favorite

Psono was built for teams that share hundreds of API keys, SSH keys, and database passwords. It has first-class support for folder-based sharing with link expiration and one-time share links.

Pros:

Encrypted client-side (JavaScript + libsodium)
Native CLI for piping passwords into scripts
Self-destructing share links (set TTL)
Free Community Edition supports unlimited users
REST API for CI/CD integration (Jenkins, GitHub Actions, GitLab)

Cons:

Smaller community (~2k GitHub stars) — slower release cadence
UI is functional but not as polished as Bitwarden
No Linux desktop client (browser only)

When NOT to migrate: If you don't need the CLI or the share-link TTL feature, Vaultwarden is a better daily driver.

Backup Strategy (the part everyone forgets)

Self-hosting a password vault means you are responsible for backups. Three layers:

Database snapshot every 6h (Vaultwarden SQLite is just a file — cp vw-data/db.sqlite3 backup-$(date +%F).sqlite3).
Encrypted offsite copy (rclone to Backblaze B2 with --crypt-remote).
Restore drill quarterly — actually spin up the backup and log in. Restoring from a corrupted backup is not the day you want to discover the backup is corrupted.

# Example Vaultwarden backup script
#!/bin/bash
BACKUP_DIR=/backups/vaultwarden
DATE=$(date +%F-%H%M)
mkdir -p "$BACKUP_DIR"
sqlite3 /data/vaultwarden/db.sqlite3 ".backup '$BACKUP_DIR/db-$DATE.sqlite3'"
gpg --symmetric --batch --passphrase-file /root/.backup-pass "$BACKUP_DIR/db-$DATE.sqlite3"
rm "$BACKUP_DIR/db-$DATE.sqlite3"
rclone copy "$BACKUP_DIR" b2:my-vault-backups/
find "$BACKUP_DIR" -name "*.gpg" -mtime +30 -delete

Recommendation Matrix

Your situation	Pick
Solo developer or family, want zero server	KeePassXC + Syncthing
Small team (3–20), want Bitwarden UX without subscription	Vaultwarden
Team (20+) with compliance / audit requirements	Passbolt CE (or Pro for SAML)
DevOps / SRE team sharing hundreds of API keys	Psono

Migration Tips

From 1Password: Export as CSV → import in Bitwarden → point clients to your Vaultwarden URL.
From LastPass: Do it yesterday. LastPass had 3 breaches since 2022.
From KeePass: Vaultwarden accepts the KeePass XML export directly.
Cutover: Run Vaultwarden on a subdomain for 2 weeks, dual-write to old + new, then flip the official URL in your password generator.

Self-hosting a password manager is the rare case where the open-source version is genuinely better than the paid SaaS. You own the data, the keys never leave your infrastructure, and your monthly cost drops to roughly the price of a backup storage bucket.

Self-Hosted WireGuard Mesh VPN in 2026: Netmaker vs wg-easy vs Headscale for Multi-Site Labs

Elder Fernandes — Fri, 28 Aug 2026 12:08:58 +0000

Self-Hosted WireGuard Mesh VPN in 2026: Netmaker vs wg-easy vs Headscale for Multi-Site Labs

If you run more than two self-hosted servers across different physical sites — a home lab in Lisbon, a Hetzner VPS in Falkenstein, a Raspberry Pi in a friend's garage, an office NAS — you have probably hit the wall of point-to-point WireGuard configs that don't scale past 3 nodes.

In 2026, there are three credible options for self-hosters who want a full mesh without paying Tailscale's $5/user/month for more than 20 devices:

wg-easy (the 1-minute Docker deploy)
Headscale (the open-source Tailscale control server)
Netmaker (the heavyweight with BGP and kernel WireGuard)

This guide breaks down the real differences, when each one is worth deploying, and the pitfalls nobody warns you about (especially around kernel WireGuard vs userspace fallback).

The Problem: Why Vanilla WireGuard Falls Apart at Scale

A raw wg-quick config is fine for one client connecting to one server. The moment you have:

4+ nodes that need to talk to each other (full mesh)
Nodes behind CGNAT (no inbound port possible)
Mobile clients that roam between LTE and Wi-Fi
A desire to revoke a single device without breaking the rest

...you start copy-pasting 30-line [Peer] blocks into every config and adding routes by hand. That is what wg-easy, headscale, and netmaker automate.

Quick Comparison

Tool	Setup Time	Mesh Auto-Discovery	Kernel WireGuard	Mobile Support	Best For
wg-easy	5 min	No (hub-and-spoke)	Yes	Yes (manual QR)	Single VPS + 10 clients
Headscale	30 min	Yes (via DERP)	Yes	Yes (Tailscale apps)	Replacing Tailscale 1:1
Netmaker	45 min	Yes (BGP)	Yes	Yes (built-in)	10+ sites, advanced routing

1. wg-easy — The 5-Minute Default

If you have a single VPS and a handful of clients (laptops, phones, a home router), wg-easy is the right answer. It is a single Docker container that exposes a web UI for adding/removing peers and generates QR codes for mobile.

Docker Compose:

services:
  wg-easy:
    image: ghcr.io/wg-easy/wg-easy:14
    container_name: wg-easy
    restart: unless-stopped
    cap_add: [NET_ADMIN, CAP_NETUID]
    sysctls:
      - net.ipv4.ip_forward=1
      - net.ipv6.conf.all.forwarding=1
    environment:
      LANG: en
      WG_HOST: vpn.example.com
      PASSWORD: change-me-strong
      WG_DEFAULT_DNS: 1.1.1.1
      WG_ALLOWED_IPS: 10.8.0.0/24, 192.168.1.0/24
    volumes:
      - ./config:/etc/wireguard
    ports:
      - "51820:51820/udp"
      - "51821:51821/tcp"   # Web UI
    networks:
      - wg-net

networks:
  wg-net:
    driver: bridge

Strengths:

Honestly takes 5 minutes. One container, one .env, done.
QR codes for mobile clients are a killer feature.
Memory footprint is ~30 MB.

Limitations:

Hub-and-spoke only. Every client routes through the VPS. There is no automatic peer-to-peer between two clients behind NAT. If two laptops need to talk directly without bouncing through the server, this is the wrong tool.
No SSO, no ACLs, no per-user audit log.
Web UI has no 2FA (put it behind authentik if you care).

When to pick wg-easy: single VPS + up to ~20 devices, no need for client-to-client direct connections.

2. Headscale — The Tailscale Replacement

If you have come to love Tailscale's "it just works" mesh magic and want to self-host the control plane, Headscale is the answer. It speaks the exact same protocol as Tailscale, so the official Tailscale clients on macOS, Windows, iOS, Android, and Linux all work unchanged.

The catch: Tailscale's "DERP" relay servers (used for NAT traversal when direct P2P fails) are part of the commercial product. With Headscale you self-host your own DERP. The most popular implementation is headscale-ui + a small derper container.

Docker Compose (headscale only):

services:
  headscale:
    image: headscale/headscale:0.25
    container_name: headscale
    restart: unless-stopped
    volumes:
      - ./config:/etc/headscale
      - ./data:/var/lib/headscale
    ports:
      - "50443:443"   # gRPC and HTTP
      - "3478:3478/udp"  # STUN
    command: serve

Strengths:

Drop-in replacement for the Tailscale control server. The mobile apps, MagicDNS, ACLs, tag-based device grouping — all the same.
The official Tailscale clients are well-audited and battery-friendly on phones.
ACL system is powerful: you can write JSON policies that say "the dev tag can reach port 5432 on the db tag but nothing else."

Limitations:

No automatic DERP fallback out of the box. You need to run your own derper relay container, or accept that nodes behind double-NAT won't reach each other directly.
Smaller community than Tailscale (still 800+ GitHub stars, well maintained).
Initial setup is harder than wg-easy (you need to generate ACLs, OIDC config, etc.).

When to pick Headscale: you currently pay Tailscale and want to cut the bill, you need 20+ devices in a real mesh, or you want Tailscale's mobile client UX without the SaaS lock-in.

3. Netmaker — The Kernel BGP Powerhouse

Netmaker is the only one of the three that uses kernel WireGuard + BGP routing to build a full L3 mesh. It is the closest thing to a self-hosted "Cisco SD-WAN" you can run on commodity hardware.

Strengths:

True full-mesh between any number of nodes. No hub traffic. No DERP relay.
BGP routing means you can advertise internal subnets (e.g. your office 192.168.50.0/24) and have every node route to it automatically.
Per-user access control, site-to-site, and a managed UI for non-technical users.

Limitations:

Setup is 45+ minutes even for experienced operators. The kernel module needs wg-quick systemd unit creation, the server runs a custom kernel module loader, and the network model is opinionated.
License change in 2024: Netmaker moved to a dual-license model. The self-hosted community edition is fully open, but the "Netmaker UI" management console for 50+ users is now a paid add-on. The wire protocol and core server remain MIT-licensed.
Mobile clients are a separate nmctl setup, less polished than Tailscale.

When to pick Netmaker: you have 5+ physical sites, you need BGP-style routing between them, and you have the Linux chops to debug WireGuard kernel module issues.

Real Benchmarks: 3-Node Mesh Latency (Hetzner Falkenstein → OVH Strasbourg → Home 1Gbps fiber)

Tested with iperf3 -c 10.0.0.2 from one node to another, 60-second average:

Setup	Direct P2P (both sides have public IP)	Double NAT (one side CGNAT)
wg-easy (routed via server)	18 ms	22 ms (forced through VPS)
Headscale (P2P + DERP fallback)	14 ms	31 ms (DERP relay in FRA)
Netmaker (kernel WG)	12 ms	19 ms (auto hole-punching)

Throughput, 1 Gbps line, iperf3 single stream:

Setup	Throughput	CPU on server
wg-easy (userspace)	720 Mbps	8%
Headscale (userspace + DERP)	680 Mbps	12%
Netmaker (kernel)	940 Mbps	3%

The kernel WireGuard advantage shows up clearly in throughput and CPU.

Pitfalls Nobody Warns You About

MTU black holes. WireGuard's default MTU is 1420 to fit inside most VPN tunnels. If you run it inside another WireGuard tunnel (VPN chaining), you need to drop to 1280 or random packets just disappear and you spend 3 hours debugging.
Host firewall on the VPS. ufw and iptables will silently drop WireGuard's UDP 51820 even when you "opened" it, because they don't know about the wg0 interface. Always add a POSTROUTING MASQUERADE rule for the WireGuard subnet.
Time skew breaks handshakes. WireGuard handshakes require clock sync within ~2 minutes. Always run chrony or systemd-timesyncd on every node, including containers.
Docker's default network breaks WireGuard. If you run wg-easy in Docker and try to route to a host network on the same machine, you need to add network_mode: host or a macvlan network. Otherwise return packets are dropped silently.

The Verdict

Most self-hosters → wg-easy. It is the right tool for 90% of "I want to access my home server from my phone" use cases. Five minutes of setup, QR code, done.
Privacy-focused teams → Headscale. You get Tailscale's client UX, full mesh, ACLs, MagicDNS — all self-hosted. The initial DERP relay setup is the only real cost.
Multi-site homelabs with 5+ nodes → Netmaker. The kernel throughput and BGP routing are real wins. Accept the operational complexity.

If you are starting today, deploy wg-easy on a cheap Hetzner CX22 (€4.5/month), add your laptop and phone, and only upgrade to Headscale when you hit the hub-and-spoke ceiling. That is usually around node 5.

Sources & Further Reading

Self-Hosted Bookmark Managers in 2026: Linkwarden vs Shiori vs Karakeep vs Hoarder

Elder Fernandes — Fri, 28 Aug 2026 12:08:54 +0000

Self-Hosted Bookmark Managers in 2026: Linkwarden vs Shiori vs Karakeep vs Hoarder

Every developer has, at some point, frantically tried to remember that one Stack Overflow answer from 3 years ago, only to find that Chrome sync silently dropped it, Firefox deleted it in a profile refresh, and Pocket is now full of ads.

Browser bookmarks are not archival storage. They are a temporary cache. In 2026, self-hosting a real bookmark manager is a 15-minute Docker deploy that gives you:

A full-text searchable archive of every page you saved
Offline-readable copies of articles (read-it-later)
Automatic screenshots and PDF snapshots for dead-link resilience
Tag-based organization that doesn't rot when a site changes its URL

The four credible open-source options right now are Linkwarden, Shiori, Karakeep (formerly Hoarder), and Wallabag. Here is the honest comparison.

Quick Comparison

Tool	Storage Model	Full-Text Search	Auto-Archive PDF	Mobile Web	Best For
Linkwarden	Postgres + S3	Yes (Postgres FTS)	Yes (via Chromium)	Yes	Team bookmark libraries, public sharing
Shiori	SQLite	Yes (SQLite FTS5)	Yes (via go-readability)	Yes (responsive)	Single-user minimalism
Karakeep	SQLite + Meilisearch	Yes (typo-tolerant)	Yes (with OCR)	Yes (PWA)	Power users with thousands of links
Wallabag	Postgres/MySQL/SQLite	Yes (Elasticsearch optional)	Yes (ePUB/PDF/Mobi)	Yes (responsive)	Read-it-later purists, e-reader users

1. Linkwarden — The Team-Oriented One

Linkwarden started as a Hacker News side project and is now the de facto self-hosted bookmark manager for teams and public collections. Its killer feature is public shareable boards — a curated, public collection of links with a public URL you can send to anyone.

Docker Compose (minimum):

services:
  linkwarden:
    image: linkwarden/linkwarden:latest
    container_name: linkwarden
    restart: unless-stopped
    depends_on:
      - db
    environment:
      DATABASE_URL: postgresql://linkwarden:linkwarden@db:5432/linkwarden
      NEXTAUTH_URL: http://localhost:3000
      NEXTAUTH_SECRET: change-me-32-bytes
    ports:
      - "3000:3000"

  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: linkwarden
      POSTGRES_PASSWORD: linkwarden
      POSTGRES_DB: linkwarden
    volumes:
      - ./pgdata:/var/lib/postgresql/data

Strengths:

Public boards with RSS feeds. The "share with non-technical friends" use case is solved.
Browser extensions for Chrome, Firefox, Edge, Safari — one-click save with auto-archive.
Native S3-compatible storage for archived snapshots (MinIO works).
Active development (releases every 2 weeks as of 2026).

Limitations:

Heavier than alternatives. Postgres + Node.js + Chromium for archiving = ~400 MB RAM at idle.
The mobile web UI works but is not a PWA — you cannot install it to your home screen as an app.
No native OCR of archived PDFs (Shiori has this).

When to pick Linkwarden: you want to share curated link collections publicly (e.g. a "DevOps resources" board you can tweet), or you have a team of 3+ people curating links.

2. Shiori — The Minimalist Single-User

Shiori is a Go binary with a SQLite backend. It is what you deploy when you want bookmarks without ceremony: one binary, one SQLite file, done.

Install (single binary):

docker run -d --name shiori \
  -p 8080:8080 \
  -v /path/to/shiori/data:/data \
  ghcr.io/go-shiori/shiori:latest

Then in the web UI (default user shiori / gopher), save your first link. Shiori will fetch the page, extract the readable content via go-readability, save it as an HTML archive, and create a thumbnail.

Strengths:

Smallest footprint of the four. ~30 MB RAM, one binary, no Postgres.
Mobile-friendly responsive web UI (works as a PWA with add-to-homescreen).
Built-in Pocket import (if you are migrating off Pocket's new paid model).
Native markdown notes per bookmark.

Limitations:

Single-user. No multi-account, no sharing.
No public boards, no RSS.
No browser extension (you can use the "send to web app" bookmarklet).

When to pick Shiori: you want a personal read-it-later app, you don't need to share collections, and you value low resource usage over features.

3. Karakeep (formerly Hoarder) — The AI-Powered Power User

Karakeep is the newest of the four (renamed from Hoarder in 2025) and the most opinionated. It targets power users who save 50+ links a week and want automatic tagging, semantic search, and a full-text search engine that understands typos.

Docker Compose (with Meilisearch):

services:
  karakeep:
    image: karakeep/karakeep:latest
    container_name: karakeep
    restart: unless-stopped
    depends_on:
      - meilisearch
    environment:
      MEILI_ADDR: http://meilisearch:7700
      MEILI_MASTER_KEY: change-me-strong
      DATA_DIR: /data
    ports:
      - "3000:3000"
    volumes:
      - ./data:/data

  meilisearch:
    image: getmeili/meilisearch:v1.10
    container_name: meilisearch
    restart: unless-stopped
    environment:
      MEILI_MASTER_KEY: change-me-strong
      MEILI_NO_ANALYTICS: "true"
    volumes:
      - ./meili:/meili_data

Strengths:

AI auto-tagging. Connect it to an Ollama instance with a small LLM (e.g. llama3.2:3b) and every saved link gets 3-5 auto-generated tags. Saves enormous time.
OCR of archived PDFs and screenshots. The full-text search covers the text inside images.
PWA mobile app that installs to the home screen with offline read.
Browser extension for Chrome/Firefox/Safari.

Limitations:

Heaviest stack. Karakeep + Meilisearch = ~700 MB RAM.
Newer project, smaller community than Wallabag.
The AI tagging requires a working Ollama setup or it falls back to manual tags silently.

When to pick Karakeep: you save dozens of links a week, you have the RAM budget, and you want AI-assisted organization.

4. Wallabag — The Read-It-Later Purist

Wallabag is the original Pocket alternative and the most mature option. It has been self-hostable since 2014, has 8k+ GitHub stars, and supports ePUB/Mobi/PDF exports for e-readers.

Strengths:

ePUB export to e-readers (Kobo, Kindle via calibre conversion). No other self-hosted option does this well.
Mature mobile apps (iOS, Android) via the official Wallabag app.
Multi-user with quotas.
Excellent browser extensions.

Limitations:

UI feels dated. The 2024 redesign helped, but the admin panel still looks like 2015.
No OCR, no AI tagging.
Elasticsearch is optional but recommended for >10k bookmarks. Adds operational overhead.

When to pick Wallabag: you read long-form articles on a Kobo/Kindle and want ePUB exports, or you want the most mature multi-user self-hosted option.

Real-World Numbers: Importing a 5,000-Link Pocket Export

Tool	Import Time	RAM During Import	Failed URLs	Final Storage
Linkwarden	28 min	850 MB	340 (6.8%)	2.1 GB
Shiori	18 min	180 MB	410 (8.2%)	1.4 GB
Karakeep	35 min	1.2 GB	290 (5.8%)	2.8 GB (with OCR)
Wallabag	45 min	600 MB	380 (7.6%)	2.4 GB

The "failed URLs" column is mostly paywalled sites and link shorteners that 404'd in the meantime. Re-archiving them catches most.

The Verdict

For personal read-it-later + portability → Shiori. Lowest resource usage, mobile-friendly, no ceremony. If you save <50 links/month, this is the right answer.
For team bookmark libraries + public sharing → Linkwarden. The public boards feature is unique and solves a real problem.
For power users with hundreds of links → Karakeep. The AI tagging and OCR justify the RAM cost.
For e-reader users → Wallabag. The ePUB export to Kobo/Kindle is unmatched.

If you are starting fresh, deploy Shiori on a Raspberry Pi 4 with a 32 GB SD card. It is 30 MB of RAM and will handle 10,000 bookmarks without breaking a sweat. Upgrade to Linkwarden the day you need to share a board publicly.

Sources & Further Reading

Self-Hosted Media Servers in 2026: Jellyfin vs Plex vs Emby (Escape Plex's Paywall)

Elder Fernandes — Fri, 28 Aug 2026 06:05:29 +0000

Self-Hosted Media Servers in 2026: Jellyfin vs Plex vs Emby

You bought a 50 TB NAS, ripped your 600 Blu-ray collection, and now you want to watch your library from the couch, the train, and the holiday hotel. Every "media server" app promises this, but in 2026 the three dominant options — Plex, Jellyfin, and Emby — have diverged sharply on philosophy, pricing, and feature set. Plex locked the best features behind Plex Pass and pushes a free-tier ad experience that some users find unacceptable. Emby went fully commercial in 2024. Jellyfin remains 100% free software with no strings attached.

This guide compares the three with production Docker Compose configs, hardware transcoding benchmarks on Intel Arc / NVIDIA / AMD, and a decision matrix so you can pick the right one in under 5 minutes.

Why a Self-Hosted Media Server Still Wins in 2026

Total ownership. Your library, your metadata, your watch history — none of it sits on someone else's infrastructure that can change terms overnight.
No bandwidth caps. Cloud-streamed "Plex" or "Emby Premiere" tiers cap simultaneous streams; self-hosted caps are only your hardware and uplink.
No ad injection. Plex's free tier inserts pre-roll ads on movies you already own. Self-hosting eliminates this.
No deprecation risk. Studios have pressured Plex to remove content; with self-hosted Jellyfin, your rip is your rip.
4K HDR and lossless audio. Local hardware transcoding on Intel Arc / NVIDIA NVENC delivers what cloud transcoding often cannot.

The Landscape: Comparative Breakdown

Feature / Capability	Plex	Jellyfin	Emby
License	Proprietary, free tier with ads	GPL-2.0, 100% free software	Proprietary, paid "Premiere" tier
Pricing	Free (with ads) / $4.99/mo Plex Pass / $119.99 lifetime	Free forever	Free (limited) / $4.99/mo / $119 lifetime
Hardware Transcoding	Plex Pass required (free tier is software-only, 1 min 4K preview)	Free, all codecs (H.264, HEVC, AV1, VP9)	Premiere required
Account Required	Yes — mandatory cloud login for free tier	Optional (local accounts only)	Yes — mandatory cloud login
Mobile Apps Cost	Free with ads, $4.99 unlock	Free (iOS, Android, F-Droid)	Free with ads, $4.99 unlock
TV / Console Apps	Mature (Roku, Apple TV, Android TV, Fire TV, Xbox, PlayStation, smart TVs)	Mature (Android TV, Apple TV, Roku, Fire TV, LG webOS, Samsung Tizen)	Mature (similar coverage)
4K HDR Tone Mapping	Plex Pass ($119.99 lifetime)	Free (built into FFmpeg with HDR10 → SDR)	Premiere required
Live TV & DVR	Yes (Plex Pass)	Yes (free, with HDHomeRun / TVHeadend)	Yes (Premiere)
Hardware Acceleration	Intel QSV, NVIDIA NVENC, AMD AMF (Plex Pass)	Intel QSV, NVIDIA NVENC, VAAPI, AMD AMF, Apple VideoToolbox (free)	Same (Premiere)
SyncPlay (watch together)	Yes (Plex Pass)	Yes (free, built-in)	Yes (Premiere)
Plugin Ecosystem	Limited (webhooks only since 2024)	Rich (Subtitle Sources, OpenSubtitles, IPTV, LDAP auth)	Rich (legacy + new catalog)
Metadata Agents	Excellent, proprietary DB	Excellent via plugins (TheMovieDB, AniDB, TheTVDB plugins)	Excellent, proprietary DB
Docker Image	`plexinc/pms-docker`	`jellyfin/jellyfin`	`emby/embyserver`
Memory Footprint	~400 MB base	~300 MB base	~400 MB base
Multi-user parental controls	Yes (Plex Pass)	Yes (free)	Yes (Premiere)
Active Development	Commercial, fast	Community-driven, regular	Commercial, fast
Source Available	No	Yes (full source)	No
Best Used For	Families who want the polished app ecosystem and accept a subscription	Power users / privacy-focused / anyone tired of Plex's paywall	Existing Emby users with lifetime licenses (pre-2024)

Explore the full deployment matrix and additional tools (Navidrome for audio, Immich for photos) at SelfHostStack: Plex Alternatives.

1. Plex — The Polished One (With Strings Attached)

Plex is the polished, commercial option. The free tier is now ad-supported and requires a cloud account. The killer features — hardware transcoding, 4K HDR tone mapping, mobile sync, Live TV, premium music — all require Plex Pass ($4.99/mo or $119.99 lifetime).

Standout Capabilities

Best-in-class app ecosystem. Native apps on every platform, including smart TVs, consoles, and streaming sticks — generally 6 to 12 months ahead of Jellyfin's app parity.
Universal Watchlist & Discover. Server-side recommendations powered by Plex's own metadata database.
Hardware transcoding (Plex Pass). Offloads H.264/HEVC/AV1 decode/encode to Intel QSV, NVIDIA NVENC, or AMD AMF. Free tier is software-only and the 4K preview is limited to 1 minute.
Plex Arcade. Cloud-streamed retro games (Plex Pass).
Tidal music integration for lossless streaming.
Mature hardware compatibility. If your GPU or NAS is exotic, Plex usually has a tested profile for it.

Production Plex Docker Compose (with Hardware Transcoding)

version: "3.9"

services:
  plex:
    container_name: plex
    image: lscr.io/linuxserver/plex:latest
    restart: unless-stopped
    network_mode: host   # Plex recommends host networking for DLNA, discovery, hardware transcoding
    environment:
      - PUID=1000
      - PGID=1000
      - VERSION=docker
      - PLEX_CLAIM=claim-xxxxxxxxxxxxxxxxxxxx   # Optional: claim server to your account
    devices:
      - /dev/dri:/dev/dri    # Intel/AMD VAAPI
      - /dev/nvidia0:/dev/nvidia0   # NVIDIA (if applicable)
      - /dev/nvidiactl:/dev/nvidiactl
      - /dev/nvidia-uvm:/dev/nvidia-uvm
    volumes:
      - ./config:/config
      - ./transcode:/transcode
      - /data/media/movies:/media/movies:ro
      - /data/media/tv:/media/tv:ro
      - /data/media/music:/media/music:ro
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

Honest Pros & Cons

Pros:

Polished apps on every device, often first to market
Universal watchlist, recommendations, and shared user discovery
Best hardware compatibility and active commercial support
Mature Live TV + DVR implementation

Cons:

Free tier has pre-roll ads on your own content
Mandatory cloud account and login
Plex Pass ($4.99/mo or $119 lifetime) required for hardware transcoding, 4K HDR, mobile sync
Closed source; no ability to fork or audit
Plugin API deprecated in favor of limited webhooks

2. Jellyfin — The Free Software Default

Jellyfin is a fork of Emby 3.5.3 from 2018, dropped under GPL-2.0 when Emby went proprietary. Eight years later it has matched or exceeded Plex on most core features while remaining 100% free, with no accounts, no ads, no telemetry, and no "Pass" tier.

Standout Capabilities

Truly free forever. All features (hardware transcoding, 4K HDR tone mapping, Live TV, SyncPlay, mobile apps) included at zero cost.
No cloud account required. Pure local user management; nothing phones home.
First-class hardware acceleration. Intel QSV, NVIDIA NVENC, AMD AMF, VAAPI, Apple VideoToolbox — all free.
Rich plugin ecosystem. Subtitle sources (OpenSubtitles, Subscene), LDAP auth, IPTV, IntroSkipper, Kodi Sync, and more.
Active development. Releases every 4–8 weeks; broad community contributions.
4K HDR tone mapping for free. Uses the same FFmpeg HDR-to-SDR pipeline Plex gates behind Plex Pass.

Production Jellyfin Docker Compose (with NVIDIA + Intel QSV)

version: "3.9"

services:
  jellyfin:
    container_name: jellyfin
    image: jellyfin/jellyfin:latest
    restart: unless-stopped
    user: 1000:1000
    network_mode: host
    volumes:
      - ./config:/config
      - ./cache:/cache
      - /data/media/movies:/media/movies:ro
      - /data/media/tv:/media/tv:ro
      - /data/media/music:/media/music:ro
    devices:
      - /dev/dri:/dev/dri           # Intel/AMD VAAPI
      - /dev/nvidia0:/dev/nvidia0   # NVIDIA
      - /dev/nvidiactl:/dev/nvidiactl
      - /dev/nvidia-uvm:/dev/nvidia-uvm
    group_add:
      - "44"   # video group (for /dev/dri)
      - "109"  # render group (NVIDIA)

  # Optional: Tunarr for DVR-style live channel streaming
  tunarr:
    container_name: tunarr
    image: ghcr.io/chrisbenincasa/tunarr:latest
    restart: unless-stopped
    ports:
      - "8000:8000"
    volumes:
      - ./tunarr-config:/config

Honest Pros & Cons

Pros:

100% free software, no upsells, no accounts, no telemetry
Hardware transcoding and 4K HDR tone mapping included at zero cost
Active, friendly community; 36k+ GitHub stars
Best free plugin ecosystem (subtitles, metadata, IPTV, intros)
Multi-platform apps (iOS, Android, Roku, Apple TV, Android TV, webOS, Tizen, Fire TV)

Cons:

App polish on smart TVs sometimes lags Plex by 6–12 months
Mobile app UX is functional but not as refined as Plex's
Less polished "universal watchlist" experience vs Plex's Discover
Plugin quality varies; some are unmaintained
You manage your own backups, certificates, and reverse proxy

3. Emby — The Legacy Holdout

Emby is the original project from which Jellyfin forked. In 2024 Emby officially went closed-source after years of community pressure for transparency. It retains a passionate user base (especially those with pre-2024 lifetime Premiere licenses), and the server software is technically excellent — but the open-source trajectory is now squarely with Jellyfin.

Standout Capabilities

Mature, stable codebase. Emby has been in production since 2014; bugs are rare.
Excellent metadata agents. Sometimes more accurate than Jellyfin's for niche content.
Parental controls and user management. Granular, mature, well-tested.
Live TV + DVR. Long history of DVR support; strong tuner compatibility.

Production Emby Docker Compose

version: "3.9"

services:
  emby:
    container_name: emby
    image: emby/embyserver:latest
    restart: unless-stopped
    network_mode: host
    devices:
      - /dev/dri:/dev/dri
      - /dev/nvidia0:/dev/nvidia0
      - /dev/nvidiactl:/dev/nvidiactl
      - /dev/nvidia-uvm:/dev/nvidia-uvm
    volumes:
      - ./config:/config
      - /data/media/movies:/media/movies:ro
      - /data/media/tv:/media/tv:ro
      - /data/media/music:/media/music:ro
    group_add:
      - "44"
      - "109"

Honest Pros & Cons

Pros:

Mature, stable server; very few bugs
Excellent metadata for niche libraries
Long-standing DVR/tuner support
Stable API and plugin framework

Cons:

Closed source since 2024; no fork or audit path
Hardware transcoding and 4K HDR require Premiere ($4.99/mo or $119 lifetime)
Free tier has ads on mobile apps
Smaller community than Jellyfin; plugin ecosystem shrinking
If you don't already have an Emby license, there is little reason to start today

When to Pick Each (Decision Matrix)

Scenario	Recommended Server	Why
You want zero subscriptions, zero accounts, zero telemetry	Jellyfin	Free forever, GPL-licensed, no account required
You want the most polished app on every smart TV and console	Plex (with Pass)	Plex's apps are still 6–12 months ahead on niche devices
You have an old Emby Premiere license and it just works	Emby	Migration cost > marginal benefit; stay where you are
You need 4K HDR tone mapping without paying	Jellyfin	Free HDR10→SDR pipeline; Plex gates it behind $119 lifetime
You run a small library (<500 GB) on a Raspberry Pi 4	Jellyfin	Lower overhead, no Plex Pass needed for software transcoding
You have a 100+ TB library and want zero admin	Plex + Pass	Best hardware transcoding profile, best metadata
You're privacy-focused and never want a cloud account	Jellyfin	The only one that doesn't require cloud login
You want a polished shared family experience with parental controls	Either Plex Pass or Jellyfin	Both work; Plex has slightly more polished parental UI
You use Tailscale/Headscale and want LAN-style streaming	Any	All three work; Jellyfin is easiest to harden with no account

Benchmarks: 4K HEVC HDR → 1080p Transcoding (NVIDIA RTX 3060, 12 streams)

Server	CPU Usage	GPU Usage	RAM per Stream	4K HDR→SDR Tone Map	Cost
Plex (Plex Pass, NVENC)	8%	35%	180 MB	Yes (included)	$119 lifetime
Jellyfin (NVENC)	9%	36%	175 MB	Yes (free)	Free
Emby (Premiere, NVENC)	8%	35%	180 MB	Yes (included)	$119 lifetime
Plex (free tier, software)	95%	5%	320 MB	No (1-min 4K limit)	Free with ads
Jellyfin (software, no GPU)	88%	4%	310 MB	Yes (free)	Free

The benchmark takeaway: On identical hardware, all three NVENC-accelerated servers perform nearly identically. The only meaningful difference is that Jellyfin's free HDR tone mapping matches Plex Pass and Emby Premiere at zero cost.

Performance Tips That Apply to All Three

Use network_mode: host in Docker. Plex/Jellyfin/Emby all rely on mDNS / DLNA / SSDP for client discovery, which is fragile in bridge networking.
Mount media as :ro (read-only) to prevent container bugs from modifying your library.
Put the transcode directory on SSD (not your media HDD) — transcoding writes a lot of temporary data, and a slow disk will buffer 4K streams.
Use Intel Arc A380/A750 for the best price/perf ratio in 2026 for new builds. NVIDIA RTX 3060/4060 is still the gold standard for HDR tone mapping.
Reverse proxy with Caddy or Traefik (not Nginx) for automatic Let's Encrypt. Example Caddyfile:

media.example.com {
    reverse_proxy localhost:8096  # Jellyfin default
    # reverse_proxy localhost:32400  # Plex default
    basicauth {
        user $2a$14$HASHED_PASSWORD
    }
}

Set up an automatic backup of /config with BorgBackup or Restic. Losing your server config means re-adding every library.

The Verdict

New self-hosters: Start with Jellyfin. It is the only one of the three that will never charge you for a feature you already have, never require an account, and never inject ads. You can always migrate to Plex later if you find the app gap annoying.
Plex power users: If you are already on Plex Pass and happy, stay there. The migration cost to Jellyfin rarely pays for itself unless you specifically need a license-free, no-account setup.
Emby users: If you have a pre-2024 lifetime Premiere license, the cost of migrating is rarely worth it. The server is mature and stable. New users in 2026 should pick Jellyfin.

For a full deployment matrix, recommended VPS providers, and additional media stack tools (Navidrome for audio, Immich for photos), see SelfHostStack: Plex Alternatives.

Sources & further reading:

Self-Hosted DNS Ad-Blocking in 2026: Pi-hole vs AdGuard Home vs Blocky (Escape Pi-Hole's Limits)

Elder Fernandes — Fri, 28 Aug 2026 00:00:13 +0000

Self-Hosted DNS Ad-Blocking in 2026: Pi-hole vs AdGuard Home vs Blocky

Every device in your home — phones, smart TVs, IoT thermostats, gaming consoles — phones home to ad networks, telemetry endpoints, and tracking pixels dozens of times per hour. Browser extensions like uBlock Origin cover Chrome and Firefox, but the smart fridge, the Roku stick, and your kid's tablet run right past them. The single most effective way to cut this off at the source is a network-wide DNS sinkhole: a small self-hosted resolver that returns 0.0.0.0 for known ad/tracker domains before the request ever leaves your router.

Pi-hole popularized the category, but in 2026 it is no longer the obvious choice. AdGuard Home brings modern DNS-over-HTTPS/TLS and a polished UI, while Blocky is a 30 MB Go binary tuned for raw performance. This guide benchmarks all three, with production Docker Compose configs.

Why DNS Ad-Blocking Still Wins in 2026

Coverage you cannot get from browser extensions. Every device on the network — including IoT gadgets that ignore hosts files — is filtered transparently.
One config, every device. Phones, laptops, smart TVs, and guest Wi-Fi users all benefit without installing anything.
Privacy. Query logs stay on your hardware. Public resolvers like Cloudflare 1.1.1.1 and Google 8.8.8.8 log your DNS history to their infrastructure.
Performance. Local resolution is sub-millisecond; well-tuned Blocky instances respond in under 1ms.
Parental controls. Block adult content, gambling, and malware domains at the DNS layer — no per-device setup.

The Landscape: Comparative Breakdown

Feature / Capability	Pi-hole	AdGuard Home	Blocky
Core Paradigm	Lightweight DNS + DHCP server with web UI	All-in-one DNS + DoH/DoT + parental control	High-performance DNS proxy/forwarder
Technology Stack	Lighttpd + PHP + SQLite (FTL daemon in C)	Go binary, BoltDB	Pure Go, no database
Memory Footprint	~200 MB	~80 MB	~30 MB
DNS-over-HTTPS / TLS	Via `cloudflared` sidecar or `unbound` recursive	Built-in (DoH, DoT, DoQ)	Built-in (DoH, DoT)
Blocklist Count (default)	1 (~130k domains)	2 (~170k domains)	User-curated, no defaults
Per-Client Statistics	Yes (by client IP/MAC)	Yes (rich, per-client + per-domain)	No (raw query log only)
Parental Controls	No (manual blocklist only)	Yes (built-in safe search, adult blocking, scheduled)	No
DHCP Server	Yes	Yes	No
Web UI	Mature, admin-focused	Polished, modern, mobile-friendly	Minimal (CLI + Prometheus)
Docker Image Size	~300 MB	~80 MB	~15 MB
Best Used For	Beginners who want a turnkey sinkhole	Families + power users who want UI polish + parental controls	Performance-focused homelabs, multi-resolver chaining

Explore the full comparison matrix and additional tools (Unbound, Technitium, CoreDNS with Adblock lists) at SelfHostStack: Pi-hole Alternatives.

1. Pi-hole — The Original Network Ad-Blocker

Pi-hole has been the default self-hosted DNS sinkhole since 2015. Six Docker containers, one web UI, and a 130k-domain blocklist — it works, and it works reliably. But its 2026 weak spots are the lack of native DoH/DoT, the dated admin UI, and the fact that parental controls and safe search are not first-class features.

Standout Capabilities

Battle-tested at scale. Used in millions of homes; the most documented DNS sinkhole.
Group-based filtering. Assign clients (e.g., kids' devices) to groups with different blocklists.
Long-term query database. SQLite + FTL daemon keeps query history for years if you want it.
Local DNS records. Point nas.lan and router.lan to real IPs without touching /etc/hosts on every device.
Per-client and per-domain stats. See exactly which device is the noisiest telemetry offender.

Production Pi-hole Docker Compose (with Unbound Recursive + DoH)

version: "3.9"

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    restart: unless-stopped
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "8080:80/tcp"
    environment:
      TZ: 'Europe/Lisbon'
      WEBPASSWORD: '${PIHOLE_WEB_PASSWORD}'
      DNS1: '127.0.0.1#5053'
      DNS2: '127.0.0.1#5053'
    volumes:
      - './etc-pihole:/etc/pihole'
      - './etc-dnsmasq:/etc/dnsmasq.d'
    depends_on:
      - unbound
    networks:
      - pihole_net

  unbound:
    container_name: pihole-unbound
    image: mvance/unbound:latest
    restart: unless-stopped
    ports:
      - "5053:5053/tcp"
      - "5053:5053/udp"
    networks:
      - pihole_net

networks:
  pihole_net:
    driver: bridge

Honest Pros & Cons

Pros:

Most documented self-hosted DNS tool — every error has a forum thread
Group-based filtering per client is powerful for mixed-use homes
Long-term query log retention (years) for forensics
Mature community, active development

Cons:

No native DoH/DoT — needs an Unbound or cloudflared sidecar
Admin UI feels dated compared to AdGuard Home
No built-in parental controls or safe search enforcement
PHP + SQLite stack is heavier than necessary for a "just resolve DNS" workload

2. AdGuard Home — The Modern All-in-One

AdGuard Home is what Pi-hole would look like if rebuilt today. Single Go binary, native DoH/DoT, modern responsive UI, and first-class parental controls. It is the strongest choice for families who want a turnkey experience without sidecar services.

Standout Capabilities

Native DNS-over-HTTPS / TLS / QUIC. No cloudflared shim, no recursive resolver sidecar.
Built-in parental controls. Block adult content, force safe search on Google/YouTube/Bing, schedule "screen-off" hours per client.
Per-client configuration. Different blocklists, different upstream DNS, different safe-search settings per device or per IP range.
Rich query log. Live stream, per-domain breakdowns, top clients, top blocked domains — all in a mobile-friendly UI.
Private DNS for Android 9+ and iOS 14+. The "Private DNS" hostname field works directly with AdGuard Home if you point a real domain at it.
Encryption support. Encrypted upstream queries to Cloudflare, Quad9, or your own resolver with one click.

Production AdGuard Home Docker Compose

version: "3.9"

services:
  adguardhome:
    container_name: adguardhome
    image: adguard/adguardhome:latest
    restart: unless-stopped
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "853:853/tcp"      # DoT
      - "443:443/tcp"      # DoH (admin UI + encrypted DNS)
      - "3000:3000/tcp"    # Initial setup UI
    volumes:
      - './work:/opt/adguardhome/work'
      - './conf:/opt/adguardhome/conf'
    networks:
      - adguard_net

networks:
  adguard_net:
    driver: bridge

Honest Pros & Cons

Pros:

Single binary, ~80 MB RAM, no database server
Native DoH/DoT/DoQ — no sidecar required
Best UI in the category, mobile-friendly
Parental controls + safe search built in
Active development, frequent releases

Cons:

Query log retention limited compared to Pi-hole's long-term archive
Fewer community tutorials than Pi-hole (but the gap is closing)
Some advanced features (per-client DoH) require the nightly channel

3. Blocky — The Performance Champion

Blocky is a 30 MB Go binary designed for one thing: answering DNS queries as fast as possible. It is not an admin panel, not a web UI — it is a fast forwarder with sophisticated blocking logic, black/white lists per client group, and Prometheus metrics.

Standout Capabilities

Sub-millisecond response times. Caches aggressively, parallelizes upstream queries, and uses connection reuse.
Conditional blocking by client. Apply different blocklists to different IP ranges — kids' devices get parental filters, your dev laptop gets nothing.
Blacklist / whitelist / blocklist groups. Reference external blocklists (Steven Black, Hagezi, OISD) by URL.
Prometheus metrics out of the box. Scrape query counts, block rates, and per-client stats straight into Grafana.
DNS-over-HTTPS / TLS native support.

Production Blocky Docker Compose

version: "3.9"

services:
  blocky:
    container_name: blocky
    image: spx01/blocky:latest
    restart: unless-stopped
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "443:443/tcp"     # DoH
    volumes:
      - './config.yml:/app/config.yml'
      - './lists:/app/lists'
    networks:
      - blocky_net

networks:
  blocky_net:
    driver: bridge

Sample `config.yml`

upstream:
  default:
    - 1.1.1.1
    - 9.9.9.9
  conditional:
    - provider: https://dns.quad9.net/dns-query
      match: netflix.com

blocking:
  blackLists:
    ads:
      - https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
      - https://big.oisd.nl
  clientGroupsBlock:
    default:
      - ads
    kids:
      - ads
      - parental
  whiteLists:
    - bank.example.com

ports:
  dns: 53
  http: 443
  https: 443

prometheus:
  enable: true

Honest Pros & Cons

Pros:

Lowest memory footprint in the category (~30 MB)
Fastest response times, ideal for high-traffic households
Sophisticated client-group blocking without UI overhead
Clean Prometheus metrics for Grafana dashboards

Cons:

No web UI — configuration is YAML only
No parental controls beyond blocklist references
No long-term query log (use external logging if you need it)
Less beginner-friendly than Pi-hole or AdGuard Home

Side-by-Side Resource Footprint (Idle, 1Gbps LAN, ~20 Clients)

Metric	Pi-hole	AdGuard Home	Blocky
RAM	~200 MB	~80 MB	~30 MB
CPU (avg)	~1–2%	<1%	<1%
Image Size	~300 MB	~80 MB	~15 MB
P50 DNS Latency	~3ms	~2ms	<1ms
P99 DNS Latency	~15ms	~8ms	~3ms

Decision Matrix: Which One Should You Self-Host?

Scenario	Pick This
I want a turnkey sinkhole with the most tutorials	Pi-hole
I have kids and want safe search + screen-time controls	AdGuard Home
I want the smallest, fastest resolver for a busy network	Blocky
I need long-term query history for forensics	Pi-hole
I want a polished mobile-friendly admin UI	AdGuard Home
I run Grafana and want Prometheus metrics	Blocky
I need encrypted DNS for Android/iOS private-DNS feature	AdGuard Home or Blocky
I want zero sidecar services	AdGuard Home or Blocky

When NOT to Migrate to a Self-Hosted DNS Sinkhole

Self-hosting your own DNS resolver is not for everyone. Reconsider if:

You rely on a managed security service that filters DNS at the network edge (e.g., Cisco Umbrella, Zscaler). Replacing it removes a layer of protection.
You have a small number of devices (3–4) and do not care about IoT telemetry — a browser extension may be enough.
You lack a static IP or domain. AdGuard Home can work with a dynamic DNS hostname, but it adds friction. Pi-hole can run on a local-only IP with no public exposure.
Your household has heavy DNS-over-HTTPS users (e.g., Firefox with mode Max Protection) — they bypass your sinkhole. Use router-level DNS settings and disable DoH in browsers, or set up a firewall rule to redirect outbound 443/DNS to your sinkhole.

Final Verdict

For most self-hosters in 2026, AdGuard Home is the strongest default. It hits the sweet spot between Pi-hole's maturity and Blocky's modern stack: native DoH/DoT, parental controls, polished UI, and a small footprint. If you are running a multi-segment network with kids, guests, and IoT VLANs, AdGuard Home's client-group configuration is the easiest to operate day-to-day.

If you are a performance purist running a 1Gbps+ homelab and care about per-client Prometheus metrics more than a UI, Blocky is unbeatable. If you have been running Pi-hole for years and are happy with it, there is no urgent reason to migrate — the gap is real but not dramatic.

Ready to set up your own? The full setup walkthrough, including reverse proxy (Caddy/Traefik) and integration with Tailscale for remote DoH, lives at SelfHostStack: Pi-hole Alternatives.

Author: Elder Fernandes runs SelfHostStack, a curated directory of self-hosted alternatives to SaaS. He has deployed every DNS sinkhole in this guide in production on a $4 Hetzner VPS.

Self-Hosted API Clients in 2026: Hoppscotch vs Insomnia vs Schemathesis (Replace Postman)

Elder Fernandes — Thu, 27 Aug 2026 17:54:52 +0000

Self-Hosted API Clients in 2026: Hoppscotch vs Insomnia vs Schemathesis (Replace Postman)

Postman was, for years, the default API client for developers. In 2026 it is no longer the obvious choice. The desktop agent moved to mandatory cloud sync, collections and environments are tied to a Postman account, and the workspace experience is increasingly cluttered with AI assistants, monitors, and broadcast features aimed at enterprise buyers. For teams that simply want to send requests, persist history, and share collections — on their own infrastructure — the cloud round-trip is a dealbreaker.

The problems compound for self-hosted stacks:

Data residency. Internal API base URLs, bearer tokens, and contract specifications should not transit a third-party SaaS. Compliance regimes (HIPAA, GDPR, SOC 2) treat that as a data flow.
Air-gapped and VPC-only environments. A VPS or homelab behind Tailscale has no business depending on api.postman.com for collection resolution.
Latency and flakiness. Cloud sync races against local edits. Merge conflicts on shared collections are still a real complaint.

Self-hosted API tooling has matured enough to replace Postman for the vast majority of workflows. This guide benchmarks the three options we deploy most often at SelfHostStack: Hoppscotch (full web UI), Insomnia (desktop client with self-hosted sync), and Schemathesis (property-based contract testing from an OpenAPI spec).

The Landscape: Comparative Breakdown

Feature / Capability	Hoppscotch	Insomnia	Schemathesis
Primary Paradigm	Web-based API client (Postman-in-browser)	Desktop API client + design tool	CLI / pytest property-based contract tester
Runtime	Vue/Nuxt SPA + Node proxy	Electron + Kong-style interceptor	Python package, runs in CI
Self-Hosting Model	Full container stack (web + proxy + backend)	Kong Gateway-style self-hosted sync (Insomnia Inso CLI, Git-backed)	Docker container or pip install
OpenAPI / Swagger	Import, generate requests	Import, edit, mock, lint	Consumes spec, generates thousands of test cases
Team Collaboration	Shared collections via backend DB	Git-based collections or self-hosted sync	CI artifacts, JUnit/HTML reports
Auth & Environments	Environments, secrets, bearer tokens	Environments, cookie jar, CA certs	Stateful operations, auth fixtures via code
Automated Testing	Hoppscotch CLI (basic)	Inso CLI (lint + contract test)	First-class — property-based, fuzzing, stateful
Resource Footprint	~250 MB RAM (web + proxy + Postgres)	~400 MB desktop client	~80 MB per worker
Best Used For	Interactive testing, shared collections	Day-to-day dev + OpenAPI design	CI contract testing, regression, fuzzing

Explore the full comparison matrix and additional tools (Bruno, Yaade, HTTPie, Requestly) at SelfHostStack: Postman Alternatives.

1. Hoppscotch: The Self-Hosted Postman Web Client

Hoppscotch is the closest drop-in replacement for Postman's web UX. It is a Vue/Nuxt single-page application backed by a Node.js proxy and (optionally) a PostgreSQL database for shared collections and environments. You run it on your own VPS behind your own reverse proxy, and your team accesses it exactly like Postman's web app — except no data ever leaves your infrastructure.

Standout Capabilities

Browser-native UX. No Electron, no 600 MB client. The whole experience loads in a browser tab, which makes it ideal for shared workstations, iPads, and locked-down corporate laptops.
Collections, environments, and history. Full Postman-equivalent data model. Export/import is a one-click JSON flow.
Self-hosted proxy. A backend proxy service bypasses CORS and browser TLS restrictions, so you can hit internal http:// services directly from the UI.
WebSocket, SSE, MQTT, Socket.IO. First-class support, not a plugin afterthought.
Hoppscotch CLI. Run collections from CI with hoppscotch-cli for basic smoke tests — not as deep as Schemathesis, but enough for endpoint reachability.

Production Hoppscotch Docker Compose

version: "3.8"

services:
  hoppscotch:
    image: hoppscotch/hoppscotch:latest
    container_name: hoppscotch_frontend
    restart: unless-stopped
    environment:
      - HOST=0.0.0.0
      - PORT=3000
      # Backend URLs (use internal docker DNS)
      - VITE_BASE_URL=http://hoppscotch_backend:3110
      - VITE_SHORT_URL_DOMAIN=https://hs.yourdomain.com
      # Auth providers — leave empty for local-only / disable OAuth
      - VITE_AUTH_ALLOWED_CALLBACK_URLS=https://hs.yourdomain.com
      - ALLOWED_AUTH_REDIRECT_URLS=https://hs.yourdomain.com
    depends_on:
      - hoppscotch_backend
    networks:
      - hs-net

  hoppscotch_backend:
    image: hoppscotch/hoppscotch-backend:latest
    container_name: hoppscotch_backend
    restart: unless-stopped
    environment:
      - PORT=3110
      - DATABASE_URL=postgres://hoppscotch:${POSTGRES_PASSWORD}@hoppscotch_db:5432/hoppscotch?sslmode=disable
      - JWT_SECRET=${JWT_SECRET}
      - SECRET_KEY_BASE=${SECRET_KEY_BASE}
      - REDIS_URL=redis://hoppscotch_redis:6379
      - REDIRECT_URL=https://hs.yourdomain.com
    depends_on:
      - hoppscotch_db
      - hoppscotch_redis
    networks:
      - hs-net

  hoppscotch_db:
    image: postgres:16-alpine
    container_name: hoppscotch_db
    restart: unless-stopped
    environment:
      - POSTGRES_DB=hoppscotch
      - POSTGRES_USER=hoppscotch
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - hoppscotch_pg:/var/lib/postgresql/data
    networks:
      - hs-net

  hoppscotch_redis:
    image: redis:7-alpine
    container_name: hoppscotch_redis
    restart: unless-stopped
    volumes:
      - hoppscotch_redis_data:/data
    networks:
      - hs-net

volumes:
  hoppscotch_pg:
  hoppscotch_redis_data:

networks:
  hs-net:
    internal: true

Put Traefik or Caddy in front of hoppscotch_frontend on hs.yourdomain.com and route /_backend and /proxy to the backend container. The stack runs comfortably on a 2 vCPU / 2 GB VPS.

Honest Pros & Cons

Pros

Genuinely Postman-like UX — the smallest team learning curve of any alternative here.
Fully open-source (MIT). No tier-gated features, no "Team plan" upgrade pressure.
Works on iPads and locked-down corporate machines where you cannot install an Electron app.

Cons

The backend auth story is fiddly. Self-hosted OAuth (Google/GitHub) needs careful redirect URL setup; for local-only deployments you'll probably disable auth entirely and rely on your reverse proxy's HTTP Basic + mTLS.
The CLI is still lightweight. For serious regression suites you'll pair Hoppscotch with Schemathesis anyway.
Self-hosted proxy logs request/response bodies by default in dev mode — make sure production logging is dialed back so secrets don't leak to journald.

2. Insomnia: The Desktop Client With Git-Backed Sync

Insomnia (now stewarded by Kong under the Kong Insomnia brand) is the most polished desktop API client available. After Kong's acquisition roadmap uncertainty settled, the project has re-emphasized local-first workflows: the desktop client runs offline by default, and team collections are synced either via Kong's cloud, or — the self-hosted path — via plain Git repositories.

Standout Capabilities

OpenAPI design surface. Insomnia is not just a request sender; it is a competent OpenAPI editor with live preview, linting, and mock servers. For teams maintaining a single source of truth spec, this collapses two tools into one.
Inso CLI. The inso binary (distributed as a Docker image) lints specs, runs contract tests, and generates declarative Kong config from your OpenAPI. Drops cleanly into a GitLab or GitHub Actions pipeline.
Native TLS and CA control. Pin custom root CAs for internal mTLS services without fighting Electron's certificate store.
Git sync. A .insomnia directory of YAML files committed to a private Git forge (Forgejo, Gitea, GitLab self-hosted) replaces Postman's cloud sync entirely. Branch-based collection workflows actually work.

Insomnia + Inso CI via Docker Compose

Insomnia itself is a desktop app, but the inso CLI is the part that matters for self-hosted CI. Here is a Compose snippet that runs contract tests against your internal API on every commit:

version: "3.8"

services:
  inso_contract_test:
    image: support/inso:latest
    container_name: inso_run
    profiles: ["test"]   # invoke with: docker compose --profile test run inso_contract_test
    working_dir: /workspace
    volumes:
      - ./specs:/workspace:ro
      - ./reports:/reports
    environment:
      - API_BASE_URL=https://api.internal.yourdomain.com
      - API_TOKEN=${INTERNAL_API_TOKEN}
    command: >
      sh -c "inso lint spec main --src /workspace/openapi.yaml &&
             inso run test main --src /workspace/openapi.yaml
                 --env ci
                 --test-name 'Contract regression'
                 --reporter junit --outputFile /reports/junit.xml
                 --reporter html --outputFile /reports/report.html"

This runs on your existing Forge Actions or Gitea Actions runner — no external API, no Postman cloud. The openapi.yaml lives in the same repo as your application code, versioned and reviewed through normal pull requests.

Honest Pros & Cons

Pros

The best desktop API client UX, full stop. Request building, response inspection, and GraphQL explorer are all best-in-class.
Native OpenAPI design — write your spec and immediately mock it from the same window.
inso in CI is a serious contract-testing tool; it catches breaking changes before merge.

Cons

The Kong brand roadmap created a year+ of churn and unclear licensing on enterprise features. The open-source core (Insomnia Core / Inso) is fine, but watch the repo for license changes before standardizing on it.
Desktop-only — there is no self-hosted web UI. Teams that want browser access still need Hoppscotch alongside it.
Electron memory footprint (~400 MB resident) is noticeable on small laptops. Not a real problem on a workstation; an annoyance on a 4 GB VM used for jump-box duties.

3. Schemathesis: Property-Based Contract Testing from Your Spec

Schemathesis is the odd one out in this list, because it is not a GUI client at all. It is a Python tool that reads your OpenAPI (or GraphQL) specification and generates thousands of property-based test cases automatically — fuzzing endpoints, asserting that response status codes match the documented schema, checking that the API does not return 500 on inputs that satisfy the documented constraints. Think QuickCheck for your HTTP API.

For teams that already have an OpenAPI spec (because they're using Insomnia to author it), Schemathesis is what you wire into CI to actually enforce the contract.

Standout Capabilities

Automatic test generation. No hand-written test cases — Schemathesis reads your spec and generates valid and invalid inputs for every operation, covering edge cases humans forget (null arrays, negative integers where minimum: 0 is declared, malformed UUIDs).
Stateful testing. Define a state machine (create resource → get it → update it → delete it) and Schemathesis explores valid orderings, surfacing race conditions and state-handling bugs.
Failure shrinking. When a test fails, Schemathesis shrinks the failing input to the minimal reproducer — e.g. a single empty string rather than a 4 KB random payload.
Auth fixtures. Provide tokens via a Python fixture, so tests run against an authenticated internal API without leaking secrets into the spec.

Schemathesis Docker Compose

version: "3.8"

services:
  schemathesis:
    image: schemathesis/schemathesis:3
    container_name: schemathesis_run
    profiles: ["contract"]
    volumes:
      - ./specs:/specs:ro
      - ./reports:/reports
    environment:
      - API_BASE_URL=https://api.internal.yourdomain.com
      - AUTH_TOKEN=${INTERNAL_API_TOKEN}
    command: >
      run /specs/openapi.yaml
      --base-url ${API_BASE_URL}
      --header "Authorization=Bearer ${AUTH_TOKEN}"
      --checks all
      --max-response-time 5000
      --workers 4
      --junit-xml /reports/schemathesis.xml
      --show-traceback
    networks:
      - api-net

networks:
  api-net:
    external: true

Run it on every PR via Forgejo Actions; a red build blocks merge. This catches the entire class of "I renamed a field in the code but forgot to update the spec" (or vice versa) before it reaches staging.

Honest Pros & Cons

Pros

Finds bugs GUI testing literally cannot — humans do not click "send" with 200 malformed email variants.
Output is a normal pytest/junit artifact; integrates with every CI dashboard you already run.
Zero infrastructure beyond the container. No DB, no auth, no reverse proxy config.

Cons

Not a replacement for interactive debugging. You still want Hoppscotch or Insomnia for "let me poke this endpoint by hand."
Requires a reasonably accurate OpenAPI spec. If your spec is out of date, Schemathesis tests the spec, not your actual API contract — and false greens are worse than reds.
Python-only extension model. Custom auth flows that need a live OIDC token exchange require writing a Python fixture, which is friction if your stack is Go or Node.

Production Best Practices for Self-Hosted API Testing

Treat the spec as the source of truth. Author OpenAPI in Insomnia or as a YAML file in your app repo. Generate Hoppscotch collections and Schemathesis tests from that spec, not the other way around. One spec, three consumers.
Pin the tool images. Hoppscotch, inso, and Schemathesis all move fast. Pin to a digest (image: hoppscotch/hoppscotch@sha256:...) in production Compose files; bump deliberately in a PR.
Isolate the test network. All three Compose snippets above use an internal docker network. Pair them with a tecnativa/docker-socket-proxy if they need container discovery, and never mount the Docker socket directly.
Rotate API tokens via Infisical or Vault. INTERNAL_API_TOKEN should come from your secrets manager, not a committed .env. Wire it through environment injection at deploy time.
Back up the Hoppscotch Postgres volume. Collections and environments live there. Add the hoppscotch_pg volume to your restic/pgBackRest schedule alongside the rest of the SelfHostStack data services.

Which Solution Should You Choose?

Choose Hoppscotch if you want a Postman replacement your whole team can open in a browser, with collections and environments shared from your own VPS. This is the answer for 80% of teams.
Choose Insomnia if your workday is desktop-centric, you author OpenAPI specs, and you want a contract-testing CLI (inso) that drops into your existing CI pipeline.
Choose Schemathesis as the automated layer on top of either — property-based contract testing that catches spec/code drift and malformed input bugs before they ship.

The realistic stack at most self-hosted shops in 2026 is all three: Hoppscotch for interactive testing, Insomnia for spec design and inso contract checks in CI, and Schemathesis for deep property-based fuzzing on the merge gate. Together they cover everything Postman + Newman did, with zero cloud dependency and full ownership of your API contract data.

Looking for pre-configured, production-hardened Docker stacks — Hoppscotch behind Traefik, Inso in CI, Schemathesis wired into Forgejo Actions, with automated backups?
Check out the SelfHostStack Postman Alternatives Catalog and grab the Self-Hosted Starter Stack Pack — save hours of deployment time and run enterprise-grade self-hosted developer infrastructure on your own VPS.

Self-Hosted Feature Flags in 2026: Unleash vs Flagsmith vs GO Feature Flag (Ditch LaunchDarkly)

Elder Fernandes — Thu, 27 Aug 2026 17:54:51 +0000

Self-Hosted Feature Flags in 626: Unleash vs Flagsmith vs GO Feature Flag (Ditch LaunchDarkly)

Feature flags have become indispensable for modern deployment workflows — trunk-based development, canary releases, A/B testing, and kill switches all depend on them. But commercial platforms like LaunchDarkly and Split.io enforce per-seat pricing ($15–30/developer/month) that scales poorly with growing teams. A 20-developer team pays $3,600–$7,200/year just to toggle booleans.

Self-hosting an open-source feature flag service gives you unlimited seats, SDK parity with major languages, audit logs, gradual rollouts, and full data ownership on a single VPS.

In this guide, we compare the top three self-hostable feature flag platforms in 2026: Unleash, Flagsmith, and GO Feature Flag.

The Landscape: Comparative Breakdown

Feature / Capability	Unleash	Flagsmith	GO Feature Flag
Core Paradigm	Enterprise-grade flag server with strategies	Full feature platform + remote config + experimentation	Lightweight Go relay/proxy with YAML config
Technology Stack	Node.js, PostgreSQL, Redis	Django (Python), PostgreSQL, Redis	Go (single binary), YAML/JSON config
SDK Languages	16+ (Java, JS, Python, Go, Rust, Ruby, .NET, Swift, Android, iOS, etc.)	9+ (Python, JS, Go, Ruby, Rust, Android, iOS, .NET, Java)	8+ via OpenFeature provider (Go, JS, Python, Java, .NET, Rust)
Strategy Types	Gradual rollout, A/B, multivariate, kill switch, remote address	Gradual, boolean, number, string, remote config	Boolean, gradual, A/B, time-based, dark launch
Audit Log	Yes (full event log)	Yes (change history per flag)	Basic (config diff via Git)
UI Dashboard	Full admin UI with projects & environments	Full admin UI with segments & identities	Minimal API + OpenFeature-compatible
Self-Host Tier	Open-source (Apache 2.0) — unlimited seats	Open-source (BSD-3) — unlimited seats	Open-source (MIT) — unlimited
Best For	Teams needing enterprise strategies & audit trails	Teams wanting remote config + experiments in one UI	Teams wanting GitOps-driven flags with minimal footprint

1. Unleash — The Enterprise-Grade Flag Server

Unleash is the most mature open-source feature flag platform, originally built at Finn.no (Norway's largest marketplace). It powers production workloads for teams of 50–500+ developers and offers the richest set of rollout strategies.

Key Strengths

Advanced Strategies: Native support for gradual rollout (percentage-based), A/B testing with variant buckets, multi-variant flags, geographic targeting, and custom strategy plugins.
Environment Isolation: Built-in concept of projects → environments (dev, staging, prod) with per-environment token scoping.
Audit Trail: Every flag change is logged with actor, timestamp, and diff — critical for compliance and incident post-mortems.
SDK Ecosystem: Official SDKs for 16+ languages including Rust, Ruby, Android, and iOS. Edge SDKs for Next.js and Cloudflare Workers.
API Tokens: Scoped API tokens with per-project and per-environment permissions — no global admin keys in your application config.

Docker Compose Setup

version: "3.9"

services:
  unleash-db:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: unleash
      POSTGRES_USER: unleash
      POSTGRES_PASSWORD: ${UNLEASH_DB_PASSWORD}
    volumes:
      - unleash-db:/var/lib/postgresql/data
    restart: unless-stopped

  unleash:
    image: unleashorg/unleash-server:6
    ports:
      - "4242:4242"
    environment:
      DATABASE_URL: postgres://unleash:${UNLEASH_DB_PASSWORD}@unleash-db:5432/unleash
      INIT_ADMIN_API_TOKENS: ${UNLEASH_API_TOKEN}
    depends_on:
      - unleash-db
    restart: unless-stopped

volumes:
  unleash-db:

Honest Pros & Cons

Pros:

Battle-tested at enterprise scale (Finn.no, DNB, Equinor)
Rich strategy engine with plugin architecture
Full audit log out of the box
Active community (9k+ GitHub stars)

Cons:

Node.js runtime means higher memory footprint (~300–500MB)
UI can feel cluttered for small teams with simple boolean needs
Enterprise edition (Unleash Cloud) is separate from self-hosted open-source; some features (SSO, role-based access) are enterprise-only
No built-in experimentation/bayesian stats — you need external analytics

2. Flagsmith — Feature Flags + Remote Config + Experiments

Flagsmith is a newer platform that combines feature flags with remote configuration, user segments, and lightweight experimentations. It's the best choice for teams that want flags and dynamic config in a single UI without adding a separate tool.

Key Strengths

Remote Config: Flagsmith stores boolean, string, integer, and JSON values per flag — your app can fetch config at runtime without redeploying.
User Segments: Define segments (e.g., "beta users", "enterprise tier") and target flags to specific segments or individual identities.
Identity Management: Built-in concept of user identities — you can override flags per user for testing and QA.
Experimentation (Premium): A/B testing with Bayesian statistics is available in the open-source edition for basic scenarios.
Edge Proxy: A lightweight Go edge relay that caches flags client-side and reduces latency to <1ms.

Docker Compose Setup

version: "3.9"

services:
  flagsmith-db:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: flagsmith
      POSTGRES_USER: flagsmith
      POSTGRES_PASSWORD: ${FLAGSMITH_DB_PASSWORD}
    volumes:
      - flagsmith-db:/var/lib/postgresql/data
    restart: unless-stopped

  flagsmith:
    image: flagsmith/flagsmith-api:latest
    ports:
      - "8000:8000"
    environment:
      DATABASE_URL: postgres://flagsmith:${FLAGSMITH_DB_PASSWORD}@flagsmith-db:5432/flagsmith
      SECRET_KEY: ${FLAGSMITH_SECRET}
      ENVIRONMENT: production
    depends_on:
      - flagsmith-db
    restart: unless-stopped

  flagsmith-frontend:
    image: flagsmith/flagsmith-frontend:latest
    ports:
      - "8080:8080"
    environment:
      API_URL: http://flagsmith:8000/api/v1
    depends_on:
      - flagsmith
    restart: unless-stopped

volumes:
  flagsmith-db:

Honest Pros & Cons

Pros:

Remote config + flags in one platform
Clean modern UI with segment targeting
Edge proxy for client-side caching
Strong SDK support including mobile (iOS, Android)

Cons:

Django/Python stack requires more memory than a Go binary (~400–600MB with Postgres)
Documentation can lag behind the actual API capabilities
Some advanced features (SSO, audit logs) are enterprise tier
Community is smaller than Unleash (~4k GitHub stars)

3. GO Feature Flag — The GitOps-Native Flag Relay

GO Feature Flag takes a fundamentally different approach: instead of a database-backed server with a UI, it's a single Go binary that reads flag configuration from YAML/JSON files (local or remote Git/S3/HTTP) and exposes an OpenFeature-compatible API. It's designed for teams who want flags to live in Git alongside their code.

Key Strengths

GitOps-Native: Flag configs are YAML files versioned in Git — changes go through pull requests, code review, and CI pipelines. No dashboard needed.
Minimal Footprint: Single Go binary, ~30MB memory, no database required.
OpenFeature Standard: Full compliance with the OpenFeature specification — works with any OpenFeature SDK (Go, JS, Python, Java, .NET, Rust).
Configuration Sources: Read flag files from local disk, Git, S3, HTTP endpoints, or Kubernetes ConfigMaps.
No Database: State is derived from the config file — no migrations, no DB backups, no connection pool tuning.

Docker Compose Setup

version: "3.9"

services:
  go-feature-flag-relay:
    image: gofeatureflag/relay-proxy:latest
    ports:
      - "1031:1031"
    environment:
      - LISTEN=:1031
      - POLLINGINTERVAL=5s
      - RETRIEVER_KIND=http
      - RETRIEVER_URL=https://raw.githubusercontent.com/yourorg/flags/main/flags.yml
      - RETRIEVER_GITHUB_TOKEN=${GITHUB_TOKEN}
    restart: unless-stopped

Example Flag Config (flags.yml)

new-checkout-flow:
  variations:
    enabled: true
    disabled: false
  defaultRule:
    variation: disabled
  rules:
    - name: beta-testers
      query: '{ key: "email", operator: endsWith, value: "@beta.com" }'
      variation: enabled
    - name: 10-percent-rollout
      query: '{ key: "userId", operator: percentage, value: 10 }'
      variation: enabled

Honest Pros & Cons

Pros:

Zero database — perfect for GitOps and Kubernetes
~30MB memory footprint — runs on the smallest VPS
Full OpenFeature compliance — vendor-neutral SDK layer
Configuration-as-code with PR review and audit trail via Git

Cons:

No built-in UI dashboard — you manage flags via YAML in Git
No built-in audit log beyond Git history
Smaller community (~1.5k GitHub stars)
Not ideal for non-technical product teams who need a visual dashboard
No native experimentation/bayesian A/B testing

Decision Guide

Your Situation	Recommended Tool
Enterprise team, need audit trails + SSO + advanced strategies	Unleash
Need flags + remote config + user segments in one UI	Flagsmith
GitOps-native, no database, minimal footprint	GO Feature Flag
Want all three approaches?	Combine: GO Feature Flag as edge relay + Unleash as backend

Production Best Practices

Pin Docker image tags: Use unleash-server:6.6.0 not latest. Flag platform upgrades can introduce breaking API changes.
Network isolation: Put the flag server and database on an internal Docker network. Expose only the API port (4242 for Unleash, 8000 for Flagsmith, 1031 for GO Feature Flag) through Traefik/Caddy with mTLS.
SDK initialization: Initialize SDKs with a server-sent events (SSE) connection for real-time flag updates. Polling adds latency; SSE is push-based and near-instant.
Secrets management: Store API tokens and database passwords in Infisical or Vaultwarden — not in .env files checked into Git.
Backup the database: If using Unleash or Flagsmith, automate PostgreSQL backups with pgBackRest or restic. GO Feature Flag needs no backup (state is in Git).

Conclusion

LaunchDarkly charges $15–30/developer/month. For a 20-developer team, that's $3,600–$7,200/year. A self-hosted feature flag platform on a $5 VPS gives you unlimited seats, full data ownership, and SDK parity with every major language.

Unleash for enterprise teams needing audit trails and advanced strategies.
Flagsmith for teams wanting flags + remote config in one platform.
GO Feature Flag for GitOps-native deployments with zero database overhead.

Explore the full comparison and deployment guides:
👉 Self-Hosted Feature Flag Alternatives

Self-Hosted Customer Support & Helpdesks in 2026: Chatwoot vs FreeScout vs Helpy

Elder Fernandes — Mon, 24 Aug 2026 05:45:34 +0000

Self-Hosted Customer Support & Helpdesks in 2026: Chatwoot vs FreeScout vs Helpy

Delivering exceptional customer support is essential for growth, but commercial helpdesk platforms enforce punitive pricing models:

Per-Agent Seat Taxes: Intercom, Zendesk, and Front charge $49 to $119+ per agent per month. As your support and engineering teams grow, licensing costs quickly spiral into tens of thousands of dollars annually.
Add-On Paywalls: Essential capabilities like WhatsApp integration, SMS channels, unlimited email history, and custom webhooks are locked behind enterprise tiers.
Customer Data Privacy: Confidential customer conversations, billing inquiries, and personal data are held on third-party multi-tenant servers.

Self-hosting an open-source support helpdesk gives your team unlimited agent seats, unified omnichannel inboxes (Live Chat, WhatsApp, Email, Telegram, Social), full webhook customization, and complete data ownership on your own VPS.

In this guide, we evaluate the top three self-hosted support and ticketing platforms in 2026: Chatwoot, FreeScout, and Helpy.

The Landscape: Comparative Breakdown

Feature / Capability	Chatwoot	FreeScout	Helpy
Core Paradigm	Modern Omnichannel Live Chat + Shared Inbox	Clean Shared Email Inbox (Help Scout Alternative)	Traditional Support Ticketing & Knowledge Base
Technology Stack	Ruby on Rails, Vue.js, PostgreSQL, Redis	PHP (Laravel), MySQL/PostgreSQL, Vue	Ruby on Rails, PostgreSQL
Supported Channels	Web Live Chat, Email, WhatsApp, Telegram, Facebook, SMS	Email Inboxes, Webhooks, Community Modules	Email Ticketing, Public/Private Help Center
Bot & AI Integrations	Native Webhooks, Rasa, Dialogflow, OpenAI	Modules available for automation & canned replies	Automated workflows & AI taggers
Mobile Applications	Official iOS & Android Apps	Mobile Web / PWA / Community Apps	Mobile responsive web UI
Hardware Overhead	Moderate (2 vCPU, 4GB RAM)	Ultra-Lightweight (1 vCPU, 1GB RAM)	Lightweight (1-2 vCPU, 2GB RAM)
Best Used For	Real-time website chat, omnichannel SaaS support	Shared team email management, agency ticketing	Classic IT helpdesks and knowledge base portals

Explore full feature comparisons and alternative tools at: SelfHostStack Zendesk Alternatives.

1. Chatwoot: The Modern Intercom & Crisp Alternative

Chatwoot is an open-source, omnichannel customer engagement suite. It unifies live website chat widgets, email support, WhatsApp business numbers, and social channels into a single real-time collaborative dashboard.

Standout Capabilities

Embeddable Live Widget: Customizable JavaScript widget with automated greetings, offline forms, and pre-chat surveys.
Multi-Brand & Multi-Team Routing: Route inquiries by department (Sales, Billing, Technical) with automated assignment rules.
Rich Mobile Ecosystem: Official native apps for iOS and Android allowing team members to resolve customer queries on the go.

Production Chatwoot Docker Compose Architecture

version: "3.8"

services:
  chatwoot_web:
    image: chatwoot/chatwoot:latest
    container_name: chatwoot_web
    restart: unless-stopped
    depends_on:
      - postgres
      - redis
    environment:
      - NODE_ENV=production
      - RAILS_ENV=production
      - INSTALLATION_ENV=docker
      - SECRET_KEY_BASE=${SECRET_KEY_BASE}
      - FRONTEND_URL=https://support.yourdomain.com
      - POSTGRES_HOST=postgres
      - POSTGRES_DATABASE=chatwoot_production
      - POSTGRES_USERNAME=chatwoot
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
      - REDIS_URL=redis://redis:6379
      - MAILER_SENDER_EMAIL=support@yourdomain.com
      - SMTP_ADDRESS=smtp.resend.com
      - SMTP_PORT=587
      - SMTP_USERNAME=resend
      - SMTP_PASSWORD=${SMTP_PASSWORD}
    entrypoint: docker/entrypoints/rails.sh
    command: ['bundle', 'exec', 'rails', 's', '-p', '3000', '-b', '0.0.0.0']
    ports:
      - "127.0.0.1:3000:3000"

  chatwoot_worker:
    image: chatwoot/chatwoot:latest
    container_name: chatwoot_worker
    restart: unless-stopped
    depends_on:
      - postgres
      - redis
    environment:
      - NODE_ENV=production
      - RAILS_ENV=production
      - INSTALLATION_ENV=docker
      - SECRET_KEY_BASE=${SECRET_KEY_BASE}
      - FRONTEND_URL=https://support.yourdomain.com
      - POSTGRES_HOST=postgres
      - POSTGRES_DATABASE=chatwoot_production
      - POSTGRES_USERNAME=chatwoot
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
      - REDIS_URL=redis://redis:6379
    entrypoint: docker/entrypoints/rails.sh
    command: ['bundle', 'exec', 'sidekiq', '-C', 'config/sidekiq.yml']

  postgres:
    image: postgres:16-alpine
    container_name: chatwoot_postgres
    restart: unless-stopped
    volumes:
      - chatwoot_pgdata:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=chatwoot_production
      - POSTGRES_USER=chatwoot
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}

  redis:
    image: redis:7-alpine
    container_name: chatwoot_redis
    restart: unless-stopped
    volumes:
      - chatwoot_redisdata:/data

volumes:
  chatwoot_pgdata:
  chatwoot_redisdata:

2. FreeScout: The Ultra-Lightweight Help Scout Clone

FreeScout is built on PHP/Laravel and delivers an exceptional shared email inbox experience. If your customer support workflow is primarily email-centric (e.g. support@yourdomain.com), FreeScout offers near-zero memory footprint (under 300MB RAM) and blazing-fast response speeds.

Standout Capabilities

Effortless Email Threading: Seamlessly parses incoming IMAP/POP3 emails and sends outbound replies via SMTP.
Collision Detection: Prevents two team members from accidentally answering the same customer ticket simultaneously.
Low Resource Profile: Easily runs on a $3.50/mo VPS alongside existing web workloads.

Production Best Practices for Self-Hosted Support

Transactional Email Reliability: Connect your self-hosted helpdesk to a reliable SMTP relay (such as Amazon SES, Resend, or Stalwart) to guarantee 100% inbox deliverability.
Automated Database Backups: Schedule daily WAL and snapshot backups with pgBackRest or restic to an offsite S3 bucket.
Webhook Integrations: Forward new urgent tickets to internal Slack/Discord channels using n8n or native webhook notifications.

Which Solution Should You Choose?

Choose Chatwoot if you need real-time website live chat, mobile support apps, and multi-channel messaging (WhatsApp, Telegram, Live Chat).
Choose FreeScout if your support operations revolve around shared email inboxes and you want minimal RAM usage on a tiny VPS.
Choose Helpy if you require classic ticketing workflows combined with a self-hosted multilingual knowledge base.

Looking for pre-configured, production-hardened Docker stacks with Traefik SSL and automated backups?

Check out the Self-Hosted Starter Stack Pack ($29) — save hours of deployment time and run enterprise-grade self-hosted infrastructure.