DevOpsPack

@feed.devopspack.com.ap.brid.gy

Practical guides, battle-tested stacks, and production-ready setups. ๐ŸŒ‰ bridged from โ‚ https://devopspack.com/, follow @ap.brid.gy to interact

Memos is the self-hosted note-taking tool that gets out of your way. One Docker command, a timeline of Markdown notes, tags, full-text search, public or private visibility per note, REST API, and MCP integration. MIT, 61k+ stars, Go + SQLite. No folders, no workspaces, no friction.

Memos: The Self-Hosted Note-Taking Tool That Gets Out of Your Way

Most note-taking tools ask you to decide before you write. Title? Folder? Workspace? Project? By the time you've answered, the thought is gone. Memos doesn't ask. Open it, type, save. The note lands in a reverse-chronological timeline. Tag it later. Find it with search. That's the model. One Docker command to deploy, SQLite by default, no telemetry, no subscription. MIT licensed, **61,000+ GitHub stars** , written in Go. ## What Memos is Memos (usememos.com) is an open-source, self-hosted quick-capture note-taking tool. **Go** backend, TypeScript/React frontend. **MIT licensed**. Current release: **v0.29.1** (June 2026). SQLite by default, PostgreSQL and MySQL also supported. Single container, no external dependencies. The design philosophy is deliberate minimalism. Not trying to be Notion or Obsidian. A timeline for quick capture โ€” closer to a private feed of your own thoughts than a structured knowledge base. ## The timeline model Every memo is a timestamped entry in a reverse-chronological timeline. No folders, no nested pages, no hierarchy. You never decide where something goes โ€” you write it, it exists, you search for it later. Each memo has: **Visibility** (Private / Protected / Public), inline **tags** with `#tag` syntax automatically indexed, **pinning** , **relations** (link memos to each other), **reactions** , and **attachments**. ## Markdown editor v0.29.0 shipped a rebuilt CodeMirror 6 editor. Markdown stays visible and unchanged while headings, formatting, tags, and mentions are styled in place โ€” no WYSIWYG mode switching. Tag completion, list indentation, focus mode, and a formatting toolbar. Full Markdown support: headings, code blocks with syntax highlighting, tables, task lists, blockquotes. ## Tags and search Tags written inline as `#tagname` anywhere in the memo text โ€” no separate UI. The sidebar shows all tags with memo counts, clickable to filter the timeline. Full-text search is fast: Go + SQLite handle personal note volumes efficiently. ## Public sharing and microblog Per-memo visibility: set each note independently to private, protected, or public. Public memos appear at a clean URL on your instance. Many people run Memos as a personal public microblog on their own domain โ€” same instance, different visibility per memo, no separate tool. ## REST API and MCP Full REST API at `/api/v1`, authenticated with personal access tokens. v0.29.0 shipped a rebuilt MCP (Model Context Protocol) integration โ€” Memos exposes an OpenAPI-driven MCP toolset covering memos, comments, relations, reactions, shortcuts, and attachments. An AI agent can read and write your Memos instance as a tool: "save this to my notes", "search my memos for kubernetes". Signed webhooks (Standard Webhooks HMAC-SHA256) fire on memo events โ€” useful for n8n automations: new `#task` memo โ†’ create ticket, new public memo โ†’ push to newsletter. ## Web Clipper Official Chrome and Firefox extensions. Select text on any page, right-click โ†’ save to Memos. Review the clip, choose visibility, customize the Markdown format before saving. ## Self-hosting docker run -d \ --name memos \ -p 5230:5230 \ -v ~/.memos:/var/opt/memos \ neosmemo/memos:stable Navigate to `http://localhost:5230`, complete setup, start writing. SQLite lives in `~/.memos` โ€” backup is a directory copy. For production with Docker Compose: services: memos: image: neosmemo/memos:stable restart: unless-stopped ports: - "5230:5230" volumes: - ./memos:/var/opt/memos Put Traefik in front for HTTPS. PostgreSQL or MySQL replace SQLite via `--driver` and `--dsn` flags for larger multi-user deployments. Helm charts available for Kubernetes. ARM supported โ€” runs on Raspberry Pi. Resource usage: ~50MB RAM at idle. Runs comfortably on the smallest VPS tier alongside many other containers. ## Multi-user Multiple accounts on one instance, each with their own private timeline and public profile. Admin controls open or invite-only registration. Works as a shared family or small-team note space with individual private areas. ## Memos vs Notion / Obsidian / AFFiNE **vs Notion** โ€” category mismatch. Notion is a structured knowledge base with databases, relational tables, and project management. If you use Notion primarily for daily logs, quick notes, and bookmarks โ€” Memos does that better and simpler, self-hosted, for free. **vs Obsidian** โ€” Obsidian is for building connected knowledge with backlinks and graph view, stored as plain `.md` files. Memos is for quick capture without hierarchy. Many people run both: Memos for daily capture, Obsidian for long-form knowledge building. **vs AFFiNE** โ€” AFFiNE combines docs, whiteboard, and databases in one self-hosted workspace. Much more powerful but also heavier (PostgreSQL + Redis + Electron). Memos is a single container at 50MB RAM. Different use cases โ€” AFFiNE for team knowledge, Memos for personal quick capture. ## Who it's for **Good fit:** * Anyone wanting a frictionless private scratchpad on their own infrastructure * Developers who want REST API and MCP integration for AI agent workflows * Teams running a shared quick-notes instance for daily logs and snippets * People who want a lightweight public microblog on their own domain * Home lab runners who want a useful low-resource service **Not ideal:** * Structured knowledge bases with databases and project management โ€” use Notion or AFFiNE * Plain Markdown file storage with graph backlinks โ€” use Obsidian * Enterprise SSO/SCIM requirements โ€” no commercial entity or SLA behind Memos ## My take The timeline model with no folders removes the most common note-taking friction: deciding where to put something. You don't decide โ€” you write, search later. The resource footprint justifies running it on any home server: one container, 50MB RAM, SQLite backup is a directory copy. The MCP integration is the most interesting recent development. Memos as a personal knowledge store that AI tools can read from and write to makes it useful in agentic workflows beyond just human note-taking. 61,000+ stars without a commercial entity behind it is a genuine signal โ€” this is a tool people actually use and recommend. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help setting up a self-hosted notes stack? Deploying Memos โ€” Docker Compose, Traefik for HTTPS, custom domain, PostgreSQL for multi-user, API automation with webhooks and n8n, and MCP wiring for AI tools โ€” takes an afternoon. I can wire it into your existing self-hosted infrastructure. Get in touch at pipoline.com โ†’

devopspack.com

CrowdSec is the collaborative open source IPS and WAF โ€” detects brute-force, port scans and web exploits, blocks via bouncers at the firewall or reverse proxy. The community blocklist from 200,000+ installations means you block known attackers before they reach you. MIT, Go, free forever.

CrowdSec: The Collaborative IPS That Blocks Attackers Before They Reach You

Every server exposed to the internet gets hammered. SSH brute-force starts within minutes. Web crawlers probe for admin panels and CVEs. Port scanners map exposure. The default posture โ€” fail2ban a few IPs โ€” stops working at scale. CrowdSec is the modern answer. It watches logs and HTTP traffic for malicious behavior, identifies attacking IPs, and feeds decisions to bouncers that block at the firewall, reverse proxy, or Kubernetes ingress. The differentiator: the community blocklist. 200,000+ installations share attack signals globally. When an IP attacks someone else, you block it before it reaches you. ## What CrowdSec is CrowdSec is an open-source crowdsourced IPS and WAF. Written in **Go** , **MIT licensed** , currently **v1.7.8** (May 2026). **14,100+ GitHub stars**. Used by **200,000+ installations** across VMs, Docker stacks, Kubernetes, and bare metal. Three layers: * **Security Engine** โ€” reads logs and HTTP requests, matches behavioral scenarios, generates decisions (ban this IP for 4 hours) * **Bouncers** โ€” enforce decisions at firewall, reverse proxy, CDN, or application level * **Central API + Community Blocklist** โ€” shares signals, downloads the curated global blocklist "Detect Here, Remedy There" โ€” one Security Engine can protect multiple services through multiple bouncers simultaneously. ## Detection โ€” scenarios and parsers Logs flow through: Acquisition โ†’ Parsers โ†’ Scenarios. The Hub provides parsers for nginx, sshd, Apache, postfix, MySQL, and dozens more. Built-in scenarios: * `crowdsecurity/ssh-bf` โ€” SSH brute force (5 failed auth in 20s โ†’ ban) * `crowdsecurity/http-crawl-non_statics` โ€” probing for sensitive paths * `crowdsecurity/wordpress-bf` โ€” WordPress wp-login brute force * `crowdsecurity/http-probing` โ€” systematic path scanning * `crowdsecurity/http-bad-user-agent` โ€” known malicious user agents ## AppSec โ€” WAF component CrowdSec's AppSec component inspects HTTP requests forwarded from Nginx, Traefik, HAProxy, or Caddy for SQL injection, XSS, path traversal, CVE exploitation patterns (105,000+ rules), and virtual patching. Supports ModSecurity SecLang rules โ€” teams migrating from ModSecurity can bring existing rule sets. OWASP CRS compatible. ## Community blocklist Every enrolled CrowdSec instance shares attack signals. Signals are aggregated and validated โ€” IPs appearing across enough installations join the Community Blocklist. Every engine downloads this and blocks proactively. CrowdSec claims this blocks threats 7โ€“60 days ahead of traditional vendors. Free tier covers the most active attackers; paid tiers add premium feeds and enriched CTI. ## Bouncers * **cs-firewall-bouncer** โ€” iptables/nftables, blocks at kernel level * **cs-nginx-bouncer** โ€” Nginx Lua module, serves 403 or captcha * **cs-traefik-bouncer** โ€” Traefik middleware plugin * **cs-cloudflare-bouncer** โ€” pushes decisions to Cloudflare via API * **cs-aws-waf-bouncer** โ€” pushes to AWS WAF IP sets * **cs-kubernetes-bouncer** โ€” Kubernetes network policy enforcement ## Docker Compose deployment services: crowdsec: image: crowdsecurity/crowdsec:latest restart: unless-stopped environment: COLLECTIONS: "crowdsecurity/linux crowdsecurity/traefik" volumes: - ./crowdsec/acquis.yaml:/etc/crowdsec/acquis.yaml - ./crowdsec/db:/var/lib/crowdsec/data - /var/log:/var/log:ro traefik-bouncer: image: fbonalair/traefik-crowdsec-bouncer:latest restart: unless-stopped environment: CROWDSEC_BOUNCER_API_KEY: ${CROWDSEC_BOUNCER_KEY} CROWDSEC_AGENT_HOST: crowdsec:8080 `acquis.yaml` configures log sources: filenames: - /var/log/traefik/*.log labels: type: traefik --- filenames: - /var/log/auth.log labels: type: syslog Enroll in the free Console: `cscli console enroll <token>`. Key CLI commands: cscli decisions list # active bans cscli decisions add --ip 1.2.3.4 --duration 24h cscli collections install crowdsecurity/wordpress cscli metrics For Kubernetes: official Helm chart deploys the Security Engine as a DaemonSet, bouncer as ingress middleware, decisions synchronized cluster-wide. ## CrowdSec vs fail2ban * **Community blocklist** โ€” blocks known attackers globally before they hit you; fail2ban only reacts to your own logs * **Bouncer model** โ€” enforce at any layer; fail2ban is coupled to iptables * **AppSec/WAF** โ€” HTTP request inspection; fail2ban reads logs only * **Multi-machine** โ€” shared decision database; fail2ban is per-machine ## Who it's for **Good fit:** any internet-exposed server needing more than fail2ban; Traefik Docker stacks; Kubernetes clusters; teams wanting community threat intel without commercial feeds. **Not ideal:** enterprise WAF governance with compliance reporting; air-gapped environments where sharing signals externally is not acceptable. ## My take The community blocklist alone justifies the setup overhead โ€” blocking known attackers proactively is qualitatively different from reacting after they've started. For Traefik Docker stacks, the integration is seamless. The free tier (MIT Security Engine + Community Blocklist) is genuinely useful without any commercial upgrade, and the 200,000+ installation network is a real moat: the more people run it, the better the blocklist gets. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help setting up CrowdSec? Security Engine, Traefik or Nginx bouncer, firewall bouncer, log acquisition config, Hub collections, Console enrollment, Kubernetes DaemonSet โ€” takes experience to configure without gaps in coverage. I handle the full setup and wire it into your existing Docker Compose or Kubernetes infrastructure. Get in touch at pipoline.com โ†’

devopspack.com

n8n is the workflow automation platform for technical teams โ€” 400+ integrations, visual builder plus real code when you need it, native AI agents with human-in-the-loop, and self-hostable under a fair-code license. 197k+ GitHub stars, used by teams who outgrew Zapier.

n8n: Workflow Automation for Teams Who Outgrew Zapier

Zapier works until it doesn't. The moment you need custom data transformation, a non-standard API auth scheme, conditional logic across five branches, or more than a few thousand tasks per month without a bill that scales with volume โ€” you're stuck. Zapier and Make are built for non-technical users making simple connections. n8n is built for developers who want automation power without giving up flexibility. Visual workflow builder for the easy parts, full JavaScript/TypeScript execution for everything else, 400+ native integrations, native AI agent support with human-in-the-loop approvals, and a self-hosted option that keeps your data and costs under control. **197,000+ GitHub stars** โ€” top 50 on all of GitHub. ## What n8n is n8n (pronounced "n-eight-n", short for "nodemation") is a fair-code workflow automation platform. Written in **TypeScript** , built on Node.js. The license is the **Sustainable Use License** โ€” free for self-hosting your own automation, source available, but commercial redistribution requires a commercial license. For teams running it internally: free. n8n GmbH (Berlin) raised a $55M Series B led by Highland Capital โ€” Sequoia's first seed investment in Germany. 100M+ Docker pulls, 200,000+ community members, releases almost daily. Actively developed commercial product with a strong open-source core. ## Visual canvas + Code node Workflows are built on a visual canvas โ€” nodes connected by edges, data flows as JSON. Every node can be tested in isolation: click "Execute Node" to run against real data and inspect the output before wiring it forward. Branching (IF/Switch), merging, looping, waiting, and error handling are first-class primitives. The **Code node** gives you full JavaScript or Python execution with access to workflow data: // Code node โ€” transform data freely const items = $input.all(); return items.map(item => ({ json: { fullName: `${item.json.firstName} ${item.json.lastName}`, domain: item.json.email.split('@')[1], isEnterprise: item.json.plan === 'enterprise' } })); This is the fundamental difference from Zapier. When the pre-built transformation doesn't fit, you write it. No workarounds โ€” just code. ## 400+ integrations Built-in nodes cover: GitHub, GitLab, Jira, Linear, Slack, Discord, Telegram, WhatsApp, Gmail, Outlook, Notion, Airtable, Google Sheets, PostgreSQL, MySQL, MongoDB, Redis, AWS (S3, Lambda, SES, SQS), Stripe, HubSpot, Salesforce, Shopify, and hundreds more. The **HTTP Request node** covers any REST API not in the catalog โ€” full control over headers, auth, body, and pagination. Community nodes: hundreds more available in the registry, installable in one click on self-hosted. Custom nodes built in TypeScript via the n8n node SDK. ## Native AI โ€” agents, RAG, MCP The **AI Agent node** connects to any LLM (OpenAI, Anthropic, Ollama, Mistral, Groq, Gemini) and uses other n8n nodes as tools โ€” database lookups, API calls, code execution โ€” in a ReAct loop. AI agents that actually do things, not just generate text. **Human-in-the-loop approvals** (2026): add a review step on any AI Agent โ†’ tool connection. The agent pauses, sends an approval request via Slack or email, waits, then continues or aborts. The critical safety mechanism for AI agents touching production systems. **MCP support** : n8n works as both an MCP client (calling external MCP tools) and MCP server (exposing n8n workflows as MCP tools to other AI systems). **RAG pipelines** : vector store nodes (Pinecone, Qdrant, Weaviate, pgvector), document loaders, and embedding nodes built in. Full ingest-chunk-embed-store-query pipeline on the canvas. ## Triggers Webhook (any HTTP method, sync or async), Schedule (cron or interval), 100+ native app triggers, Form trigger (renders a UI form), Chat trigger (routes to AI Agent), Email trigger (IMAP/SMTP), and Manual trigger for testing. ## Sub-workflows Complex automations composed via the **Execute Workflow** node โ€” call a sub-workflow with input data, get output back. Build reusable components: "send Slack notification", "lookup customer in CRM", "validate lead" โ€” each maintained independently, called from any parent workflow. ## Docker Compose deployment services: n8n: image: n8nio/n8n:latest restart: unless-stopped ports: - "5678:5678" environment: - N8N_HOST=${N8N_HOST} - N8N_PROTOCOL=https - WEBHOOK_URL=https://${N8N_HOST} - DB_TYPE=postgresdb - DB_POSTGRESDB_HOST=postgres - DB_POSTGRESDB_DATABASE=n8n - DB_POSTGRESDB_USER=n8n - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD} - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY} volumes: - ./n8n-data:/home/node/.n8n depends_on: - postgres postgres: image: postgres:16-alpine restart: unless-stopped environment: POSTGRES_DB: n8n POSTGRES_USER: n8n POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} volumes: - ./postgres-data:/var/lib/postgresql/data Key variables: `N8N_HOST` (your domain), `N8N_ENCRYPTION_KEY` (generate once, keep it โ€” losing this key means losing all saved credentials), `WEBHOOK_URL`. Put Traefik in front for HTTPS. Minimum: 1 CPU, 1GB RAM. For high-volume deployments: queue mode using Redis + multiple worker containers. The main instance handles the UI and triggers; workers pick up execution jobs from the queue and scale horizontally. ## n8n vs Zapier Zapier is the leader for non-technical users โ€” 7,000+ app catalog, simplest onboarding. It charges per task: at 50,000 tasks/month you're paying $299/month. At 100,000 tasks/month, more. n8n self-hosted: $0 for unlimited executions. For teams at volume, the economics are decisive. For teams who need code, n8n's Code node eliminates whole categories of Zapier workarounds. For data sovereignty, everything stays on your infrastructure. Zapier wins on: simplicity for non-developers, the 7,000-app catalog depth, managed reliability with no server to run. ## n8n vs Make Make targets the middle ground โ€” powerful visual scenario building, better than Zapier at complex transformations, cheaper at volume (Core plan $9/month for 10,000 operations). n8n's advantages: real code execution vs Make's limited expression language, better AI/agent capabilities, self-hosting. Make wins on UI polish and non-technical accessibility. ## Who it's for **Good fit:** * Developers and technical teams who want automation power with code when needed * High execution volume where Zapier/Make pricing becomes significant * Data sovereignty requirements โ€” all workflow data on your infrastructure * AI agents that call APIs, query databases, and take real actions * DevOps workflows: GitHub webhooks โ†’ deployments, alerts โ†’ tickets, on-call automation **Not the right fit:** * Non-technical users who need Zapier's simplicity * Teams needing obscure integrations in Zapier's 7,000-app catalog not covered by n8n's 400+ * Organizations that need zero operational overhead โ€” n8n cloud exists but the self-hosted model is the core value ## My take n8n fills a real gap: automation powerful enough for developers, visual enough for non-developers to understand, and self-hostable for data control and cost management. The 197k stars reflect a tool that genuinely solves a problem better than the alternatives for its specific audience. The AI agent capabilities with human-in-the-loop are the most interesting development. Give the agent tools and autonomy, require human confirmation before irreversible actions, connect to MCP servers. This is the right architecture for AI automation: capable but controllable. The fair-code license is a non-issue for internal use โ€” just understand it before building a product on top of n8n. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help setting up n8n? Deploying n8n in production โ€” Docker Compose, PostgreSQL, Traefik for HTTPS, queue mode with Redis workers, credential encryption, webhook config, and building your first automations โ€” takes an afternoon done properly. I can handle the full setup and help migrate workflows from Zapier or Make. Get in touch at pipoline.com โ†’

devopspack.com

Web-Check is the all-in-one OSINT tool for analysing any website โ€” enter a URL and get 40+ data points back instantly: DNS records, SSL chain, open ports, tech stack, HTTP headers, WHOIS, redirect chain, firewall detection, TLS config, and more. MIT, 32k+ stars, self-hostable in one Docker command.

Web-Check: 40+ Website Checks in One OSINT Dashboard

There's a certain routine every developer or ops person goes through when investigating a domain they don't control. First, a WHOIS lookup. Then DNS โ€” dig A, MX, TXT. Then SSL certificate check, probably in the browser. Then curl for headers. Then nmap for ports, maybe. Then Shodan to see what's exposed. Then BuiltWith or Wappalyzer for the tech stack. Each tool is separate, each result is in a different format, and by the time you've correlated everything, ten minutes are gone. Web-Check collapses this entire workflow into one URL input and one dashboard. Enter a domain, get 40+ data points back simultaneously โ€” DNS records, SSL chain analysis, open ports, HTTP security headers, tech stack, WHOIS info, redirect chains, firewall detection, TLS cipher suites, threat intelligence, and more. MIT licensed, 32,000+ GitHub stars, built by Alicia Sykes. Self-host it in one Docker command. ## What Web-Check is Web-Check is an open-source all-in-one OSINT and website inspection tool. Built with **React** (frontend) and **Node.js** serverless functions (backend checks). **MIT licensed**. **32,000+ GitHub stars** at github.com/Lissy93/web-check. Latest release: **v2.1.0** (2026). Available as a live hosted version at web-check.xyz, self-hostable via Docker, deployable to Vercel/Netlify/Railway with one click, or installable as an npm package. It's not a security scanner in the Nessus or Burp Suite sense โ€” it doesn't probe for vulnerabilities or attempt exploitation. It's a passive reconnaissance and information-gathering tool: it queries public data sources, reads publicly accessible headers and records, and presents what any browser or curl command could find, just organized and all at once. ## The checks โ€” what it actually does Web-Check runs 40+ checks in parallel, organized into logical groups: ### Network and DNS * **IP info** โ€” IP address, ASN, hosting provider, organization * **DNS records** โ€” A, AAAA, MX, NS, TXT, CNAME, SOA โ€” all record types at once * **DNS server** โ€” which DNS provider is being used (Cloudflare, Route53, etc.) * **DNSSEC** โ€” whether DNS Security Extensions are properly implemented * **Traceroute** โ€” hop-by-hop path analysis to the server * **Associated hostnames** โ€” other domains resolving to the same IP * **Server location** โ€” geographic location of the hosting server on a map ### Security * **SSL chain** โ€” full certificate chain: validity, issuer, expiration, signature algorithm * **TLS configuration** โ€” protocol versions supported (TLS 1.0/1.1/1.2/1.3), cipher suites, handshake simulation * **HTTP security headers** โ€” Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy * **HSTS** โ€” whether HTTP Strict Transport Security is implemented and configured correctly * **Firewall detection** โ€” Cloudflare, AWS WAF, Akamai, and other WAF detection * **Security.txt** โ€” whether the site publishes a security contact file * **Threat intelligence** โ€” checks against threat intel feeds for malicious activity * **Malware and phishing detection** โ€” Safe Browsing API check * **Block detection** โ€” whether the site is blocked by major filters * **Open ports** โ€” common port scan (80, 443, 21, 22, 25, 8080, etc.) ### Content and technology * **Tech stack** โ€” frameworks, CMS, analytics, CDN, server technology detected from headers and HTML * **Cookies analysis** โ€” cookie names, flags (HttpOnly, Secure, SameSite), and compliance indicators * **HTTP headers** โ€” full raw header dump with analysis * **Crawl rules** โ€” robots.txt content and directives * **Sitemap** โ€” sitemap.xml detection and parsing * **Linked pages** โ€” outbound links from the homepage * **Social tags** โ€” Open Graph and Twitter Card metadata for social sharing previews * **Screenshot** โ€” visual screenshot of the site as it renders ### Domain and performance * **WHOIS** โ€” domain registrar, registration date, expiration, registrant info * **Domain info** โ€” TLD, registrar, domain age * **Redirect chain** โ€” full HTTP redirect chain with status codes at each hop * **TXT records** โ€” SPF, DKIM, DMARC, Google verification, and other TXT record analysis * **Email configuration** โ€” MX records, SPF, DMARC, DKIM setup analysis * **Archive history** โ€” Wayback Machine snapshot history * **Global ranking** โ€” traffic rank estimate * **Server status** โ€” response time and availability * **Lighthouse metrics** โ€” performance, accessibility, SEO scores * **Carbon footprint** โ€” estimated CO2 per page load ## The use cases Web-Check is useful in more situations than you'd initially think: **Security auditing your own sites** โ€” before deploying to production, run Web-Check against the domain. Immediately see if your CSP is missing, if TLS 1.0 is still enabled, if HSTS is properly configured, if security headers are present. Takes 30 seconds instead of running five separate tools. **Investigating suspicious domains** โ€” a link arrives in a phishing report or a suspicious email. Web-Check shows you who hosts it, what ASN it's on, whether it's detected as malicious, what its SSL cert says, whether it shares IPs with known-bad infrastructure. OSINT without leaving a single tool. **Competitive and technical reconnaissance** โ€” understand what tech stack a competitor or client site uses, who hosts them, whether they're behind a CDN, what their certificate setup looks like. All passive, all from public data. **Pre-acquisition due diligence** โ€” buying a domain or acquiring a web property? WHOIS history, archive history, domain age, associated hostnames, email configuration โ€” all in one report. **Debugging infrastructure issues** โ€” DNS misconfiguration, redirect loops, missing security headers, expired certificates. Web-Check surfaces all of these in one pass instead of requiring you to remember which tool checks which thing. **Email deliverability investigation** โ€” SPF, DKIM, DMARC presence and configuration visible at a glance. The email configuration check identifies common misconfigurations that cause deliverability problems. ## Self-hosting The simplest self-hosted deployment is a single Docker command: docker run -p 3000:3000 lissy93/web-check Navigate to `http://localhost:3000` and it's running. For a persistent deployment with Docker Compose: services: web-check: image: lissy93/web-check:latest restart: unless-stopped ports: - "3000:3000" environment: - PORT=3000 # Optional: API keys for enhanced checks # - SECURITY_TRAILS_API_KEY=your_key # - SHODAN_API_KEY=your_key # - GOOGLE_CLOUD_API_KEY=your_key Put Traefik in front for HTTPS and a custom domain. The tool works fully without any API keys โ€” most checks run against public data. Optional API keys enhance some checks: SecurityTrails for more DNS history, Shodan for richer port/exposure data, Google Cloud for Lighthouse and Safe Browsing checks. For one-click cloud deployment, the repo includes buttons for Vercel, Netlify, Railway, and Render โ€” useful if you don't want to run a server but want your own instance rather than using the public web-check.xyz. ## Privacy considerations When using the public hosted version at web-check.xyz, your queried domains are sent to the server. For sensitive investigations โ€” auditing internal infrastructure, researching domains you don't want associated with your IP, competitive intelligence โ€” self-hosting is the right choice. The self-hosted instance makes all queries from your own server's IP, not from a shared Vercel edge or the public web-check.xyz infrastructure. ## Limitations Web-Check is passive reconnaissance โ€” it only reads publicly accessible information. It doesn't probe for application vulnerabilities (SQLi, XSS, authentication bypass), scan for CVEs in running software, or attempt any active exploitation. For that, you need Burp Suite, Nuclei, or a dedicated DAST scanner. Some checks require the server running web-check to have specific tools installed: `chromium` for screenshots and Lighthouse, `traceroute` for traceroute analysis, `dns` utilities for DNS checks. The Docker image includes these; the Vercel deployment skips some checks that require them. The tech stack detection is heuristic-based โ€” it reads headers, HTML patterns, and script sources. It won't identify every technology, particularly custom-built or intentionally obscured stacks. ## Who it's for **Good fit:** * Developers who want a quick, comprehensive view of any domain's public posture * Security engineers running preliminary recon or auditing their own infrastructure * DevOps teams who want a self-hosted internal tool for site health and security checks * Incident responders investigating suspicious domains in phishing reports * Anyone who runs multiple manual checks on domains regularly and wants them in one place **Not the right fit:** * Teams needing active vulnerability scanning โ€” use Nuclei, Burp Suite, or OpenVAS instead * Continuous monitoring at scale โ€” Web-Check is on-demand, not a monitoring platform * Bulk domain analysis โ€” the tool is designed for single-domain inspection, not batch processing ## My take Web-Check is one of those tools that you try once for a specific purpose and then keep reaching for. The value isn't in any single check โ€” you could run each one manually โ€” it's in having all 40+ checks run simultaneously and presented in a clean dashboard. The time savings compound quickly when you're doing this kind of investigation regularly. The self-hosted Docker deployment is trivially easy, and running your own instance makes sense for any serious use: you control what domains you query, from what IP, with no query history on a shared server. The optional API key integration is well thought out โ€” the tool is fully useful without any keys, and the keys just add depth to specific checks rather than being required for basic functionality. 32,000+ GitHub stars for a passive recon tool is a strong signal โ€” this is not niche. Every developer or ops person who discovers it bookmarks it, and most eventually self-host it. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help setting up internal security tooling? Deploying Web-Check and wiring it into your internal toolchain โ€” self-hosted instance behind Traefik, API key configuration for enhanced checks, integration with your existing security workflows โ€” is a quick win. I can also help build out a broader self-hosted security toolkit: Trivy for container scanning, SonarQube for code analysis, and Web-Check for domain reconnaissance, all running on your own infrastructure. Get in touch at pipoline.com โ†’

devopspack.com

Weblate is the open source continuous localization platform that plugs directly into your Git workflow. Translators work in a browser UI, changes commit back to your repo automatically. GPLv3+, used by LibreOffice, Fedora, phpMyAdmin and 2,500+ projects across 165 countries.

Weblate: Continuous Localization That Lives in Your Git Repository

Translation workflows break in predictable ways. Developers export strings to a spreadsheet, translators fill it in, someone re-imports it three sprints later, half the new strings are missing, and the German locale is two versions behind. Every release is a manual reconciliation. Weblate solves this by treating translation as a continuous process integrated with version control. Translators work in a browser, Weblate commits their work back to your Git repository automatically, and you can see translation status across every language at a glance โ€” like CI status on a branch. The spreadsheet disappears. Translation becomes part of the normal development workflow. ## What Weblate is Weblate is an open source web-based localization platform with tight version control integration. Written in **Python** and **Django** , licensed **GPLv3+**. Current release: **2026.6** (June 2026, new calendar versioning). Previously **v5.15.2** (January 2026). Around **4,600+ GitHub stars** , used by **2,500+ projects** across **165+ countries** โ€” including LibreOffice, phpMyAdmin, Fedora, Debian, F-Droid, Kodi, and Tor. Weblate s.r.o. โ€” the company behind it โ€” was incorporated in Czechia in October 2024, giving the project commercial backing while keeping the codebase fully open source. ## Continuous localization model Traditional localization is batch-based: export, translate, import, repeat. Weblate's model is continuous: translations live in your repository alongside the code, synchronized automatically in both directions. When a developer adds a string and pushes to Git, Weblate pulls the change and flags it as needing translation. When a translator submits in the web UI, Weblate commits directly to a branch โ€” or opens a pull request. The repository is always the source of truth. Translators never need Git access. Translation completeness becomes a measurable quality gate in CI. ## Version control integration Supported VCS: Git, GitHub (pull requests), GitLab (merge requests), Gitea/Forgejo, Gerrit, Subversion, Bitbucket. The typical GitHub workflow: Weblate monitors your main branch, creates a `weblate` translation branch, commits translations there, and opens a PR against main when ready. Your normal review process applies โ€” the translation PR goes through CI like any other change. ## File format support Weblate supports virtually every localization format in practical use: * **gettext PO/POT** โ€” standard for open source and Python/Django apps * **JSON** variants โ€” flat, nested, i18next, go-i18n, WebExtension * **XLIFF** โ€” enterprise XML format * **Android strings.xml** and **iOS .strings / .stringsdict** * **Java properties, PHP arrays, Ruby YAML, Qt TS** * CSV, INI, Desktop files, AppStream metadata, and more ## Translation editor and quality checks The web editor shows source string, current translation, translation memory matches, and machine translation suggestions side by side. Built-in quality checks flag automatically: * Missing or extra placeholders (`%s`, `{name}`) * Inconsistent translations of the same source string * Punctuation mismatches, overly long translations, glossary violations * Unchanged translations (possible copy-paste errors) Critical checks block saving; warnings allow saving with a flag. Translations are structurally correct before they land in the repository. ## Machine translation and AI MT integrations as suggestion sources: DeepL, Google Translate, Microsoft Translator, LibreTranslate (self-hosted), OpenAI-compatible APIs, MyMemory, Apertium. MT results appear as suggestions โ€” translators review and accept, reject, or edit. For self-hosted instances, configure LibreTranslate or a local LLM to keep all translation data on your infrastructure. ## Translation memory and glossary **Translation memory** โ€” a database of previously translated string pairs. When a new string resembles something translated before, the memory surfaces it as a suggestion. Particularly valuable when translating new versions where most strings are unchanged. **Glossary** โ€” project-level canonical translations for key terms. When a glossary term appears in a source string, the editor highlights it. Violations are flagged as quality check failures, enforcing consistent terminology across all translators. ## Docker Compose deployment Three containers: Weblate, PostgreSQL, and Valkey (Redis-compatible): services: weblate: image: weblate/weblate:latest restart: unless-stopped ports: - "80:8080" env_file: .env volumes: - ./weblate-data:/app/data depends_on: - database - cache database: image: postgres:16-alpine restart: unless-stopped environment: POSTGRES_DB: weblate POSTGRES_USER: weblate POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} volumes: - ./postgres-data:/var/lib/postgresql/data cache: image: valkey/valkey:8-alpine restart: unless-stopped volumes: - ./valkey-data:/data Key `.env` variables: `WEBLATE_SITE_DOMAIN`, `WEBLATE_ADMIN_EMAIL`, `WEBLATE_ADMIN_PASSWORD`, `WEBLATE_EMAIL_HOST`, `POSTGRES_PASSWORD`. Put Traefik in front for HTTPS. Minimum: 2 CPU, 2GB RAM โ€” 4GB recommended for active projects. ## Projects, components, and Workspaces A **Project** is your application. A **Component** is one translatable resource โ€” typically one file per language. Multiple components per project: UI strings, docs, email templates, each synchronized independently. **Workspaces** (new in 2026.6) group related projects with shared teams and billing โ€” useful for agencies or organizations managing multiple products. ## Weblate vs Crowdin Crowdin is the leading commercial TMS โ€” polished, hosted, no setup. Priced per source word: 100k source words costs $299/month. Weblate self-hosted: $0 + server, unlimited words, unlimited projects, unlimited users. Crowdin wins on ease of getting started and for non-technical teams who shouldn't see Git. Weblate wins for developer teams who want Git-native translation, have data residency requirements, or face per-word pricing at scale. ## Weblate vs Lokalise Lokalise has a strong developer experience โ€” CLI, API, CI/CD integration. Priced per user ($120+/month for a small team). Weblate's Git integration achieves similar CI/CD automation self-hosted. For Git-centric teams, Weblate matches Lokalise's key proposition at a fraction of the cost. ## Who it's for **Good fit:** * Open source projects โ€” Hosted Weblate is **free for libre software** * Dev teams that want translation in the Git workflow: automatic commits, PRs, CI gates * Organizations with data residency requirements * High string volume projects where per-word pricing becomes expensive **Not the right fit:** * Non-technical teams with no Git exposure โ€” VCS model adds overhead * Teams needing deep Figma or CMS integrations โ€” Crowdin/Lokalise cover more * Small one-time translation projects where setup cost isn't justified ## My take Weblate's core insight โ€” that translation should be continuous, Git-native, and visible as a quality metric โ€” is correct. The spreadsheet-based workflow is a solved problem and Weblate solves it well. The 2,500+ project adoption including Fedora and LibreOffice signals it handles real scale. The deployment is genuinely straightforward: three Docker containers, environment variables, Traefik for HTTPS. Python/Django is lighter than Rails. The GPLv3 license means you can deploy it for internal use freely โ€” copyleft conditions only apply if you distribute modified Weblate source to others. For open source projects: use Hosted Weblate, it's free. For commercial teams localizing to multiple languages with volume: self-host and eliminate the per-word bill entirely. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help setting up Weblate? Deploying Weblate โ€” Docker Compose, PostgreSQL, Valkey, Traefik, connecting your Git repository, configuring components and translation workflows, setting up MT integrations, and wiring the translation PR flow into your CI/CD pipeline โ€” takes an afternoon done properly. I can handle the full setup and have your translators working in a browser while commits land automatically in your repo. Get in touch at pipoline.com โ†’

devopspack.com

Chatwoot is the self-hosted alternative to Intercom and Zendesk โ€” omnichannel inbox for live chat, email, WhatsApp, Instagram, Telegram and more, all in one dashboard. MIT-licensed core, Captain AI agent, 34.5k GitHub stars, used by 15,000+ organizations.

Chatwoot: The Self-Hosted Alternative to Intercom and Zendesk

Most businesses end up with a fragmented support stack. Live chat on Intercom at $74/month per seat. Email through a separate helpdesk. WhatsApp handled by whoever checks the company phone. Social media DMs answered days late. No unified view of customer history, no way to hand conversations between agents. Chatwoot is the open-source answer. A single omnichannel inbox that pulls in conversations from live chat, email, WhatsApp, Facebook Messenger, Instagram, Twitter/X, Telegram, Line, and SMS โ€” all in one dashboard, self-hosted on your own infrastructure. The most-starred open-source customer support tool on GitHub, used by 15,000+ organizations, with a Captain AI agent for automating routine queries. ## What Chatwoot is Chatwoot is an open-source omnichannel customer engagement platform. Written in **Ruby on Rails** (backend) and Vue.js (frontend), backed by **PostgreSQL** and **Redis**. The latest stable release is **v4.15.1** (June 2026). It has **34,500+ GitHub stars** and 8,200+ forks โ€” by a wide margin the most-starred open-source customer support tool. The license is **MIT for the core** โ€” nearly everything in a standard self-hosted deployment. A separate commercial license covers the `enterprise/` directory, which adds SAML SSO, custom roles, advanced assignment, and audit logs. For most teams self-hosting, the MIT core covers everything needed. ## Channels โ€” the omnichannel inbox Chatwoot centralizes conversations from: * **Website live chat** โ€” embeddable widget with customizable branding and pre-chat forms * **Email** โ€” connect any inbox via IMAP/SMTP, including Google Workspace and Microsoft 365 * **WhatsApp** โ€” via WhatsApp Business API (Twilio, 360dialog) * **Facebook Messenger** and **Instagram DMs** * **Twitter/X** โ€” mentions and DMs * **Telegram** โ€” via bot token * **Line** โ€” for Japan, Thailand, Taiwan * **SMS** โ€” via Twilio or other providers * **API channel** โ€” custom channels via the Channel API Every incoming message from any channel lands in the shared inbox. Agents respond from within Chatwoot and the reply goes back through the original channel. No switching between apps. ## Collaboration features The shared inbox is where teams actually work. Key features: **Assignments and routing** โ€” conversations assigned to specific agents or teams. Auto-assignment rules route based on channel, label, or round-robin across available agents. **Labels** โ€” tag conversations (Bug, Billing, Urgent) for filtering, reporting, and automation triggers. **Private notes** โ€” internal comments visible only to agents. Use for escalation context without the customer seeing it. **@mentions** โ€” loop in a colleague via private note without reassigning the conversation. **Canned responses** โ€” predefined reply templates. Type `/` in the reply box to search and insert. Saves rewriting the same answers. **Contact management** โ€” CRM-style contact database with full conversation history. Shopify integration pulls in order data directly into the contact panel. ## Captain โ€” AI agent Captain is Chatwoot's built-in AI agent, shipped as a first-class feature since v4.14.0. It handles conversations autonomously using a connected knowledge base, suggests replies for human agents, and summarizes conversation history. On self-hosted, you configure your own LLM endpoint โ€” OpenAI API or any compatible endpoint including self-hosted Ollama. No customer data leaves your server to an AI provider you don't control. ## Automation Automation rules trigger actions based on conversation events and conditions: * New conversation outside business hours โ†’ send offline message, snooze * Conversation labeled "Billing" โ†’ assign to billing team * Conversation open 24h with no reply โ†’ send follow-up * Customer message contains "cancel" โ†’ assign to retention team ## Help Center Integrated knowledge base where you publish FAQs, guides, and docs. Has its own public URL, supports multiple portals (one per brand), and is the knowledge source Captain uses when answering customer questions. Better Help Center = better Captain responses. ## Docker Compose deployment The official self-hosted setup runs Rails + Sidekiq + PostgreSQL + Redis: services: chatwoot_base: &chatwoot_base image: chatwoot/chatwoot:latest env_file: .env volumes: - /data/storage:/app/storage rails: <<: *chatwoot_base depends_on: [postgres, redis] ports: - "3000:3000" command: bundle exec rails s -p 3000 -b 0.0.0.0 sidekiq: <<: *chatwoot_base depends_on: [postgres, redis] command: bundle exec sidekiq -C config/sidekiq.yml postgres: image: postgres:16-alpine environment: POSTGRES_DB: chatwoot POSTGRES_USER: chatwoot POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} volumes: - ./postgres-data:/var/lib/postgresql/data redis: image: redis:alpine volumes: - ./redis-data:/data Key `.env` variables: `SECRET_KEY_BASE`, `POSTGRES_*` credentials, `REDIS_URL`, `FRONTEND_URL`, and SMTP settings. Rails handles the web process; Sidekiq handles background jobs (email processing, webhook delivery, notifications). Put Traefik in front for HTTPS. Minimum requirements: 2 CPU cores, 4GB RAM. Ruby on Rails and Sidekiq together need more memory than a Go binary โ€” budget 8GB for production and consider a dedicated PostgreSQL instance under real load. ## Chatwoot vs Intercom Intercom is the polished, fully-managed market leader. Superior AI, mature integrations, slicker UX, full-time support. It also costs $74/seat/month โ€” a 10-agent team pays $8,880/year before add-ons. The case for Chatwoot: data ownership and cost. With Intercom, your customer conversations live on Intercom's servers under US jurisdiction. With Chatwoot self-hosted, they live on your infrastructure. For teams with GDPR or data residency requirements, this matters. For startups sensitive to their Intercom bill, the math is straightforward. The honest gap: Intercom's product experience is better. The mobile apps are smoother, the integrations deeper, the AI more capable. If budget allows and data sovereignty isn't required, Intercom is legitimately the better product. Chatwoot wins when you want similar functionality under your own control. ## Chatwoot vs Zendesk Zendesk is the enterprise support platform โ€” deep ticketing, SLA management, complex routing, ITSM capabilities. Overkill for most startups and SMBs. Chatwoot covers 80% of what Zendesk does for the most common use case: shared inbox, omnichannel, basic automation, reporting. For organizations paying Zendesk prices for what is essentially a shared inbox problem, Chatwoot is the clear alternative. ## Who it's for **Good fit:** * Startups and SMBs who want omnichannel customer support without Intercom/Zendesk pricing * Organizations with GDPR or data residency requirements where conversation data must stay on their infrastructure * Companies communicating across multiple channels (live chat, WhatsApp, Instagram, email) who need a unified view * Developer-led teams who want to extend the platform via API or customize the open-source codebase **Not the right fit:** * Teams needing formal ITSM workflows (incident management, change management, CMDB) โ€” a dedicated ITSM tool is more appropriate * Organizations without technical staff โ€” Rails + PostgreSQL + Redis + Sidekiq is more complex to operate than a single binary * Very high conversation volume without dedicated infrastructure ops capacity ## My take Chatwoot fills a genuine gap: the space between manually checking five inboxes and paying enterprise SaaS prices for an omnichannel platform. The 34,500+ stars and 15,000+ organization adoption tell a real story โ€” this is production-quality software with an active community. The Captain AI integration with self-hosted LLMs is the most interesting development. Chatwoot plus Ollama gives you AI-assisted customer support with zero data leaving your infrastructure โ€” compelling for organizations that need AI-assisted support but have strict data handling requirements. The operational overhead is real: Ruby on Rails needs more infrastructure than Go. But if you're already comfortable operating Rails, it's a non-issue. If your team is new to Ruby infrastructure, budget time to learn the deployment model before going to production. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help deploying Chatwoot? Setting up Chatwoot in production โ€” Docker Compose, PostgreSQL, Redis, Sidekiq, Traefik for HTTPS, SMTP, connecting your channels, configuring automation rules, and wiring Captain AI to your LLM endpoint โ€” takes experience to get right. I can handle the full setup and have your team handling customer conversations from a single inbox the same day. Get in touch at pipoline.com โ†’

devopspack.com

Metabase is the open source BI tool your non-technical teammates will actually use. Point-and-click dashboards without SQL, a real SQL editor when you need it, Metabot AI for data questions, and a self-hosted setup that takes five minutes. AGPL-3.0, 48k+ stars, used by 50,000+ companies.

Metabase: The BI Tool Your Non-Technical Teammates Will Actually Use

Most BI tools are built for data analysts. You need SQL fluency to write meaningful queries, an understanding of the data model to know what to even ask, and the patience to work through a UI designed by someone who thinks pivot tables are intuitive. The result: the data team becomes a bottleneck, and everyone else makes decisions without data. Metabase is built for everyone else. The product manager who wants to know which signup source drove the most conversions last week. The ops lead who needs a daily view of active orders. The founder who wants to understand churn without submitting a Jira ticket to analytics. Point-and-click questions, interactive dashboards, automated reports, and an AI assistant that answers data questions in plain English โ€” all self-hostable, all free in the Community Edition. ## What Metabase is Metabase is an open source business intelligence and embedded analytics platform. **AGPL-3.0 licensed** , written in Clojure (backend) and React (frontend), with **48,200+ GitHub stars** and **50,000+ companies** using it in production. The latest release is **v0.62.4** (July 2026). It's used by startups for their first analytics dashboard and by large organizations running hundreds of embedded dashboards for customers. The core architecture: Metabase connects directly to your databases โ€” PostgreSQL, MySQL, BigQuery, Snowflake, Redshift, MongoDB, and 20+ more โ€” and lets users ask questions and build dashboards without learning SQL. The application itself stores its configuration (users, dashboards, questions) in an external PostgreSQL or MySQL database. For the data it analyzes, it queries your existing databases directly at question time, without copying data into a separate warehouse. ## The license โ€” AGPL-3.0 with commercial carve-outs Metabase Community Edition is AGPL-3.0. For internal use โ€” your team asking data questions from your own Metabase instance โ€” this has no practical implications. The AGPL copyleft condition activates if you distribute modified Metabase source code over a network to external users. The case that needs attention: embedding Metabase dashboards or charts in a customer-facing SaaS product. If you embed an iframe of Metabase in your product and your application code is modified Metabase code, AGPL requires disclosure. Metabase's commercial license (Pro/Enterprise) removes this restriction and adds SSO, row-level security, and audit logs. For internal analytics โ€” your team using your Metabase โ€” the AGPL Community Edition is genuinely free, forever. ## Visual Query Builder โ€” no SQL required The visual question builder is Metabase's signature feature. Select a table, filter rows, group by a dimension, pick a metric, choose a visualization โ€” done. Metabase generates the SQL, runs it against your database, and shows the result as a bar chart, line graph, number metric, funnel, pivot table, or map. A non-technical user can build: "How many new signups per day over the last 90 days, grouped by acquisition channel, filtered to users who completed onboarding?" โ€” by clicking, not typing SQL. The question builder understands relationships between tables if you've told Metabase about your data model, so it can auto-join across tables without the user knowing they exist. What makes this actually work for non-technical users: * **Drilldown** โ€” click any bar in a chart to filter to that segment and see underlying data * **Field definitions** โ€” annotate columns with friendly names, descriptions, and units so "mrr_usd" shows as "Monthly Recurring Revenue ($)" * **Segments and metrics** โ€” define reusable filters ("Active users", "Churned customers") that everyone can use without knowing the underlying query logic * **X-ray** โ€” automatic exploratory analysis of any table or segment with generated charts and insights ## SQL editor For data engineers and analysts who need full SQL control, the native query editor provides syntax highlighting, auto-complete, query history, and the ability to use the results of a SQL query as the basis for further visual analysis. You can write a complex CTE in SQL and then build a visual chart on top of its output โ€” combining both modes in a single workflow. SQL questions can be turned into dashboards alongside visual questions, shared with the team, and added to subscriptions โ€” there's no second-class treatment for SQL users. ## Dashboards Metabase dashboards support interactive filters that apply across all cards, auto-refresh for live data monitoring, fullscreen mode for TV displays, click behavior that drills into other dashboards or external URLs, and custom layouts. Dashboard subscriptions let you schedule a PDF export to be delivered by email or Slack on a recurring basis. The permission system controls which users or groups can see which dashboards and which data. Collections organize content into folders with their own permission sets โ€” the Engineering collection, the Finance collection, the executive dashboard โ€” each visible only to the right people. ## Metabot โ€” AI for data Metabot is Metabase's built-in AI assistant, available in the Pro/Enterprise plans. Ask "Which plan drives the most revenue?" or "How did total accounts grow last year?" in plain English and Metabot returns an answer with a visualization, explains its reasoning, and can be prompted to refine the analysis. It's backed by whatever LLM provider you configure โ€” OpenAI, Anthropic, or your own hosted model. For teams that have invested in defining their data model well in Metabase (field descriptions, metrics, segments), Metabot can produce reliable answers because it's working from a curated semantic layer rather than raw schema inference. For poorly documented schemas, the AI answers reflect that quality. ## Data Studio Metabase's Data Studio is the semantic layer and data management area. It lets you define: * **Metrics** โ€” canonical definitions of KPIs ("Active MRR", "Churned Users") that everyone uses consistently * **Segments** โ€” reusable filter groups ("Enterprise customers", "Trial users in EMEA") * **Field metadata** โ€” display names, descriptions, data types, and relationship information * **Data visibility** โ€” hide internal columns (password_hash, API keys) from non-admin users This metadata layer is what separates a useful Metabase deployment from a confusing one. Investing an afternoon in Data Studio documentation means non-technical users can self-serve accurately rather than building questions on raw system columns they don't understand. ## Embedded analytics Metabase can embed charts and dashboards directly in your own application via iframes (signed embed) or the JavaScript SDK. This is particularly useful for SaaS products that want to give customers a reporting view of their own data. The embedding model supports multi-tenant isolation โ€” each customer sees only their own data โ€” and the "Powered by Metabase" branding can be removed with a commercial license. ## Database connectors Official connectors: PostgreSQL, MySQL, MariaDB, SQLite, Microsoft SQL Server, Oracle, Google BigQuery, Amazon Redshift, Snowflake, MongoDB, Presto/Trino, Apache Spark, Druid, and more. If your database speaks SQL or has a JDBC driver, it can connect to Metabase. Multiple databases can be connected simultaneously โ€” finance questions query BigQuery, product questions query PostgreSQL, all from the same Metabase instance. ## Self-hosting Metabase The fastest start is a single Docker command: docker run -d -p 3000:3000 --name metabase metabase/metabase This starts Metabase with an H2 database for application data โ€” fine for testing, not for production. For production, use PostgreSQL: services: metabase: image: metabase/metabase:latest restart: unless-stopped ports: - "3000:3000" environment: MB_DB_TYPE: postgres MB_DB_DBNAME: metabase MB_DB_PORT: 5432 MB_DB_USER: metabase MB_DB_PASS: ${MB_DB_PASS} MB_DB_HOST: db depends_on: - db db: image: postgres:16-alpine restart: unless-stopped environment: POSTGRES_DB: metabase POSTGRES_USER: metabase POSTGRES_PASSWORD: ${MB_DB_PASS} volumes: - ./postgres-data:/var/lib/postgresql/data Put Traefik in front for HTTPS. Navigate to your domain, complete the setup wizard, connect your first database, and create your first dashboard. Minimum requirements: 2 CPU cores, 2GB RAM. The Java/Clojure runtime is heavier than Go or Rust โ€” budget 1.5-2GB for the Metabase process itself. One critical production note: run the setup wizard to completion immediately after first boot, before anyone else accesses the instance. The first user to complete setup becomes the admin. ## Metabase vs Superset These are the two dominant open source BI options and the comparison that comes up most often. **Ease of use** โ€” Metabase wins, clearly. The visual question builder is genuinely more accessible to non-technical users. Superset has a steeper learning curve and is more oriented toward data engineers and analysts. **Self-hosting complexity** โ€” Metabase wins. One Docker container + PostgreSQL. Superset requires Redis, Celery workers, a metadata database, and more configuration to get right. **Visualization flexibility** โ€” Superset wins. More chart types, more configuration options, and an integrated SQL Lab that's more powerful. If you need precise control over chart appearance, Superset gives it. **Semantic layer** โ€” Comparable. Metabase's Data Studio provides metrics, segments, and field metadata. Superset has dataset-level definitions. Neither is as powerful as dbt Semantic Layer or LookML. **Embedded analytics** โ€” Metabase wins for the Community Edition use case. Superset's embedding story is more complex to implement. **License** โ€” Both AGPL-3.0. Same internal use implications apply to both. ## Metabase vs Grafana Grafana is primarily an observability and infrastructure monitoring tool โ€” time-series data, metrics from Prometheus/InfluxDB, infrastructure dashboards. Metabase is a business intelligence tool โ€” user data, financial metrics, product analytics from relational databases. They serve different use cases. If you're monitoring your Kubernetes cluster, use Grafana. If you're answering business questions from PostgreSQL, use Metabase. Many teams run both. ## Metabase vs Tableau / Power BI Tableau and Power BI are enterprise BI platforms with the deepest feature sets in the market โ€” sophisticated calculated fields, complex blending from multiple sources, hundreds of visualization types, enterprise governance, and large consultant ecosystems. They're also expensive: Tableau Creator is $75/user/month; Power BI Premium is $4,995/month for a dedicated capacity. Metabase Community Edition self-hosted: $0 + server costs. For teams where the primary use case is "non-technical users asking ad-hoc questions from our production database," Metabase covers 80% of the Tableau use case at 0% of the cost. The 20% it misses is the enterprise governance, advanced calculated fields, and cross-source blending that large organizations need โ€” and which justify Tableau's price for those organizations. ## Who it's for **Good fit:** * Startups and SMBs who want "everyone can answer data questions" without a dedicated data team * Teams with a PostgreSQL, MySQL, or BigQuery database who want dashboards without a data warehouse * Engineering teams who want to give ops, product, and business stakeholders self-service data access * Organizations with data residency requirements who need BI on their own infrastructure * SaaS products that want to embed customer-facing analytics (with commercial license for multi-tenant) **Not the right fit:** * Teams that need row-level security on the free tier โ€” that requires Pro ($500+/month) * Organizations with complex multi-source data blending needs โ€” Tableau or Power BI are more powerful * High-volume analytics on very large datasets without a data warehouse โ€” Metabase queries your production database directly, which can stress it * Teams embedding Metabase in a customer-facing product without a commercial license โ€” the AGPL has implications for that use case ## My take Metabase is the best answer to "we need dashboards and our team can't write SQL." That's a real problem in most organizations โ€” data is in a database, questions go unanswered because nobody wants to bother the data team, and decisions get made on intuition. Metabase solves that gap better than anything else in the open source space, and for internal use, it's genuinely free. The five-minute setup claim is real โ€” one Docker command and a setup wizard. The hard part isn't deploying Metabase; it's the Data Studio work to document your schema well enough that non-technical users build accurate questions. That investment pays off every time a PM answers their own question without filing a Jira ticket. The Superset comparison depends on your team. If your primary users are data engineers and analysts who want maximum flexibility, Superset. If your primary users are non-technical business stakeholders who need guided self-service, Metabase. The 48,000+ GitHub stars and 50,000+ company adoption reflect how well Metabase nails the second use case. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help setting up Metabase for your team? Deploying Metabase in production โ€” Docker Compose, PostgreSQL for the application database, Traefik for HTTPS, connecting your data sources, configuring permissions, documenting your data model in Data Studio, and building your first dashboards โ€” takes an afternoon done properly. I can handle the full setup and have your team answering data questions the same day. Get in touch at pipoline.com โ†’

devopspack.com

Trivy and SonarQube are both essential DevSecOps tools โ€” but they scan different things. Trivy finds CVEs in containers, dependencies, and IaC. SonarQube finds bugs, code smells, and security hotspots in your source code. Here's what each does, where they overlap, and why serious teams run both.

Trivy vs SonarQube: Two Security Tools That Belong in the Same Pipeline

If you ask a DevOps engineer "should I use Trivy or SonarQube?" you'll often get a confused look. The question assumes they're competing for the same job. They're not. Trivy scans what you deploy โ€” container images, filesystems, infrastructure-as-code โ€” for known vulnerabilities. SonarQube scans what you write โ€” source code โ€” for bugs, security flaws, code smells, and technical debt. Most teams that take security seriously eventually run both. This post covers what each tool does, where they overlap, how to deploy each, and when running both makes sense. ## Trivy โ€” scanning what you deploy Trivy is an open-source security scanner by Aqua Security. It's the most-starred open-source security scanner on GitHub with **36,500+ stars** , under **Apache 2.0** , and the current stable release is **v0.71.0** (June 2026). It's the default scanner in Harbor, RedHat certified, and used by default in countless CI/CD pipelines. The core design: a single Go binary with no agents, no database to manage, no server to run. Point it at a target, get results. The vulnerability database downloads and caches automatically (~50MB), updated every six hours from NVD, OS vendor advisories, and language-specific advisories. ### What Trivy scans Trivy covers eight target types with four scanner engines: **Targets:** container images (Docker, OCI), filesystems, Git repositories, VM images (AWS AMI, Azure VM), Kubernetes clusters, and SBOMs. **Scanner engines:** * **Vulnerabilities** โ€” OS packages (Alpine, Debian, Ubuntu, RHEL, Amazon Linux) and application dependencies (Python, npm, Go modules, Java, Rust, PHP, Ruby) * **Misconfigurations** โ€” IaC files: Terraform (absorbed tfsec in 2023), CloudFormation, Kubernetes YAML, Dockerfiles, Helm charts * **Secrets** โ€” hardcoded API keys, passwords, tokens in code and config files * **Licenses** โ€” open source license compliance across dependencies ### Trivy in CI/CD The most common pattern: scan every image build and fail the pipeline on CRITICAL or HIGH findings: # Scan a container image trivy image --severity HIGH,CRITICAL --exit-code 1 myapp:latest # Scan a filesystem (source code + dependencies) trivy fs --severity HIGH,CRITICAL --exit-code 1 . # Scan IaC files trivy config --severity HIGH,CRITICAL ./terraform/ # Scan a running Kubernetes cluster trivy k8s --report summary cluster # Generate an SBOM trivy image --format cyclonedx --output sbom.json myapp:latest In GitHub Actions: - name: Scan image with Trivy uses: aquasecurity/trivy-action@master with: image-ref: myapp:latest format: sarif output: trivy-results.sarif severity: HIGH,CRITICAL exit-code: 1 Trivy also ships a Kubernetes Operator (via Helm) for continuous cluster scanning โ€” it runs as a controller, scans workloads, and stores results as Kubernetes CRDs you can query or surface in a dashboard. ### What Trivy is NOT Trivy doesn't analyze your source code logic. It won't find SQL injection, XSS, or logic bugs in your application code โ€” it finds CVEs in packages and misconfigurations in IaC. It doesn't track code quality, technical debt, or test coverage. These are not gaps; they're design choices for a different scope. ## SonarQube โ€” scanning what you write SonarQube is an open-core code quality and SAST platform by SonarSource, used by 7 million+ developers at organizations including Snowflake, Deutsche Bank, and Ford. The free tier is **Community Build** (LGPL-3.0, ~10,700 GitHub stars), covering 20+ languages. Commercial editions add branch analysis, taint analysis, PR decoration, and more. Current release: **SonarQube Server 2026.2** (March 2026). Where Trivy scans build artifacts and infrastructure, SonarQube scans source code. It performs static analysis โ€” reading your code without executing it โ€” to find bugs, security hotspots, code smells, duplications, and maintainability issues. ### What SonarQube analyzes * **Bugs** โ€” code that will likely cause runtime failures: null dereferences, resource leaks, incorrect API usage * **Security hotspots** โ€” code that might be a vulnerability and needs human review * **SAST** โ€” actual security vulnerabilities: SQL injection, XSS, insecure deserialization (paid tiers add taint analysis for cross-method data flow tracking) * **Code smells** โ€” maintainability issues: overly complex methods, duplicated code, poor naming, technical debt * **Secrets detection** โ€” 400+ patterns for API keys, passwords, tokens committed in code * **Coverage** โ€” test coverage integration to enforce minimum thresholds * **Duplications** โ€” copy-pasted code across the codebase ### Quality Gates SonarQube's most powerful CI/CD integration feature is the Quality Gate โ€” a pass/fail check with configurable conditions. Define: "fail if new code has any CRITICAL security hotspot, or coverage drops below 80%, or technical debt ratio exceeds 5%." The gate blocks merges when conditions aren't met. # sonar-project.properties sonar.projectKey=myapp sonar.sources=src sonar.tests=test sonar.coverage.exclusions=**/*.test.js sonar.host.url=https://sonar.example.com ### Self-hosting SonarQube SonarQube Community Build runs on Docker Compose with PostgreSQL. Note: it requires Elasticsearch internally, which needs `vm.max_map_count` set on the host: sudo sysctl -w vm.max_map_count=524288 services: sonarqube: image: sonarqube:community depends_on: - db environment: SONAR_JDBC_URL: jdbc:postgresql://db:5432/sonarqube SONAR_JDBC_USERNAME: sonar SONAR_JDBC_PASSWORD: ${SONAR_PASSWORD} ports: - "9000:9000" volumes: - sonarqube_data:/opt/sonarqube/data - sonarqube_extensions:/opt/sonarqube/extensions db: image: postgres:16 environment: POSTGRES_USER: sonar POSTGRES_PASSWORD: ${SONAR_PASSWORD} POSTGRES_DB: sonarqube Minimum requirements: 2 CPU cores, 4GB RAM (Elasticsearch is hungry). This is significantly heavier than Trivy's single binary with no server. ### What SonarQube is NOT SonarQube doesn't scan container images for CVEs. It doesn't check OS packages or application dependency vulnerabilities (that's CVE scanning โ€” Trivy's domain). The Community Build doesn't include taint analysis (cross-method data flow) or PR decoration โ€” those require paid editions. ## Where they overlap There is genuine overlap in two areas, worth understanding before choosing: **Secrets detection** โ€” both tools detect hardcoded secrets. Trivy's secrets scanner finds secrets in container images, filesystems, and Git repos. SonarQube's secrets detection (in Server editions) finds secrets in source code with 400+ patterns. If you're running both, you get double coverage โ€” which is fine, but don't assume one replaces the other. **IaC security** โ€” Trivy's misconfiguration scanner checks Terraform, CloudFormation, and Kubernetes manifests for security issues. SonarQube (paid) also analyzes IaC files. For open source setups, Trivy covers this; SonarQube Community focuses on application code. **Dependency vulnerabilities** โ€” Trivy scans manifest files (package.json, requirements.txt, go.sum) for known CVEs. SonarQube Advanced Security (paid add-on, 2025) added SCA for dependency vulnerability detection. In practice for free tiers: Trivy is the dependency CVE scanner; SonarQube focuses on code quality. ## Trivy vs SonarQube โ€” side by side Capability| Trivy| SonarQube Community ---|---|--- Container image CVEs| Yes โ€” core use case| No OS package vulnerabilities| Yes| No App dependency CVEs| Yes (manifest scan)| No (paid: SCA) IaC misconfigurations| Yes (Terraform, K8s, CF)| Limited (paid) Source code SAST| No| Yes โ€” core use case Code bugs and smells| No| Yes Taint analysis| No| Paid editions only Secrets in code| Yes| Yes (paid) Quality Gates for CI/CD| Via --exit-code flag| Yes โ€” mature gating SBOM generation| Yes (CycloneDX, SPDX)| Paid add-on License| Apache 2.0| LGPL (Community) Deployment| Single binary, no server| Docker + PostgreSQL, 4GB RAM CI/CD integration| Binary + Actions| SonarScanner + Quality Gate ## When to use each **Use Trivy if:** * You need to scan container images for CVEs before deployment * You want fast, zero-infrastructure security scanning in CI/CD * You're scanning IaC (Terraform, Kubernetes YAML) for misconfigurations * You need SBOM generation as part of supply chain security * You want a single binary that scans images, filesystems, and code repos **Use SonarQube if:** * You want to enforce code quality standards (coverage, duplications, technical debt) * You need SAST on source code โ€” SQL injection, XSS, insecure patterns * You want Quality Gates blocking PRs that degrade code quality * Your team needs a persistent dashboard of code health over time * You need compliance reporting (OWASP, CWE, NIST SSDF) **Use both:** For any team serious about DevSecOps in 2026, the honest answer is both. Trivy gates deployment on known CVEs; SonarQube gates merges on code quality and security patterns. They operate at different points in the pipeline and catch different classes of problems. The overlap (secrets, IaC) is additive, not redundant. ## A practical DevSecOps pipeline A complete open source security scanning pipeline using both tools: # Stage 1: Code commit โ€” SonarQube in CI - Run SonarScanner on source code - Quality Gate blocks merge if: CRITICAL security hotspot, coverage < 80% # Stage 2: Image build โ€” Trivy on the artifact - trivy image --severity HIGH,CRITICAL --exit-code 1 myapp:$TAG - Fails build if image has unfixed critical CVEs # Stage 3: IaC โ€” Trivy on config - trivy config --severity HIGH,CRITICAL ./terraform/ - trivy config ./kubernetes/ # Stage 4: Continuous โ€” Trivy Operator in cluster - Trivy Operator scans running workloads continuously - Results stored as Kubernetes CRDs, surfaced in dashboard This pipeline covers: code quality and SAST (SonarQube), container CVEs and IaC misconfigs (Trivy at build), and continuous cluster posture (Trivy Operator). ## My take The "Trivy vs SonarQube" framing is a false choice that comes from treating security scanning as a monolithic concern. They're different tools for different layers: Trivy operates at the infrastructure and artifact layer (what runs in production), SonarQube operates at the source code layer (what developers write). If budget and complexity allow only one: start with Trivy. A single binary, no server, no maintenance overhead, and scanning every container image before deployment for known CVEs is the highest-ROI security investment most teams can make. Then add SonarQube's Community Build when you want to enforce code quality and catch security patterns at the source. Trivy is operationally free to run. SonarQube Community Build is also free but carries the overhead of a PostgreSQL + Elasticsearch stack. Both are worth it. Most mature DevOps teams run both โ€” they just didn't frame it as a choice. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help setting up a DevSecOps scanning pipeline? Wiring Trivy and SonarQube into your CI/CD pipeline โ€” GitHub Actions, GitLab CI, or Jenkins โ€” configuring Quality Gates, setting appropriate severity thresholds, deploying the Trivy Operator in Kubernetes, and self-hosting SonarQube Community Build โ€” takes experience to get right without generating alert fatigue. I can handle the full setup for your stack. Get in touch at pipoline.com โ†’

devopspack.com

Zot is the OCI-native container registry that does exactly one thing: store and distribute container images and OCI artifacts, purely according to the OCI Distribution Specification. Single binary, no runtime dependencies, built-in auth, Cosign support, CNCF Sandbox. Here's why it beats registry:2.

Zot: The OCI-Native Container Registry That Replaces registry:2

Every team running containers eventually needs a private registry. The default answer is `registry:2` โ€” Docker's official registry image. It works. It's also showing its age: no UI, no vulnerability scanning, no garbage collection, no OCI artifact support. Zot is the modern answer. It's an OCI-native container registry built purely on OCI standards โ€” not Docker's proprietary format, just the OCI Distribution Specification and OCI Image Format, faithfully implemented. Single Go binary, no runtime dependencies, built-in authentication, and native support for everything the OCI ecosystem produces: container images, Helm charts, SBOMs, Cosign signatures, and arbitrary OCI artifacts. ## What Zot is Zot is a production-ready, vendor-neutral OCI image registry. Written in Go, **Apache 2.0 licensed** , **CNCF Sandbox** since December 2022. Latest stable: **v2.1.18** (June 2026). 2,500+ GitHub stars at github.com/project-zot/zot. The design philosophy: store images in OCI image format, serve via OCI Distribution Specification, add only what's needed to make it production-ready. No proprietary wire format, no vendor lock-in, no Docker daemon dependency. ## Why OCI-native matters The classic `registry:2` was built around Docker's own image format, later extended for OCI. Zot was built for OCI from the start โ€” no Docker legacy, no compatibility shims. This matters because OCI registries now store far more than container images: * **Container images** โ€” Docker and OCI format * **Helm charts** โ€” pushed and pulled with `helm push/pull` * **Cosign signatures** โ€” image signing via Sigstore, stored as OCI referrers * **SBOMs** โ€” Software Bill of Materials attached as OCI artifacts * **ML models** โ€” versioned distribution via OCI * **Arbitrary files** โ€” via ORAS (OCI Registry As Storage) Zot supports OCI referrers natively โ€” the mechanism Cosign uses to attach signatures and SBOMs to images. An image and all its metadata live together and are queryable via the standard referrers API. ## Core features ### Single binary, no dependencies Statically compiled Go binary, no external runtime dependencies. No Docker daemon, no Java, no separate database. Download, write a JSON config, run it. Works on Linux, macOS, ARM โ€” including Raspberry Pi and edge hardware. ### Built-in authentication and authorization HTTP Basic Auth (htpasswd), LDAP, OAuth2/OIDC (Keycloak, Authentik, Dex), and Bearer tokens โ€” all handled without a sidecar. Per-repository authorization policies defined in the config file. ### Storage backends Local filesystem by default (images stored in OCI layout format, directly inspectable). S3-compatible object storage (AWS S3, MinIO, Ceph) and GCS for production deployments. ### Image replication Sync images from upstream registries โ€” Docker Hub, GHCR, other Zot instances โ€” either on-demand (pull-through cache) or scheduled. Essential for air-gapped environments. ### Vulnerability scanning Trivy integration for CVE scanning. Results accessible via API and visible in the zui web interface. ### Garbage collection and deduplication Shared layers stored once across images. Automatic cleanup of unreferenced blobs and manifests. A CI/CD pipeline pushing images continuously won't fill your disk. ## Docker Compose deployment services: zot: image: ghcr.io/project-zot/zot-linux-amd64:latest container_name: zot restart: unless-stopped ports: - "5000:5000" volumes: - ./config.json:/etc/zot/config.json:ro - ./data:/var/lib/registry command: ["serve", "/etc/zot/config.json"] Put Traefik in front for HTTPS and TLS termination. A minimal config.json: { "distSpecVersion": "1.1.0", "storage": { "rootDirectory": "/var/lib/registry" }, "http": { "address": "0.0.0.0", "port": "5000" }, "log": { "level": "info" }, "extensions": { "search": { "enable": true }, "metrics": { "enable": true }, "scrub": { "enable": true } } } ## Supply chain security โ€” Cosign and SBOMs Cosign stores image signatures as OCI referrers โ€” attached to the image manifest via the referrers API. Zot supports this natively: # Push, sign, and verify docker push registry.example.com/myapp:latest cosign sign --key cosign.key registry.example.com/myapp:latest cosign verify --key cosign.pub registry.example.com/myapp:latest # Attach SBOM cosign attach sbom --sbom sbom.json registry.example.com/myapp:latest # Query referrers curl https://registry.example.com/v2/myapp/referrers/sha256:abc123... The image, its signature, and its SBOM all live together in Zot, addressable through standard OCI APIs. ## Zot vs alternatives **vs registry:2** โ€” simpler to set up but lacks OCI artifact support, no built-in auth (needs Nginx proxy for htpasswd), no UI, no vulnerability scanning, no referrers API. Zot is the direct upgrade path. **vs Harbor** โ€” Harbor (CNCF Graduated) is more feature-complete: full UI, RBAC, project-based organization, audit logs. It's also eight containers vs one binary. Pick Harbor for enterprise governance; pick Zot for minimal operational overhead. **vs ECR / GAR / GHCR** โ€” managed cloud registries have zero operational overhead and cloud-native integrations. Zot is the right choice when data sovereignty, air-gap requirements, or cost at scale make managed registries unsuitable. **vs Nexus / Artifactory** โ€” universal artifact repositories that support Docker alongside Maven, npm, PyPI. Zot is purpose-built for OCI and far simpler for teams that only need container and OCI artifact storage. ## Who it's for **Good fit:** * Teams running private registries who want more than registry:2 without Harbor's complexity * Air-gapped environments that mirror public registries and serve images internally * Organizations building supply chain security with Cosign and SBOMs * Teams storing Helm charts, WASM modules, ML models as OCI artifacts * Edge deployments needing a lightweight registry on modest hardware **Not the right fit:** * Teams needing Harbor's enterprise RBAC and project-based organization * Organizations needing Maven, npm, PyPI alongside containers โ€” Nexus/Artifactory instead * Teams already happy with a managed cloud registry and no air-gap requirements ## My take Zot is the registry I'd run for any team that has outgrown registry:2 and doesn't need Harbor's full complexity. The single-binary deployment is genuinely low maintenance โ€” no Postgres, no Redis, no eight-container compose stack. It handles the OCI ecosystem correctly, including referrers for Cosign signatures and SBOMs, which means it grows with supply chain security tooling rather than forcing workarounds. The CNCF Sandbox backing and active development give it credibility. It won't replace Harbor for enterprise environments that need Harbor's governance features. But for the large middle ground โ€” engineering teams running a private registry for CI/CD and internal image distribution โ€” Zot's operational simplicity and OCI correctness make it a better default than what most teams currently run. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help setting up a private container registry? Deploying Zot โ€” configuration, TLS via Traefik, OIDC authentication, replication from public registries, Cosign integration, and wiring it into your CI/CD pipeline โ€” takes an afternoon done properly. I can handle the full setup and integrate it with your existing infrastructure. Get in touch at pipoline.com โ†’

devopspack.com

FoundationDB is the distributed database Apple built iCloud on. ACID across distributed machines, a layers architecture for any data model, and a simulation testing framework that finds bugs other databases never discover. Apache 2.0, 16,400+ stars, v7.3.77.

FoundationDB: The Distributed Database That Apple Built iCloud On

Most distributed databases make you choose between consistency and scale. Cassandra gives you scale but eventual consistency. MongoDB gives you flexible documents but unreliable transactions. FoundationDB is built on the premise that this trade-off is wrong. It delivers strict serializability โ€” the strongest form of transactional isolation โ€” across a distributed cluster at the performance levels Apple needs to run iCloud. ## What FoundationDB is FoundationDB is a distributed, transactional, ordered key-value store. Apache 2.0 licensed, owned and maintained by Apple (open sourced 2018), with 16,400+ GitHub stars. Latest stable: 7.3.77 (April 2026). Linux for production, macOS/Windows for local development. Who uses it in production: Apple runs iCloud metadata and CloudKit on it (hundreds of millions of devices). Snowflake used it for metadata storage as documented in their SIGMOD paper. CouchDB is rebuilding its storage layer on FDB. These are not toy workloads. ## The unbundled architecture Most databases bundle a storage engine, data model, and query language. FDB separates these completely. The core does one thing: ordered, transactional key-value storage with strict serializability. Everything else is a layer โ€” a stateless application that maps a higher-level data model to key-value transactions. One FDB cluster can simultaneously run a document store layer, a graph layer, and a relational records layer, with full ACID across all of them. Official layers include the Record Layer (relational semantics for CloudKit), Document Layer (MongoDB wire protocol), and JanusGraph backend. ## ACID across distributed machines FDB achieves strict serializability using optimistic concurrency control (OCC) combined with MVCC. Each transaction gets a read version โ€” a consistent snapshot. Reads acquire no locks and never block writes. At commit, the system checks for concurrent changes to data the transaction touched. Conflict: retry. No conflict: atomic commit across all machines involved. Deadlocks are impossible. Slow clients cannot block others. FDB tolerates f failures with only f+1 replicas (vs 2f+1 for quorum systems) โ€” a meaningful efficiency gain at cluster scale. ## The simulation testing framework This is what makes FoundationDB remarkable โ€” worth understanding even if you never deploy it. Before writing database code, the team built a deterministic simulation framework. It runs an entire cluster โ€” networking, disk I/O, clocks, random number generators โ€” as a single-threaded process. Every source of nondeterminism is controlled. Same random seed means same sequence of events, making test runs fully reproducible. The simulator injects arbitrary failure combinations: five machines failing simultaneously during a commit, network partitions between specific components, disk failures in sequence. It fast-forwards the clock between events, so one test machine simulates years of cluster operation in hours. Distributed systems bugs that only appear after specific failure sequences are found in simulation before production. This is why Apple trusted FDB with iCloud and why Snowflake's engineers described it as the only database they trusted enough to build Snowflake on. The SIGMOD paper documenting this approach is required reading for anyone working on distributed systems. ## Architecture overview FDB separates control plane (cluster management) from data plane (reads/writes). The data plane components: Sequencer (assigns read and commit versions), Proxies (transaction entry point, batch commits), Resolvers (detect conflicts between concurrent transactions), Log servers (write-ahead log โ€” durability before storage is updated), and Storage servers (serve reads, hold the actual data). The key architectural decision: logging is decoupled from storage. Log servers and storage servers scale independently. Transaction processing (Sequencer, Proxies, Resolvers) is stateless and easily replaceable. Recovery is simplified โ€” a failed node is replaced by a fresh one that replays from the log. ## Getting started Install on Ubuntu (production-ready single-node for development): wget https://github.com/apple/foundationdb/releases/download/7.3.77/foundationdb-clients_7.3.77-1_amd64.deb wget https://github.com/apple/foundationdb/releases/download/7.3.77/foundationdb-server_7.3.77-1_amd64.deb sudo dpkg -i foundationdb-clients_7.3.77-1_amd64.deb sudo dpkg -i foundationdb-server_7.3.77-1_amd64.deb Python client example โ€” ACID transfer between two accounts: import fdb fdb.api_version(730) db = fdb.open() @fdb.transactional def transfer(tr, from_key, to_key, amount): balance_a = int(tr[from_key]) balance_b = int(tr[to_key]) if balance_a < amount: raise Exception("Insufficient funds") tr[from_key] = str(balance_a - amount).encode() tr[to_key] = str(balance_b + amount).encode() transfer(db, b'alice', b'bob', 100) The @fdb.transactional decorator automatically retries the transaction on conflict. The application code sees a simple function call; conflict resolution is transparent. ## Honest limitations **5-second transaction limit:** Transactions cannot run longer than five seconds. OLAP, analytics, and long-running bulk operations that need to hold read snapshots don't fit this model. FDB is designed for OLTP, not OLAP. **No built-in query language:** The core has no SQL, no query optimizer, no secondary indexes. These are provided by layers. If you need them without building a layer, you use the Record Layer or another layer. **Operational complexity:** A production cluster requires understanding all five server roles, capacity planning, and careful configuration. This is not a docker compose up deployment for production. **Apple-governed project:** Development happens primarily inside Apple, with community contributions accepted but the roadmap driven by Apple's internal needs. Less community-governed than PostgreSQL or etcd. ## FoundationDB vs alternatives vs etcd: etcd targets small cluster configuration data. FDB scales to petabytes and millions of transactions per second. They serve fundamentally different scale ranges. vs Cassandra / DynamoDB: These sacrifice strict consistency for availability. FDB wins on correctness; Cassandra wins on write availability under network partitions. Pick based on whether your application can tolerate eventual consistency. vs CockroachDB / Spanner: The closest peers. CockroachDB is a complete distributed SQL database built on a Paxos-replicated key-value layer. FDB provides the transactional foundation without a query language โ€” more primitive and more flexible. Use CockroachDB for distributed PostgreSQL-compatible SQL; use FDB when building a new system that needs to choose its own data model. vs PostgreSQL: When you have outgrown single-node PostgreSQL and need truly distributed transactions across multiple machines, FDB is the open source answer. ## Who it is for Good fit: teams building distributed platform infrastructure where correctness is non-negotiable; organizations that have outgrown single-node databases but want transactions rather than eventual consistency; platform teams building higher-level data services on a reliable transactional foundation; multi-model data systems that want one transactional store backing multiple data models. Not the right fit: teams needing a ready-to-use SQL database (use PostgreSQL or CockroachDB); OLAP and analytics workloads; most web application stacks where the operational overhead is not justified; small teams without distributed systems expertise. ## My take FoundationDB is the most intellectually interesting database in this blog series. The simulation testing framework is worth studying even if you never deploy it โ€” it is the most rigorous distributed systems testing approach that any production database has shipped, and the reason Apple trusted it with iCloud at scale. The unbundled architecture reframes the question that most database debates ask. Instead of which database, FDB asks what is the correct transactional primitive to build everything else on. One small, correct, well-tested core. All data models as layers on top. This is compelling if you are building the infrastructure that other applications run on, not an application itself. Operational complexity and the 5-second limit rule it out for most web stacks. But for platform teams at the scale where these trade-offs matter, FoundationDB is the most principled answer to how you get ACID guarantees at distributed scale that exists in open source today. * * * PIPOLINE ยท DEVOPS CONSULTING ### Building distributed infrastructure that needs real ACID guarantees? Evaluating FoundationDB vs CockroachDB, architecting a distributed storage layer, or planning a migration from single-node PostgreSQL to distributed storage โ€” these are the infrastructure challenges Pipoline works on. Get in touch. Get in touch at pipoline.com โ†’

devopspack.com

Zenoh is the protocol that unifies pub/sub, queries, and distributed storage from a microcontroller to the cloud โ€” without bridges, adapters, or topology constraints. Apache 2.0, written in Rust, used in ROS2, automotive SDVs, and edge infrastructure. Here's what it is and when you need it.

Zenoh: The Protocol That Runs From Microcontroller to Data Center

Most distributed systems end up with a protocol zoo. MQTT for IoT sensors because it's lightweight. Kafka for the data pipeline because it handles volume. REST for microservices because everything speaks HTTP. DDS for robotics because ROS2 requires it. And then a constellation of bridges, adapters, and translation layers to connect all of them โ€” each adding latency, complexity, and another failure point. Zenoh is the protocol that's trying to eliminate this zoo. It runs the same protocol from a bare-metal microcontroller with 64KB of RAM to a cloud data center, handles pub/sub messaging, geo-distributed queries, and persistent storage in a unified abstraction, and requires no broker for peer-to-peer topologies. One protocol, the full range of distributed systems. ## What Zenoh is Zenoh (pronounced "zeno") is an open-source pub/sub/query protocol designed to unify data in motion, data at rest, and computations across heterogeneous networks. It's developed by ZettaScale Technology, hosted under the Eclipse Foundation, **Apache 2.0 licensed** , and written in Rust โ€” with official bindings for Python, C, C++, Java, Kotlin, TypeScript, and as of version 1.9.0, Go. The current stable release is **1.9.x (Longwang)** , shipped April 2026. The GitHub repository has 4,700+ stars across the main zenoh crate, with active development and a bi-monthly release cadence named after mythological figures. The name is both a philosophical tribute and an acronym: _Zero Endpoint Network Overhead Handover_ โ€” capturing the goal of eliminating unnecessary overhead at every layer of the stack. Zenoh was designed by Angelo Corsaro, who co-chaired the OMG Data Distribution Service (DDS) specification group, after seeing the protocol gap in large-scale distributed systems for military, aerospace, and smart-city projects. No single protocol could span the full range: DDS was excellent for robotics and real-time systems but couldn't scale to internet scope or down to microcontrollers. MQTT needed a broker even for two devices on the same local network. Zenoh is the attempt to build what should have existed. ## The three primitives Zenoh's design is built around three composable abstractions that cover most distributed data needs: ### Publish/Subscribe The familiar pub/sub model, but without the broker requirement. Publishers write to key expressions (slash-separated paths like `robot/sensor/temp` or `vehicle/zone1/pressure`). Subscribers declare interest in key expressions that can include wildcards (`robot/sensor/*` or `vehicle/**/pressure`). Zenoh routes data efficiently between them regardless of network topology โ€” peer-to-peer, brokered, or hybrid. # Python โ€” publisher import zenoh session = zenoh.open(zenoh.Config()) pub = session.declare_publisher("robot/sensor/temp") pub.put({"value": 42.7, "unit": "celsius"}) # Python โ€” subscriber sub = session.declare_subscriber("robot/sensor/*", lambda sample: print(f"Received: {sample.key_expr} = {sample.payload}") ) ### Query/Reply (Queryables) Where pub/sub handles data in motion, queries handle data at rest. Any Zenoh node can declare itself a Queryable โ€” a handler that responds to queries matching a key expression. This is how Zenoh provides geo-distributed data access: you query `fleet/trucks/**/telemetry` and Zenoh routes the query to whichever nodes have matching data, collects replies, and returns them. Location transparency for data at rest โ€” you ask for data without knowing or caring where it lives. ### Geo-Distributed Storage Zenoh nodes can declare storage โ€” persistent or in-memory โ€” backed by the filesystem, RocksDB, S3-compatible storage, InfluxDB, or any custom backend via the plugin architecture. Publications to a key expression are automatically stored. Queries retrieve historical data. The storage layer integrates seamlessly with the pub/sub layer โ€” a sleeping subscriber that comes back online can query for missed publications from the nearest storage rather than losing them. ## The topology model This is what makes Zenoh architecturally distinct from MQTT and similar broker-dependent protocols. Zenoh supports three node roles, composable into arbitrary topologies at runtime: * **Router** โ€” a standalone Zenoh daemon (`zenohd`) that routes messages and provides infrastructure services. Comparable to an MQTT broker but not required for all topologies. * **Peer** โ€” a node that communicates directly with other peers without a router, forming mesh or clique topologies for local networks. * **Client** โ€” a lightweight node that connects through a router or peer, suitable for constrained devices. The critical feature: **topology is decided at runtime, not hardcoded in the protocol**. Two Zenoh peers on the same network communicate directly via multicast discovery and peer-to-peer links. When they need to reach nodes in the cloud, they route through a Zenoh router. When they're embedded devices with 64KB RAM, they run zenoh-pico, the pure C implementation designed for constrained hardware, and connect as clients. Same protocol, same key expressions, same API โ€” no translation layer. Zenoh 1.9.x (Longwang) introduced **Regions** โ€” a complete reimagining of the topology model that enables arbitrarily deep network hierarchies. Instead of the traditional three-layer router/peer/client model, you can now design nested subregions, configure custom gateway relationships, and scale to deployments that span multiple geographic regions, each with their own internal topology. This enables large-scale deployments โ€” from edge robotics that connect hubs as clients, to fleet management systems that span continents โ€” without hitting the scaling limits of any single topology type. ## Transport layer Zenoh runs over TCP, UDP, TLS, QUIC, WebSocket, Unix domain sockets, and serial links. Zenoh 1.9.x added QUIC stream multiplexing and mixed reliability support โ€” combining reliable and unreliable streams on the same QUIC connection, which is important for real-time systems where some data (like sensor readings) can be lost while control commands must be delivered reliably. The transport-agnostic design means Zenoh works over whatever link is available: TCP for cloud, QUIC for low-latency links, UDP multicast for local network discovery, serial for embedded-to-embedded communication. ## Zenoh-Pico โ€” for constrained devices zenoh-pico is the pure C implementation of the Zenoh protocol designed for microcontrollers and constrained devices. It runs on hardware with as little as 64KB of RAM, supports Arduino, Zephyr RTOS, FreeRTOS, and bare metal targets. It implements the same key expressions and API as full Zenoh, meaning a constrained sensor can publish to the same namespace as a cloud service with no translation layer. Zenoh 1.9.x added a new async executor model to zenoh-pico that reduces resource usage in single-threaded mode while enabling advanced features like auto-reconnection and peer-to-peer mode on constrained hardware. This is the same stack you'd run on a vehicle ECU, an industrial sensor node, or an autonomous robot's embedded controller โ€” all communicating natively with cloud services using the same protocol. ## Zenoh and ROS2 One of the most significant production use cases for Zenoh is as the middleware for ROS2 (Robot Operating System 2). ROS2 traditionally uses DDS (Data Distribution Service) as its middleware layer โ€” powerful for robotics but heavyweight for some deployments and difficult to bridge to the broader internet. `rmw_zenoh` is an official ROS2 middleware implementation that replaces DDS with Zenoh. This gives ROS2 applications native pub/sub across heterogeneous networks without DDS's discovery overhead, access to Zenoh's storage and query capabilities, and the ability to extend robot communication to the cloud or to constrained edge devices without a separate bridge layer. The Zenoh team has published benchmarks showing significant CPU and memory efficiency gains for ROS2 workloads: running a Zenoh router with 100 ROS2 nodes (50 publishers, 50 subscribers) on a 4-core 8GB machine shows substantially lower resource consumption than equivalent DDS deployments. ## Automotive โ€” Software Defined Vehicles Automotive is another primary use case. Modern vehicles are increasingly "Software Defined Vehicles" (SDVs) โ€” computers on wheels where electronic control units (ECUs) communicate sensor data, run algorithms, and actuate physical systems. SOME/IP and CAN bus have been the traditional in-vehicle protocols, but they don't extend cleanly to cloud connectivity or over-the-air updates. Zenoh fits the automotive architecture: ECUs run zenoh-pico as clients to zonal routers, zonal routers communicate with a central vehicle router, and the vehicle router connects to cloud infrastructure. Same protocol, same key expressions, from tire pressure sensor to fleet management backend. The security analysis from Census Labs (March 2025) identified the multi-router hop-by-hop encryption model as worth noting for sensitive deployments โ€” something to understand when designing security-critical automotive architectures. ## Language support The primary implementation is Rust, with all other language bindings wrapping the Rust core (except zenoh-pico which is pure C). Official supported languages: * **Rust** โ€” primary implementation, full feature set * **Python** โ€” binding via PyO3, suitable for scripting and data science workflows * **C / C++** โ€” for systems programming and embedded use * **Java / Kotlin** โ€” for Android and JVM-based systems * **TypeScript** โ€” for browser and Node.js applications (WebSocket transport) * **Go** โ€” official binding added in 1.9.0, sponsored by SoftBank Corp * **zenoh-pico (C)** โ€” pure C, microcontroller and RTOS targets ## The plugin ecosystem The zenohd router supports plugins that extend its capabilities. Official plugins include: * **zenoh-plugin-rest** โ€” RESTful HTTP API for Zenoh networks, bridging HTTP clients to Zenoh pub/sub * **zenoh-bridge-mqtt** โ€” bidirectional bridge between MQTT brokers and Zenoh networks, enabling existing MQTT infrastructure to integrate with Zenoh * **zenoh-plugin-ros2dds** โ€” bridge between Zenoh and DDS-based ROS2 systems * **zenoh-backend-filesystem** โ€” persistent storage backend using the filesystem * **zenoh-backend-rocksdb** โ€” high-performance persistent storage * **zenoh-backend-s3** โ€” S3-compatible object storage backend * **zenoh-backend-influxdb** โ€” time-series storage backend The MQTT bridge deserves particular attention for DevOps teams: if you have existing MQTT infrastructure (IoT devices, sensors) but want to move toward Zenoh's more capable topology model, the bridge lets existing MQTT devices communicate natively with Zenoh nodes without firmware updates. ## Zenoh vs the alternatives **vs MQTT** โ€” MQTT is the dominant IoT messaging protocol and broadly supported. Its limitation is the broker requirement: every device routes through a central broker even if two devices are on the same local network, adding latency and a single point of failure. MQTT also has no native storage or query semantics. Zenoh's broker-optional design and built-in storage/query layer address both limitations. For simple IoT scenarios with existing MQTT infrastructure, MQTT remains appropriate; for complex distributed systems or edge-to-cloud spanning deployments, Zenoh's architecture is superior. **vs Kafka** โ€” Kafka is the dominant choice for high-throughput data pipelines and event streaming in cloud architectures. It's not designed for constrained devices, doesn't run on embedded hardware, and requires significant operational overhead (ZooKeeper or KRaft, broker cluster, topic management). Zenoh covers different use cases: it's better for latency-sensitive, geographically distributed, or hardware-spanning deployments. For pure high-throughput log streaming in cloud environments, Kafka remains the right choice. **vs DDS/ROS2** โ€” DDS (OMG Data Distribution Service) is the incumbent for real-time robotics and defense systems. It offers rich QoS policies and reliable pub/sub but has complex discovery overhead and doesn't scale naturally to internet scope or constrained devices. Zenoh was explicitly designed as a superset of DDS's capabilities with better scalability and resource efficiency, by the same people who designed parts of DDS. **vs gRPC/REST** โ€” gRPC and REST are request/response protocols excellent for service APIs. They don't provide pub/sub semantics, don't handle data at rest natively, and don't adapt to peer-to-peer topologies. They're the right choice when you have a clear client/server relationship; Zenoh is the right choice when data flow is more complex and topology more dynamic. ## Getting started Run a Zenoh router with Docker: docker run --init -p 7447:7447/tcp -p 7447:7447/udp \ eclipse/zenoh:latest Install the Python binding and run a subscriber: pip install eclipse-zenoh python3 -c " import zenoh, time def listener(sample): print(f'>> [{sample.key_expr}]: {sample.payload.deserialize(str)}') session = zenoh.open(zenoh.Config()) sub = session.declare_subscriber('demo/**', listener) print('Listening... Press CTRL-C to stop') time.sleep(3600) session.close() " Publish from another terminal: python3 -c " import zenoh session = zenoh.open(zenoh.Config()) session.put('demo/temperature', 'Hello from Zenoh!') session.close() " ## Who it's for **Good fit:** * Robotics teams building ROS2-based systems who want cloud connectivity and better resource efficiency than DDS * Automotive / SDV projects needing communication from ECUs to cloud backend * Edge computing architectures that span constrained hardware and cloud services * IoT deployments that need more than MQTT offers โ€” storage, queries, peer-to-peer * Distributed systems teams tired of maintaining protocol translation bridges * Projects that need to span from microcontroller to data center on a single protocol **Not the right fit:** * Simple IoT projects with existing MQTT infrastructure and no need to extend to cloud or constrained hardware โ€” MQTT works fine * Pure cloud microservice architectures โ€” Kafka, gRPC, and REST are better suited and more operationally familiar to most teams * Teams that need a large existing community and broad third-party tooling โ€” Zenoh's ecosystem is growing but smaller than MQTT or Kafka's ## My take Zenoh solves a real problem that most infrastructure engineers haven't fully articulated yet: the protocol gap between the embedded world and the cloud world. MQTT gets you from sensor to broker. Kafka gets you from broker to data lake. DDS handles real-time robot communication. None of them spans the full range, which is why every serious IoT or robotics deployment ends up with translation bridges. Zenoh is the protocol that could eliminate most of those bridges. The Apache 2.0 license, Rust implementation, and Eclipse Foundation governance are all positive signals for long-term viability. The ROS2 adoption through `rmw_zenoh` is probably the fastest path to wider adoption โ€” as robotics teams migrate to it, the ecosystem builds. For DevOps engineers specifically, Zenoh is most immediately relevant for infrastructure that spans hardware boundaries: if you're building platforms that need to collect data from embedded sensors, process it at the edge, and feed it to cloud services โ€” and you're tired of maintaining MQTT-to-Kafka adapters or DDS bridges โ€” Zenoh is worth a serious look. The Docker-based router makes it straightforward to add to an existing stack, and the MQTT bridge plugin means you don't have to abandon existing infrastructure to start. It's a specialized tool for a specific class of distributed system problems. But for teams who have those problems, it's the most coherent solution available. * * * PIPOLINE ยท DEVOPS CONSULTING ### Building distributed infrastructure that spans hardware boundaries? Designing architectures that span embedded devices, edge nodes, and cloud services โ€” and need a protocol that works across all of them without translation bridges โ€” is exactly the kind of infrastructure challenge Pipoline works on. If you're evaluating Zenoh for a real deployment, or building a platform that needs to span from IoT hardware to cloud pipelines, get in touch. Get in touch at pipoline.com โ†’

devopspack.com

Stalwart replaces Postfix + Dovecot + Rspamd + a dozen config files with one Rust binary. Bulwark gives it a modern JMAP webmail UI. Together they're the self-hosted email stack for 2026 โ€” private, fast, and finally not painful to run.

Stalwart + Bulwark: Self-Hosted Email That Doesn't Require a PhD to Run

Running your own email server has a reputation that's hard to shake. Postfix, Dovecot, Rspamd, OpenDKIM, a dozen configuration files in different formats, a fragile chain of daemons that each fail in their own creative ways โ€” and all of it between you and a working inbox. The conventional wisdom is "don't self-host email." Most people follow it. Stalwart is the project that's making that advice worth reconsidering. It's a single Rust binary that replaces the entire traditional email stack. No Postfix, no Dovecot, no Rspamd, no separate DKIM daemon. One process handles SMTP, IMAP, JMAP, spam filtering, CalDAV, CardDAV, and WebDAV โ€” and it does it in about 100MB of RAM. Pair it with Bulwark โ€” a modern JMAP webmail client built specifically for Stalwart โ€” and you have a complete self-hosted email platform that looks and feels like it was built in 2026, not 1996. ## The email self-hosting problem The traditional self-hosted email stack is a chain of interdependent components, each with its own configuration language, log format, and failure modes: * **Postfix** โ€” SMTP daemon for sending and receiving * **Dovecot** โ€” IMAP/POP3 daemon for mail retrieval * **Rspamd or SpamAssassin** โ€” spam filter * **OpenDKIM** โ€” DKIM signing * **Roundcube or SOGo** โ€” webmail UI with its own database * **Certbot** โ€” TLS certificate management * **MySQL or PostgreSQL** โ€” backing database for multiple components The whole stack consumes 1.5GB+ of RAM on a dedicated server. Configuration spans multiple files with incompatible syntax. Debugging a delivery failure means correlating logs from three different daemons with three different time formats. Setting up DKIM, DMARC, and SPF correctly requires careful manual coordination. Stalwart collapses all of this into one binary. ## What Stalwart is Stalwart is an all-in-one, open-source mail and collaboration server written in Rust. It supports JMAP, IMAP4, POP3, SMTP, CalDAV, CardDAV, and WebDAV โ€” all in a single binary, with a single configuration system and a single web admin UI. It runs in roughly 100MB of RAM compared to 1.5GB+ for the traditional stack. It has 12,700+ GitHub stars and is actively maintained by Stalwart Labs. The license is AGPL-3.0 for the Community Edition โ€” genuinely open source. Running unmodified Stalwart internally doesn't trigger any AGPL source disclosure requirement; the copyleft condition only applies when you redistribute modified versions or offer them as a network service. An Enterprise Edition adds AI-assisted spam filtering via LLM, account archiving, live telemetry, and white-label multi-tenant features. Stalwart's Community Edition is not feature-limited. No mailbox count limits, no domain limits, no feature gating on core email functionality. You get the full server โ€” DKIM, spam filtering, CalDAV, CardDAV, WebDAV, and JMAP โ€” for free. ## What makes Stalwart different ### One binary, everything included The single-binary architecture isn't just operationally convenient โ€” it changes what's possible. The same sign-in, the same access controls, the same disk quotas, and the same monitoring cover mail, calendars, contacts, and files. One backup covers all of it; one audit log records all of it. ### JMAP โ€” the modern email protocol This is the most technically interesting aspect of Stalwart. JMAP (RFC 8620/8621) is the Internet Engineering Task Force's modern replacement for IMAP, standardized in 2019. Where IMAP was designed in 1986 for slow, unreliable connections, JMAP is designed for the modern web: HTTP/2, JSON, push notifications, batch operations, and server-side state tracking. In practice, JMAP means: the server tells your client when something changes, rather than your client polling every 30 seconds. Mark-read, move, and fetch operations batch into a single HTTP call instead of a multi-round-trip IMAP conversation. Threading is computed server-side, not reassembled on every page load. For a webmail client, JMAP is what makes the interface feel instant rather than sluggish. ### Security built in Stalwart handles DANE, MTA-STS, and TLS reporting for transport security. TLS certificates renew automatically via ACME. Mailboxes at rest can be encrypted with the user's S/MIME certificate or OpenPGP key, so even an operator with disk access cannot read them. DKIM key rotation is automated โ€” the server generates new keys, publishes them in DNS, and waits for propagation before activating them. No manual key rotation cronjob. ### Built-in spam filtering A statistical spam classifier with collaborative filtering, DNS blocklist checking, greylisting, spam traps, and sender reputation monitoring ships inside the same binary as the SMTP server. Unwanted mail is scored and rejected before it reaches the mailbox, with no extra daemon to deploy. No separate SpamAssassin or Rspamd process, no milter integration to configure. ### Resource efficiency A $5/month VPS can handle hundreds of mailboxes with Stalwart, compared to $6/user/month for Google Workspace or $12.50/user/month for Microsoft 365. The 100MB memory footprint means Stalwart fits alongside other services on a modest server โ€” it doesn't need its own dedicated machine. ## Self-hosting Stalwart Docker Compose is the simplest path. The entire stack is one container: services: stalwart-mail: image: stalwartlabs/mail-server:latest container_name: stalwart-mail restart: unless-stopped ports: - "25:25" # SMTP - "587:587" # SMTP submission - "465:465" # SMTPS - "143:143" # IMAP - "993:993" # IMAPS - "4190:4190" # ManageSieve - "8080:8080" # Web admin UI volumes: - ./data:/opt/stalwart-mail/data - ./config:/opt/stalwart-mail/etc On first run, admin credentials are generated and printed to the container logs. Navigate to `http://your-server:8080`, log in, and the web admin UI walks you through the rest: domain setup, DKIM configuration, user creation, and spam filtering rules. Put Traefik in front for HTTPS on the admin UI (port 8080). Note that the mail ports themselves (25, 587, 465, 143, 993) need direct exposure โ€” they can't go through a standard HTTP reverse proxy. Before going live: configure your DNS records (MX, SPF, DKIM, DMARC), check that your server's IP isn't on any blacklists (MXToolbox), and ensure your VPS provider allows outbound port 25 โ€” many cloud providers block it by default and require a support ticket to enable. ## What Bulwark is Bulwark is a modern, self-hosted webmail suite that speaks JMAP natively and pairs with Stalwart. It bundles mail, calendar, contacts, and files behind a single login โ€” the four apps most self-hosters end up wanting together โ€” with a web-based setup wizard, OAuth2/OIDC SSO, and an admin dashboard. Bulwark is the answer to the webmail problem. Roundcube works, but it looks like 2008 and connects to IMAP โ€” which means it misses everything JMAP enables: push notifications, instant sync, server-side threading. Stalwart's built-in webmail is minimal. Bulwark is what a JMAP-first webmail looks like when built with modern tooling (Next.js, TypeScript, AGPL-3.0). It has 705+ GitHub stars with active development โ€” last release was June 30, 2026, with 32 releases shipped at a cadence of one every two days. ### Bulwark features * **Mail** โ€” threaded conversations, unified inbox, full-text search, Sieve filters, S/MIME, templates, multiple identities * **Calendar** โ€” month, week, day, and agenda views, drag-to-reschedule, recurring events, iMIP invitations, CalDAV subscriptions * **Contacts** โ€” multiple address books, groups, vCard import/export, composer autocomplete * **Files** โ€” Stalwart's JMAP FileNode storage with previews and folder upload * **Setup wizard** โ€” first-launch web UI for JMAP, OAuth, branding, and admin credentials โ€” no .env.local editing * **Plugin system** โ€” typed extension API for adding buttons, sidebars, keyboard shortcuts, and calendar integrations (Jitsi Meet plugin ships by default) * **Mobile app** โ€” React Native (Expo) client for iOS and Android with FCM push notifications ### Self-hosting Bulwark services: bulwark: image: ghcr.io/bulwarkmail/webmail:latest container_name: bulwark restart: unless-stopped ports: - "3000:3000" volumes: - ./bulwark-data:/app/data Navigate to `http://your-server:3000` on first launch โ€” the setup wizard asks for your JMAP server URL (your Stalwart instance), configures OAuth2 against Stalwart, and sets the admin password. No config file editing required. Put Traefik in front for HTTPS and a clean domain like `mail.example.com`. ## The complete stack Running both together gives you a complete email platform under your own domain: * **stalw.art** โ€” handles all email protocols (SMTP/IMAP/JMAP), spam filtering, CalDAV/CardDAV, DKIM/DMARC, TLS * **Bulwark** โ€” modern webmail UI at `mail.example.com` with calendar, contacts, and files * **Traefik** โ€” HTTPS for the Bulwark webmail interface and Stalwart admin UI Your users get an email address at your domain, a webmail interface that feels modern, calendar and contacts sync via CalDAV/CardDAV with any standard client (Thunderbird, Apple Mail, Outlook, Android), and mobile apps. All of it runs on a $5-10/month VPS. ## Stalwart vs the alternatives **vs Mailcow** โ€” Mailcow is the most popular self-hosted email suite and has the largest community. It's a well-maintained Docker Compose stack combining Postfix, Dovecot, Rspamd, SOGo, and Nginx โ€” all the traditional components, packaged together with a polished management UI. Mailcow is more mature with better documentation for common setups. Stalwart wins on resource efficiency (100MB vs 1.5GB+), architectural simplicity (one binary vs 8+ containers), and JMAP support. For a new deployment in 2026, Stalwart is the technically superior choice. For a team that wants the most documented, battle-tested option with a large support community, Mailcow's maturity is worth considering. **vs Postfix + Dovecot + Rspamd** โ€” the traditional stack has 20+ years of production use, enormous documentation, and the widest possible expertise pool. If you're an experienced sysadmin who knows these tools, they're not going away. Stalwart's advantage is for teams who want email self-hosting without becoming email protocol experts. **vs Google Workspace / Microsoft 365** โ€” the obvious comparison. At $6-12.50/user/month, a 10-person team pays $720-1,500/year. Stalwart self-hosted on a $6/month VPS: $72/year. The math is compelling, but the operational responsibility is real โ€” you own deliverability, backups, and uptime. ## Honest caveats Email deliverability is the hard part of self-hosting email, and Stalwart doesn't change this. Getting your emails to land in recipients' inboxes rather than their spam folders requires: * A clean IP reputation (not previously used for spam) * Correct SPF, DKIM, and DMARC records * A valid PTR (reverse DNS) record matching your sending domain * A VPS provider that allows outbound port 25 Stalwart automates DKIM rotation and makes the DNS setup easier, but it can't help with a bad IP reputation or a provider that blocks port 25. Check MXToolbox before sending to anyone important. Stalwart is approaching version 1.0 but isn't there yet. The core functionality is feature-complete; the team is now focused on finalizing the database schema and performance optimizations before the 1.0 release. For production use, run regular backups and follow the release notes โ€” schema changes between versions require migration steps. ## Who it's for **Good fit:** * Developers, small teams, and agencies who want email under their own domain with full data ownership * Organizations with GDPR or data sovereignty requirements that rule out Google and Microsoft * Self-hosters who already run other infrastructure and want email to fit naturally into their stack * Teams that find Mailcow's resource footprint too heavy for a modest VPS * Anyone who wants calendar and contacts sync alongside email without a separate Nextcloud deployment **Not the right fit:** * Teams who need zero operational responsibility โ€” use Fastmail, Protonmail, or Migadu * Large organizations needing enterprise-grade support SLAs without the Enterprise Edition * Deployments where email deliverability is mission-critical from day one โ€” the learning curve for getting deliverability right is real ## My take Stalwart is the most interesting development in self-hosted email in years. The single-binary architecture doesn't just simplify deployment โ€” it changes the failure surface. Instead of debugging a multi-daemon chain, you're looking at one process with one log. Instead of maintaining compatible versions of half a dozen components, you run one binary and update it. The 100MB RAM footprint means you can add email to a server that's already running a dozen other tools without provisioning dedicated infrastructure. Bulwark is the piece that makes the full stack compelling rather than just functional. Roundcube on IMAP is fine; Bulwark on JMAP is fast. The distinction matters when your webmail is how you actually read email โ€” push notifications instead of polling, instant thread updates, one-click calendar invites from your email, all running on your own hardware. The combination puts a complete Google Workspace alternative on your own server: email, calendar, contacts, and file storage, at a fraction of per-seat costs. If you're already running Traefik, Gitea, Plane, and Mattermost on a self-hosted server โ€” and if you've been reading this blog you probably are โ€” adding Stalwart + Bulwark completes the picture. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help setting up Stalwart + Bulwark? Getting self-hosted email right โ€” Stalwart deployment, DNS configuration (MX, SPF, DKIM, DMARC), PTR record setup, deliverability verification, Bulwark webmail configuration with OAuth, and Traefik for HTTPS โ€” has more ways to go wrong than almost any other self-hosted service. I can handle the full setup and verify deliverability before you send your first email. You get a working self-hosted email stack without the usual war stories. Get in touch at pipoline.com โ†’

devopspack.com

Docmost is the genuinely open source Confluence and Notion alternative โ€” real-time collaborative editing, spaces, permissions, built-in Drawio and Mermaid diagrams, and no OIDC provider required just to log in. Self-host free, no seat fees, your data on your server.

Docmost: The Open Source Wiki That Doesn't Need an Identity Provider to Work

Confluence Data Center is dying. Atlassian stopped accepting new purchases in March 2026, and every existing license expires in March 2029 โ€” after which instances go read-only. For thousands of organizations running self-hosted Confluence, the clock is ticking. And even for teams on Confluence Cloud or Notion, per-seat pricing that scales with headcount is increasingly hard to justify when good open source alternatives exist. Docmost is the most compelling one right now. It's a collaborative wiki and documentation platform with real-time editing, spaces, nested pages, inline diagrams, and fine-grained permissions โ€” running on a stack you control, with no per-seat fees and no data leaving your network. AGPL-3.0 licensed, **20,700+ GitHub stars** , actively maintained with commits as recently as June 2026. ## What Docmost is Docmost is an open-source collaborative wiki and documentation platform founded by Philip Okugbe and positioned as a direct alternative to Confluence and Notion. It's written in TypeScript (Node.js), self-hosted via Docker Compose, and uses PostgreSQL and Redis as its only dependencies. The core concept: a team knowledge base where pages live inside Spaces (organized by team, project, or department), multiple users can edit the same page simultaneously, and everything is searchable across the entire workspace. No external identity provider required to get started โ€” built-in email and password auth works out of the box. Enterprises including **Airbus, the Australian Government, the German Red Cross, and the University of Bern** use Docmost to manage their knowledge. Many are migrating from Confluence Data Center specifically because of the end-of-life timeline. ## The license โ€” AGPL-3.0 core, /ee for enterprise Docmost uses the open-core model. The core platform is AGPL-3.0 โ€” genuinely OSI-approved open source. Enterprise features (SSO via SAML/OIDC, LDAP, MFA, audit logs, Confluence importer, AI writing assistance, full-text search inside attachments) live in a `/ee` folder under a separate commercial license. This is the same model as GitLab, Metabase, and Fleet โ€” and it's the right tradeoff for most teams. The free Community Edition covers everything the majority of teams need: unlimited pages, unlimited spaces, real-time collaboration, diagrams, comments, page history, search, and file attachments. You pay only if you need SSO, audit logs, or SCIM at enterprise scale. Importantly, the AGPL-3.0 core has no multi-tenant restrictions (unlike Outline's BSL) and no commercial-use clauses. Self-host it for your organization, modify it, use it internally โ€” no license friction. This is the cleaner license story compared to several other tools we've covered on this blog. ## Core features ### Real-time collaborative editor Multiple users can edit the same page simultaneously, with live cursor positions visible. The editor uses Markdown shortcuts that render inline โ€” type `**bold**` and it becomes bold immediately, type ````` and a code block appears. It supports tables, LaTeX math equations, callouts, collapsible blocks, code blocks with syntax highlighting, mentions, and slash commands for inserting any block type. Non-technical users will find it approachable. Technical users won't miss Markdown. The balance is well-executed. ### Built-in diagrams โ€” no integrations needed Three diagramming tools are built in with no setup required: * **Mermaid** โ€” code-based diagrams (flowcharts, sequence diagrams, ER diagrams) rendered inline * **Draw.io** โ€” full visual diagramming editor embedded in the page * **Excalidraw** โ€” freehand whiteboard-style diagrams For engineering teams that document architecture, system flows, and data models, having Mermaid and Draw.io built into the editor without a plugin or integration is a genuine differentiator. In Confluence you'd pay for a Draw.io plugin. In Notion you'd embed an external tool. In Docmost it's just there. ### Spaces Spaces organize your knowledge base into distinct areas โ€” Engineering, Product, HR, Legal, Onboarding. Each space has its own permission settings: who can view, who can edit, who can manage. Pages nest infinitely within spaces and can be reordered via drag-and-drop in the sidebar. This is the right organizational model for most teams. Not too rigid (like Confluence's project-based structure), not too flat (like a shared Notion workspace). Spaces map naturally to how organizations think about their documentation. ### No external auth required This is worth calling out explicitly because it's where Docmost differs most from Outline. Outline requires an external OIDC/OAuth provider before it will show you a login screen. Docmost ships with built-in email and password auth โ€” you deploy it, create your admin account, invite your team by email, done. No Authentik integration required just to get your wiki working. SSO (SAML 2.0 and OIDC) is available as an enterprise feature. For teams that already run Authentik or Keycloak, integrating it is straightforward โ€” but it's optional, not a requirement. ### Comments and page history Inline comments on any text selection, threaded discussions, and comment resolution (enterprise). Every page change is tracked with the ability to view diffs between versions and restore any previous state. For documentation that evolves โ€” architecture decisions, policies, runbooks โ€” this audit trail is essential. ### Search Full-text search powered by PostgreSQL's built-in search capabilities. No Elasticsearch or Typesense required. For teams not needing search inside PDF attachments (an enterprise feature), the built-in Postgres search is fast and sufficient for most wiki use cases. ## Self-hosting Docmost One of Docmost's advantages is setup simplicity. Docker Compose, PostgreSQL, Redis โ€” that's the entire stack: services: docmost: image: docmost/docmost:latest depends_on: - db - redis environment: APP_URL: 'https://wiki.example.com' APP_SECRET: ${APP_SECRET} DATABASE_URL: 'postgresql://docmost:${POSTGRES_PASSWORD}@db:5432/docmost' REDIS_URL: 'redis://redis:6379' ports: - "3000:3000" restart: unless-stopped volumes: - ./docmost-data:/app/data/storage db: image: postgres:16-alpine environment: POSTGRES_DB: docmost POSTGRES_USER: docmost POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} restart: unless-stopped volumes: - ./postgres-data:/var/lib/postgresql/data redis: image: redis:7.2-alpine restart: unless-stopped Generate `APP_SECRET` with `openssl rand -hex 32`. Put Traefik in front for HTTPS and configure SMTP for email invitations and password resets โ€” Docmost needs SMTP to send invite emails, so configure it before you invite your first user. One important note: WebSockets must pass through your reverse proxy. If you use Traefik or Nginx, ensure WebSocket proxying is enabled โ€” real-time collaborative editing depends on it. Minimum requirements: 1 CPU core, 1GB RAM for a small team. Air-gapped deployments work without any external internet dependencies. ## Docmost vs Outline We covered Outline in depth on this blog, so a direct comparison is useful for teams choosing between them. **License** โ€” Docmost wins clearly. AGPL-3.0 is OSI-approved open source. Outline uses BSL 1.1 (source-available, not OSI open source), converting to Apache 2.0 in 2030. For teams with OSI compliance requirements, Docmost is the only option. **Setup friction** โ€” Docmost wins. Built-in email/password auth means you deploy and start working. Outline requires an external OIDC/OAuth provider before the login screen even appears. **Diagrams** โ€” Docmost wins. Mermaid, Draw.io, and Excalidraw built in. Outline has limited native diagram support. **Maturity and polish** โ€” Outline wins. ~39,000 stars vs Docmost's ~20,700. Outline has a more refined editor, better API documentation, deeper Slack integration, and a longer production track record. **Integrations** โ€” Outline wins. Slack, GitHub, Figma, Linear, Airtable embeds, and a mature REST API. Docmost's API exists but is less documented. **Resource footprint** โ€” Docmost wins. Both use Node.js, but Docmost's stack (Node + PostgreSQL + Redis) is lighter than Outline's (Node + PostgreSQL + Redis + S3-compatible storage as a requirement). The practical recommendation: **pick Docmost if** the OSI license matters, you want diagrams built in, or you don't want to stand up an identity provider first. **Pick Outline if** you value the most polished experience and are already running SSO. ## Docmost vs Confluence The migration audience is real and growing. Confluence Data Center is end-of-life. Confluence Cloud is expensive at per-seat pricing. Teams evaluating replacements will find: * **Cost** โ€” Docmost Community Edition: $0 + server. Confluence Cloud: $5.75/user/month (Standard) to $11/user/month (Premium). * **Data ownership** โ€” Docmost self-hosted: your server. Confluence Cloud: Atlassian's servers. * **Diagrams** โ€” Docmost has Draw.io built in. Confluence requires the Draw.io plugin (paid add-on). * **Migration** โ€” Docmost's Confluence importer is available in the paid Business tier. Community Edition migration requires manual export/import. * **Enterprise features** โ€” Confluence has significantly deeper enterprise governance (fine-grained audit, Jira integration, compliance certifications). Docmost is catching up but isn't there yet for the largest enterprises. ## Who it's for **Good fit:** * Teams migrating from Confluence Data Center before the 2029 end-of-life * Organizations with data sovereignty or compliance requirements ruling out SaaS wikis * Engineering teams who want Mermaid and Draw.io built into their documentation tool * Teams that want Outline's experience but need a true OSI open source license * Teams without an existing SSO provider who want a wiki that works without one * Air-gapped environments needing a complete offline wiki **Not the right fit:** * Teams that need SSO on the free tier โ€” that requires the paid Business plan * Organizations needing the most polished editor and deepest integrations โ€” Outline is more mature * Teams that need Confluence-level enterprise governance today โ€” Docmost is growing but not there yet ## My take Docmost is the tool to watch in the self-hosted wiki space in 2026. The combination of a genuinely clean OSI-approved license, no external auth dependency, built-in diagrams, and a rapidly growing community puts it ahead of most alternatives for teams starting fresh. The Confluence Data Center end-of-life is a real forcing function. Organizations that have been running self-hosted Confluence for a decade suddenly need an alternative โ€” and Docmost is the most credible modern replacement that keeps data on your infrastructure. The built-in Confluence importer (Business tier) makes that migration path concrete. The comparison with Outline is honest: Outline is more polished and has more integrations. But Outline's BSL license is a genuine blocker for some organizations, and the "must configure an identity provider before anything works" setup friction is real overhead for small teams. Docmost clears both of those hurdles. For the self-hosted stack we've been building across this blog โ€” Gitea for code, Plane for project management, Traefik for routing, Authentik for auth โ€” Docmost is the natural choice for documentation. Same server, same Docker Compose pattern, AGPL-3.0 license, works offline. It fits. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help migrating to Docmost or setting it up? Deploying Docmost โ€” Docker Compose, PostgreSQL, Redis, Traefik for HTTPS, SMTP for invitations, WebSocket proxy configuration, and migrating your existing documentation from Confluence or Notion โ€” takes experience to get right. I can handle the full setup and migration, including structuring your Spaces for how your team actually works. You get a production-ready wiki on your own infrastructure without spending a weekend on it. Get in touch at pipoline.com โ†’

devopspack.com

Mattermost is the self-hosted Slack alternative that your organization actually owns โ€” channels, threads, file sharing, DevOps integrations, Playbooks for incident response, and now sovereign AI. MIT-licensed, runs as a single binary, unlimited users on the free tier.

Mattermost: Self-Hosted Team Messaging That Your Organization Actually Owns

Every engineering team eventually reaches the Slack conversation. You're paying per seat, every new tool you connect generates notifications that drown signal in noise, your incident response happens in the same channels as cat GIFs, and somewhere in the back of your mind you're aware that every message your team sends is stored on Salesforce's servers under US jurisdiction. The conversation usually ends with someone asking: "Is there a self-hosted alternative that actually works?" Mattermost is that alternative. It's been the most mature self-hosted team messaging platform since 2016, and in 2026 with version 11.7 it's added sovereign AI โ€” channel summaries, multi-agent workflows, and private inference running on your own hardware. Slack functionality, your infrastructure, your data. ## What Mattermost is Mattermost is an open-source, self-hosted collaboration platform offering channels, direct messaging, threads, file sharing, voice calling, screen sharing, and AI integration. It's written in Go and React, runs as a single Linux binary, and relies on PostgreSQL. The current stable release is version 11.7.2 (May 2026). The MIT license applies to the Team Edition โ€” the genuinely open source core. Enterprise features (SSO with SAML/LDAP, compliance tools, advanced playbooks, high availability, AI) are in paid commercial editions. This is the same open-core model as Gitea, Fleet, and Docmost. The free tier is genuinely generous: unlimited users, unlimited message history, core messaging features, and basic integrations. For small teams that need secure messaging without budget constraints, this is a legitimate option when self-hosted. ## Who uses it Mattermost is used by DevOps and engineering teams, government and defense organizations requiring air-gapped deployment, healthcare and financial institutions with HIPAA/SOC 2/GDPR requirements, and enterprises replacing Slack that want to eliminate per-user SaaS costs at scale. Notable users include Uber, the US Department of Defense, and numerous defense contractors and government agencies running completely air-gapped deployments. This isn't a niche academic interest โ€” organizations with genuine national security requirements trust Mattermost for their primary communication infrastructure. ## Core features ### Channels and messaging Public channels, private channels, direct messages, and group messages. Threaded conversations keep discussions organized. Persistent search history. Reactions, emoji, markdown formatting, code blocks with syntax highlighting. File sharing with preview. Pin important messages. Bookmarks. Everything you'd expect from a modern team messaging tool. ### Native apps across all platforms Native apps for iOS, Android, Windows, macOS, and Linux. The desktop app runs on Electron, the mobile apps are React Native. Push notifications work through Mattermost's Push Notification Service โ€” you can run your own MPNS server for fully air-gapped deployments where no traffic leaves your network. ### Playbooks โ€” structured incident response Playbooks are Mattermost's most distinctive capability. A playbook is a checklist-driven workflow that runs inside a dedicated channel, triggered manually or automatically. The classic use case: an alert fires from PagerDuty, Mattermost automatically creates a dedicated incident channel, runs the playbook (acknowledge alert, assess severity, page the on-call engineer, document the timeline), and tracks progress through a structured checklist. This is the feature that makes Mattermost compelling for teams beyond pure messaging. DevOps teams use it for incident response, release management, and on-call handoffs. Security teams use it for vulnerability disclosure and breach response workflows. The playbook lives in the same tool as your daily communication โ€” no context switch to a separate incident management platform. ### DevOps integrations Pre-packaged integrations with Jira, GitHub, GitLab, Zoom, and more. CI/CD pipeline notifications, PR review alerts, deployment status, issue assignments โ€” all routing into the right channels. The webhook and slash command architecture means you can pipe anything into Mattermost. Connecting it to Gitea (covered on this blog) is straightforward via webhooks. The integration story is where Mattermost genuinely beats Slack for engineering teams: you're not constrained by Slack's app marketplace pricing or permission model. Write a custom integration in whatever language you want, deploy it on your own server, and route its output to any channel. ### Boards Mattermost Boards provides kanban-style project management directly within the platform โ€” boards for task tracking, sprint planning, or project management with custom properties, filters, and views. Not as feature-rich as Plane or Jira, but useful for lightweight task tracking without a separate tool switch. ### Sovereign AI โ€” the version 11.7 story The most significant recent development. Mattermost 11.7 shipped the Intelligent Mission Environment framework โ€” a self-hosted, multi-agent AI layer that runs entirely on your own infrastructure: * **AI-powered channel summaries** โ€” catch up on missed conversations without reading every message * **Multi-agent workflows** โ€” orchestrate multiple AI agents within a single workspace * **Private AI inference** โ€” connect to self-hosted LLMs via Ollama, LocalAI, or any OpenAI-compatible endpoint. No data leaves your server. This positions Mattermost 11.7 as the only major team messaging platform where AI features can run fully air-gapped โ€” a critical requirement for defense and government deployments. For engineering teams running Ollama (covered in the Open WebUI post on this blog), connecting your local models to Mattermost's AI summaries is a natural next step. ## Self-hosting Mattermost Docker Compose is the simplest path. Mattermost's stack is lean: the server binary and PostgreSQL. services: mattermost: image: mattermost/mattermost-team-edition:release-9 restart: unless-stopped environment: MM_SQLSETTINGS_DRIVERNAME: postgres MM_SQLSETTINGS_DATASOURCE: postgres://mattermost:${POSTGRES_PASSWORD}@db:5432/mattermost?sslmode=disable MM_SERVICESETTINGS_SITEURL: https://chat.example.com volumes: - ./mattermost/config:/mattermost/config - ./mattermost/data:/mattermost/data - ./mattermost/logs:/mattermost/logs - ./mattermost/plugins:/mattermost/plugins ports: - "8065:8065" depends_on: - db db: image: postgres:16-alpine restart: unless-stopped environment: POSTGRES_DB: mattermost POSTGRES_USER: mattermost POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} volumes: - ./postgres-data:/var/lib/postgresql/data Put Traefik in front for HTTPS. Configure SMTP for email notifications and user invitations. The initial setup wizard walks through the rest. Minimum server requirements: 1 CPU, 2GB RAM for small teams. A new compiled version is released under an MIT license every month on the 16th โ€” monthly release cadence with predictable updates. For larger deployments, Mattermost supports high-availability clustering, read replicas, and horizontal scaling. A Kubernetes Helm chart is available. The deployment documentation is among the most thorough of any open source project in this space. ## Mattermost vs Slack **Data ownership** โ€” the core argument. Slack is Salesforce, subject to US CLOUD Act jurisdiction. Mattermost self-hosted is your infrastructure, your jurisdiction. For regulated industries and organizations outside the US, this is not a philosophical preference โ€” it's a compliance requirement. **Cost at scale** โ€” Slack charges per active user. At 100 users on Slack Pro ($8.75/user/month) you're paying $10,500/year. Mattermost self-hosted free tier: $0 + server costs. The math gets increasingly favorable as teams grow. **DevOps integrations** โ€” Mattermost's integration architecture is more flexible for engineering workflows. Playbooks have no Slack equivalent. The ability to run your own bots and integrations without marketplace fees or permission restrictions is meaningful for teams with complex automation needs. **Polish and ease of use** โ€” Slack wins. The UI is more refined, the mobile apps are smoother, onboarding is simpler. Mattermost's interface is functional but noticeably less polished. For non-technical users, this matters. **AI features** โ€” Mattermost wins for air-gapped/private deployments. Slack AI is cloud-only. Mattermost's sovereign AI framework lets you run AI features on your own hardware with self-hosted LLMs. ## Mattermost vs Rocket.Chat These are the two main self-hosted Slack alternatives and they're worth a direct comparison. Mattermost is generally considered cleaner and more stable, with stronger DevOps integrations and better documentation. Rocket.Chat has more built-in features (video calls, live chat for customer support) but is heavier and historically less stable at scale. For pure internal team messaging, Mattermost is typically preferred by engineering teams. Rocket.Chat's licensing has become more complex over the years, with limits on the free tier. Mattermost's MIT core is simpler and more clearly open source for the core use case. ## Who it's for **Good fit:** * Engineering teams who want Slack functionality without SaaS vendor lock-in * Organizations in regulated industries (defense, finance, healthcare, government) where data sovereignty is non-negotiable * Teams needing structured incident response โ€” Playbooks are genuinely useful for on-call and DevOps workflows * Large teams where per-seat SaaS pricing becomes a significant budget item * Organizations needing air-gapped deployment with zero external dependencies * Teams wanting AI features that run on their own infrastructure **Not the right fit:** * Small teams that prioritize ease of setup over data control โ€” Slack is easier * Teams that need built-in video conferencing โ€” Mattermost relies on external integrations for video calls * Non-technical organizations without IT resources to maintain a self-hosted server * Teams that need the Team Edition beyond 250 users โ€” the free tier has known performance constraints at larger scale ## My take Mattermost is the right answer for organizations where "who owns this data" is a question that actually gets asked. That's a smaller category than the general market but it's a real one โ€” and for teams in that category, there isn't a better-maintained, more mature self-hosted option. For DevOps teams specifically, Playbooks change the calculus. Having structured incident response workflows living inside your daily communication tool โ€” not a separate PagerDuty, Opsgenie, or custom runbook system โ€” reduces the cognitive overhead of incident response in a meaningful way. The integration story (CI/CD pipelines, GitHub/GitLab, monitoring alerts routing into the right channels) is also genuinely better than Slack for teams that have already built webhook-heavy DevOps workflows. The sovereign AI story in version 11.7 is the most interesting recent development. The combination of Mattermost + Ollama gives you AI-powered team communication where no data leaves your network. For the organizations that need that โ€” and there are more of them than the cloud-first tech press acknowledges โ€” it's the only real option in the messaging space. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help deploying Mattermost? Setting up Mattermost in production โ€” Docker Compose, PostgreSQL, Traefik for HTTPS, SMTP for notifications, push notification service configuration, Playbooks for your incident response workflow, and integrating with your CI/CD pipeline and alerting tools โ€” takes experience to get right. I can handle the full setup and wire your existing DevOps tooling into the right channels. You get a production-ready team messaging platform your organization controls, without spending a week on it. Get in touch at pipoline.com โ†’

devopspack.com

We just open sourced MongoTUI โ€” a terminal UI for MongoDB built with Python and Textual. Browse databases, manage users and roles, monitor performance, and handle indexes โ€” all without leaving your terminal. Like Compass, but for SSH sessions.

MongoTUI: A Terminal UI for MongoDB We Just Open Sourced

Managing MongoDB through the terminal is fine when you know exactly what you're doing. `mongosh` is powerful, but navigating databases, checking replica set health, managing user permissions, and running queries all in a raw shell gets tedious fast โ€” especially over SSH, in production environments where Compass can't be installed, or when you just want a quick overview without firing up a GUI. We built MongoTUI to fill that gap. It's an open source terminal user interface for MongoDB that gives you a Compass-like experience in your terminal โ€” keyboard-driven, fast, and secure over SSH. Available today on PyPI and GitHub. ## What MongoTUI does MongoTUI is a Python terminal application built on Textual and PyMongo. It connects to any MongoDB instance โ€” standalone, replica set, or Atlas โ€” and gives you a sidebar-driven interface to navigate your databases and collections, manage users and roles, inspect indexes, monitor live performance, and run queries and aggregation pipelines, all without a web browser. The four main areas: ### Database and document management Browse databases and collections in a Compass-style sidebar tree. View collection stats โ€” document count, storage size. Query documents with JSON filters. Run aggregation pipelines. Create and drop databases. It's the day-to-day MongoDB workflow, in your terminal. ### User and role administration This is where MongoTUI is particularly useful. Managing MongoDB users through `mongosh` means remembering the right command syntax, getting the JSON structure right, and running separate commands to view, create, and modify users. MongoTUI surfaces all of it in one screen: browse all users and their current roles, create and delete users, reset passwords, and grant or revoke roles through a built-in role picker that shows available built-in roles rather than requiring you to type them from memory. If you manage MongoDB access for a team โ€” onboarding engineers, rotating credentials, auditing who has what permissions โ€” this is the workflow improvement MongoTUI was built around. ### Index management View existing indexes with their key info and storage size. Create and drop indexes. Full support for text and vector search indexes, including vector search with similarity options. As MongoDB's vector search capabilities have expanded, index management has gotten more complex โ€” MongoTUI handles the full range. ### Live monitoring Live performance graphs for active connections, operations per second, and memory usage. Server stats: version, uptime, storage engine. Replica set status with member health โ€” so you can see at a glance whether your replica set is healthy without running `rs.status()` and parsing the output. ## Getting started Install from PyPI: pip install mongotui Connect to a local MongoDB instance: mongotui Connect with a URI: mongotui --uri "mongodb://admin:password@localhost:27017/?authSource=admin" # Short form mongotui -u "mongodb://admin:password@localhost:27017/?authSource=admin" Running locally with Docker: # Start a local MongoDB instance docker compose up -d # Connect mongotui -u "mongodb://admin:admin@localhost:27017/?authSource=admin" Requirements: Python 3.11+, MongoDB 4.4 or newer. ## Why we built it The trigger was a specific workflow problem at Pipoline. When working on client infrastructure โ€” MongoDB deployments on servers without GUI access โ€” the user management workflow through `mongosh` was slow and error-prone. Compass isn't always an option: air-gapped environments, servers without a display, quick SSH sessions where installing a GUI tool isn't justified. `mongosh` works but requires remembering the exact command syntax for operations you might only do every few weeks. We wanted something that looked good in a terminal, worked over SSH, and handled the operations that are annoying to do in a raw shell โ€” especially user and role management, where a built-in role picker beats typing `readWriteAnyDatabase` from memory. Textual turned out to be the right framework. It handles keyboard navigation, mouse support, reactive layouts, and terminal graphs cleanly. PyMongo handles the MongoDB connection. The result is something that genuinely feels like a native terminal application rather than a Python script with a box drawn around it. ## Tech stack * **Python 3.11+** * **Textual** โ€” the TUI framework from Textualize * **PyMongo** โ€” official MongoDB Python driver * **textual-plotext** โ€” terminal performance graphs ## What's next MongoTUI is at an early stage. The core workflows โ€” database browsing, user management, index management, and monitoring โ€” are working. There's more to build: document editing directly in the TUI, better aggregation pipeline support, connection profiles for multiple environments, and expanded replica set management. The project is open source under AGPL-3.0. If you're working with MongoDB and spending time in the terminal, try it out. If you run into something that doesn't work or a workflow that's missing, open an issue on GitHub โ€” early feedback shapes where the project goes. **GitHub:** github.com/DevOpsPack/mongotui **PyPI:** pypi.org/project/mongotui * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help with your MongoDB infrastructure? MongoTUI was built out of real production work โ€” managing MongoDB deployments, user access, and replica sets for clients. If you need help with your MongoDB setup, access control, or ops tooling, that's exactly what Pipoline does. Get in touch at pipoline.com โ†’

devopspack.com

Open WebUI is the self-hosted ChatGPT alternative with 139k+ stars โ€” connects to Ollama for local models, any OpenAI-compatible API, Claude, and more. RAG built in, multi-user auth, Python functions, voice chat. One interface for every LLM you run.

Open WebUI: Self-Hosted ChatGPT With Local Models and Full Data Control

Running local LLMs has never been easier. Ollama downloads and runs Llama, Mistral, Qwen, and dozens of other models in one command. The problem is the interface: a terminal API isn't how most people want to interact with a language model. You want a clean chat UI, conversation history, document upload, and the ability to share access with your team โ€” everything ChatGPT gives you, but running entirely on your own hardware. Open WebUI is that interface. It started as "Ollama WebUI" โ€” a simple frontend for Ollama โ€” and has grown into a full self-hosted AI platform that connects to Ollama, every OpenAI-compatible API, Anthropic's Claude directly, and a dozen other backends. Same interface, complete data control, zero per-token cost for local models. ## What Open WebUI is Open WebUI is an extensible, feature-rich self-hosted AI platform designed to operate entirely offline. It supports Ollama and OpenAI-compatible APIs, making it provider-agnostic for both local and cloud-based models. **139,000+ GitHub stars** make it one of the most-starred AI projects on GitHub. It's backed by Andreessen Horowitz (a16z), Mozilla Builders 2024, and GitHub Accelerator 2024 โ€” unusual backing for an open source project, and a signal of serious long-term investment. The core concept: _one interface for every AI model you run_. Connect Ollama for local models, OpenAI for GPT-4o/GPT-5, Anthropic for Claude, vLLM for high-throughput self-hosted inference, or any OpenAI-compatible endpoint. Multiple backends can be active simultaneously โ€” route internal confidential data to a local Ollama model while using the Claude API for tasks that benefit from frontier model capability, all from the same UI. The license is MIT โ€” genuinely open source with no commercial restrictions. Installation options: Docker (most common), Python via uvx, or a desktop app. There's also an Enterprise plan for organizations needing custom branding, SLA support, and LTS versions. ## The model layer โ€” Ollama Open WebUI is the chat layer; Ollama is the model layer. They talk over HTTP on port 11434. Understanding both is useful: **Ollama** handles model downloading, quantization, GPU/CPU allocation, and exposes an OpenAI-compatible API. Install it with one command: # Install Ollama (macOS/Linux) curl -fsSL https://ollama.com/install.sh | sh # Pull and run a model ollama pull llama3.2:3b ollama run llama3.2:3b # For production, keep it running as a service # Ollama listens on http://localhost:11434 Model recommendations to start with: * **llama3.2:3b** โ€” fast on almost anything, 2GB VRAM, good for general chat * **qwen2.5:14b** โ€” strong reasoning, good multilingual, 8GB+ VRAM * **deepseek-r1:7b** โ€” strong at code and technical reasoning * **mistral:7b** โ€” fast, good instruction following, 4GB VRAM On Apple Silicon Macs, run Ollama natively (not in Docker) โ€” this lets it use the Metal GPU. Docker doesn't have Metal GPU passthrough, so a Dockerized Ollama on Mac falls back to CPU and is significantly slower. ## Self-hosting Open WebUI The fastest path when Ollama is already running on your machine: docker run -d \ -p 3000:8080 \ --add-host=host.docker.internal:host-gateway \ -v open-webui:/app/backend/data \ --name open-webui \ --restart always \ ghcr.io/open-webui/open-webui:main Navigate to `http://localhost:3000`, create your admin account (the first user becomes admin automatically), and you're chatting. The `--add-host=host.docker.internal:host-gateway` flag allows the Docker container to reach Ollama running on the host machine. For a self-contained Docker Compose setup with Ollama bundled: services: ollama: image: ollama/ollama volumes: - ollama-data:/root/.ollama restart: unless-stopped # For GPU: add runtime: nvidia + NVIDIA_VISIBLE_DEVICES: all open-webui: image: ghcr.io/open-webui/open-webui:ollama depends_on: - ollama environment: OLLAMA_BASE_URL: http://ollama:11434 WEBUI_SECRET_KEY: ${WEBUI_SECRET_KEY} volumes: - open-webui-data:/app/backend/data ports: - "3000:8080" restart: unless-stopped volumes: ollama-data: open-webui-data: Put Traefik in front for HTTPS. Minimum requirements: 4GB RAM for the Open WebUI container, plus whatever the model requires (3-8GB VRAM for typical 7B models). Open WebUI itself is lightweight โ€” the model is where the resources go. ## Core features ### Multi-backend model management Add API keys for OpenAI, Anthropic, or any OpenAI-compatible endpoint in Settings โ†’ Connections. All connected models appear in the same model selector dropdown. Switch between your local Llama 3.2 and Claude 3.5 Sonnet in the same conversation, or set a default model per workspace. ### Built-in RAG Upload PDFs, Word docs, HTML, CSV, or any text file to a conversation and the built-in RAG engine chunks, embeds, and retrieves relevant context automatically. No separate pipeline to configure. Open WebUI supports five document extraction engines including Tika and Docling (the same IBM Research parser used in OpenRAG). Create persistent knowledge bases that any conversation can reference โ€” upload your company documentation once and query it from any chat. ### Python function calling (Pipelines / Functions) This is where Open WebUI goes beyond a simple chat interface. The native Python Function calling system (previously called Pipelines) lets you extend model capabilities with pure Python functions that run server-side. Add a function that queries your database, calls an internal API, runs a shell command, or does any arbitrary computation โ€” and the model can call it as a tool. Bring Your Own Function (BYOF) by simply adding Python code through the UI's tools workspace. ### Web search integration Connect a search engine to give models access to real-time information. Supported: SearXNG (self-hosted, privacy-first), Google, Brave, DuckDuckGo, Kagi, Perplexity, and others. Configure once, and any conversation can trigger a web search when the model needs current information. The SearXNG combination gives you fully local search-augmented generation with no data leaving your network. ### Multi-user with authentication Create user accounts, assign roles (admin or user), and control model access per user. OAuth support for Google, GitHub, Microsoft, and OIDC providers โ€” including Authentik, which we've covered on this blog. Role-based access control means you can expose Open WebUI to your team without giving everyone admin access or access to every model. ### Voice and video Speech-to-text (STT) via local Whisper, OpenAI, Deepgram, or Azure, and text-to-speech (TTS) via Azure, ElevenLabs, OpenAI, or local Transformers. Hands-free voice conversations with your local models, running entirely on-device when using the Whisper and Transformers options. ### Model Arena (A/B testing) Send the same prompt to multiple models simultaneously in a split-screen view and compare responses. Rate responses, build preference datasets, and understand how different models handle the same task. Useful for evaluating whether it's worth running a larger model for a specific use case. ### Notes A built-in note-taking workspace with Markdown, code blocks, and to-do lists โ€” with AI integration for tone adjustment and style enhancement. Feed notes into conversations and query your LLM about them. A small but useful addition that reduces context switching. ## Open WebUI vs the alternatives **vs LibreChat** โ€” LibreChat is the other major self-hosted chat platform. Open WebUI optimizes for Ollama-first, polished UX and local model workflows. LibreChat optimizes for multi-provider enterprise flexibility (deeper SSO, RBAC, audit logs, plugin marketplace). Open WebUI is prettier and easier to set up. LibreChat is more configurable for large organizations with complex requirements. For most teams, Open WebUI's feature set is sufficient and the setup is faster. **vs LM Studio / Jan** โ€” these are desktop-first, single-user tools. No server, no multi-user, no RAG pipeline. Jan is the simplest possible "run a model, talk to it" experience. Open WebUI is the right choice the moment you need multi-user, document upload, or team sharing. Not competing โ€” they target different use cases. **vs AnythingLLM** โ€” AnythingLLM focuses heavily on document ingestion and workspace organization, with slightly better document management ergonomics. Open WebUI has a more polished chat interface, more model backends, and the Python Functions system for extensibility. Open WebUI is the better choice for teams that need a general-purpose AI platform; AnythingLLM is better if document Q&A is the primary use case (though OpenRAG or Dify may be even better for that). **vs Dify** โ€” Dify is a full LLM application platform (covered on this blog). Open WebUI is a chat interface. They serve different purposes and can coexist: Open WebUI for conversational use, Dify for building structured LLM workflows and applications. Dify's RAG is more production-grade; Open WebUI's chat experience is more polished. ## Practical DevOps use cases * **Private code assistant** โ€” connect a coding-focused model (deepseek-r1, qwen2.5-coder) and use it for code review, refactoring, and generation without sending proprietary code to external APIs * **Internal documentation chat** โ€” upload runbooks and architecture docs to a knowledge base, query them conversationally * **Team AI platform** โ€” give your engineering team a shared ChatGPT-equivalent that routes sensitive work to local Ollama and general work to frontier model APIs * **Model evaluation** โ€” use the Arena feature to A/B test models for specific internal tasks and justify model selection decisions * **Offline environments** โ€” air-gapped infrastructure where no data can leave the network; Open WebUI + Ollama is the answer ## Who it's for **Good fit:** * Teams who want a private ChatGPT-equivalent they control completely * Anyone running local models via Ollama who wants a proper chat interface * Organizations with compliance or data sovereignty requirements ruling out SaaS AI tools * Teams that want to run both local models and frontier model APIs from the same interface * DevOps engineers who want to extend the interface with custom Python functions calling internal APIs **Not the right fit:** * Solo users who just want the simplest possible local model experience โ€” Jan or LM Studio are simpler * Teams primarily building structured LLM applications rather than having conversations โ€” use Dify * Organizations needing deep enterprise governance (RBAC per resource, full audit logs) โ€” consider LibreChat or the Open WebUI Enterprise plan ## My take Open WebUI is the right answer to "my team needs a private AI assistant." The setup is fast โ€” one Docker command if you already have Ollama running. The interface is genuinely polished, comparable to what you'd expect from a commercial product. The model-agnostic architecture means you're never locked in: run local models for sensitive work, route to Claude or GPT for tasks that need frontier capability, all without changing tools. The Python Functions system is the feature that separates it from being just a chat UI. Being able to add custom tools that call your internal APIs, query your databases, or run arbitrary logic โ€” and have the model call those tools automatically โ€” turns Open WebUI into a platform rather than an interface. For DevOps teams who want a private AI assistant that can actually do things in their infrastructure, this is the capability that matters. The 139,000+ stars and a16z backing reflect real community adoption. This is the most-used self-hosted AI platform in the space, which means the most community tooling, the most documented configurations, and the best chance the project stays maintained. For any team running self-hosted infrastructure who hasn't deployed Open WebUI yet, it's worth an afternoon. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help setting up Open WebUI + Ollama? Deploying Open WebUI with Ollama, configuring GPU passthrough correctly, setting up multi-user auth with Authentik OIDC, adding custom Python functions for your internal APIs, and putting it behind Traefik with HTTPS โ€” takes experience to get right the first time. I can handle the full setup and configure it for your team's specific workflow. You get a production-ready private AI platform without spending a day on Docker networking and GPU configuration. Get in touch at pipoline.com โ†’

devopspack.com

Uptime Kuma is the self-hosted monitoring dashboard your team will actually use. Globalping gives it a global probe network so you know whether your service is down everywhere, not just from your server. Here's how both tools work and why they're better together.

Uptime Kuma + Globalping: Self-Hosted Monitoring With Global Visibility

Your monitoring tool knows your service is down. But is it down for everyone, or just from your server? Is it unreachable in South America, or just slow in Germany? Is your CDN routing traffic correctly after that DNS change, or is the old record still resolving in Asia? These questions are what separate uptime monitoring from uptime understanding. Uptime Kuma answers the first question elegantly: is this endpoint up or down? It's self-hosted, MIT licensed, runs on a Raspberry Pi, and has the cleanest monitoring dashboard in the open source space. Globalping answers the second: run a check from anywhere in the world in seconds, using a community-hosted probe network spanning every continent. They integrate natively. Together they give you self-hosted uptime monitoring with global visibility โ€” no paid SaaS required. ## Uptime Kuma Uptime Kuma is a self-hosted monitoring tool created by Louis Lam that does one thing well: tell you when your services go down and alert you immediately. It supports monitoring HTTP/HTTPS domains, keywords on webpages, DNS records, Docker containers, and even databases such as MySQL and SQL. The project has 67,000+ GitHub stars and is one of the most-starred self-hosted tools on GitHub. The current stable release is version 2.x. It's MIT licensed โ€” genuinely open source with no commercial restrictions. ### Monitor types Uptime Kuma supports monitoring for HTTP(s), TCP, HTTP(s) Keyword, HTTP(s) JSON Query, WebSocket, Ping, DNS Record, Push, Steam Game Server, and Docker Containers. The breadth covers most real-world monitoring needs: * **HTTP/HTTPS** โ€” check that a URL returns a 200 and optionally contains a keyword or matches a JSON path * **TCP port** โ€” verify a port is open on any host (databases, mail servers, custom services) * **DNS** โ€” verify DNS records resolve correctly (critical after DNS changes) * **Docker container** โ€” monitor container health state directly from the Docker socket * **Push monitor** โ€” your application sends a heartbeat to Uptime Kuma; if it stops, you get an alert (perfect for cron jobs) * **Ping** โ€” ICMP ping with response time tracking Check intervals go down to 20 seconds โ€” faster than most SaaS monitors. Uptime Kuma's 20-second check interval is genuinely faster than many alternatives' 1-minute minimum. If sub-minute monitoring matters to you, that's a real advantage. Unlimited monitors, no per-monitor pricing. ### Notifications Notifications work via Telegram, Discord, Gotify, Slack, Pushover, Email (SMTP), and 90+ notification services. If you want to send alerts to a niche notification service, Uptime Kuma probably supports it. Webhooks cover custom destinations โ€” pipe alerts into n8n, Windmill, or any automation platform. ### Status pages Uptime Kuma generates public status pages showing the health of your services with uptime history. Useful for communicating service status to users and customers without giving them access to your dashboard. You can add your own domain, custom logo, and select which monitors to include per page. ### Certificate expiry monitoring TLS certificate expiry is tracked automatically on all HTTPS monitors. You get an alert before the certificate expires, with configurable advance warning. Given how many incidents are caused by forgotten certificate renewals, this alone justifies the deployment. ### Self-hosting Uptime Kuma Uptime Kuma is the simplest self-hosted tool to deploy on this entire blog. Single Docker command, SQLite database, no external dependencies: docker run -d \ --restart=unless-stopped \ -p 3001:3001 \ -v uptime-kuma:/app/data \ --name uptime-kuma \ louislam/uptime-kuma:2 Or with Docker Compose: services: uptime-kuma: image: louislam/uptime-kuma:2 container_name: uptime-kuma restart: unless-stopped ports: - "3001:3001" volumes: - ./uptime-kuma-data:/app/data Navigate to `http://your-server:3001`, create your admin account, add your first monitor. Done. Put Traefik in front for HTTPS and a clean domain. Minimum requirements: 512MB RAM, single CPU โ€” runs comfortably on a Raspberry Pi. ## Globalping Globalping is a community-powered platform for running network measurements from anywhere in the world. Globalping is a platform that allows anyone to run networking commands such as ping, traceroute, dig, curl, and mtr on probes distributed all around the world. The project is developed by the jsDelivr team โ€” the same team that runs one of the world's largest CDN networks โ€” and is fully open source. At peak, Globalping handles 2 million+ tests per day. The probe network spans hundreds of cities across every continent, including residential ISP networks (eyeball networks) that data-center-only monitoring can't replicate. The core architecture: anyone can run a probe by spinning up a Docker container. That probe joins the global network and contributes its location to the pool. The probes will only issue an outgoing WebSocket connection to the Probe Management Module. There are no open ports on the probe, nor will it ever accept any incoming connections, limiting the risk of unauthorized access or attacks against the probe itself. ### What Globalping can measure * **Ping** โ€” ICMP or TCP ping with RTT and packet loss from any location * **Traceroute** โ€” visualize routing paths across the world * **DNS lookup** โ€” verify DNS resolution from specific regions, ISPs, or cities * **HTTP** โ€” full HTTP request with response headers, TLS details, and timing * **MTR** โ€” combined ping and traceroute for detailed network path analysis ### Location targeting Location selection is Globalping's most powerful feature. You can be as broad or precise as you need: * `world` โ€” random probe anywhere * `Germany` โ€” random probe in Germany * `Germany+datacenter-network` โ€” German probe on stable datacenter infrastructure * `comcast+california` โ€” Comcast ISP probe in California (eyeball network) * `AS13335` โ€” any probe on Cloudflare's ASN * `us-east-1` โ€” cloud region targeting This granularity is what makes Globalping genuinely useful for real-world debugging. "Is this DNS change propagated in Germany?" becomes a one-command answer. ### CLI and free tier # Install npm install -g @globalping/cli # Ping devopspack.com from Germany globalping ping devopspack.com from Germany # DNS check from multiple locations globalping dns devopspack.com from world --limit 5 # HTTP check from Brazil globalping http devopspack.com from Brazil --protocol HTTPS Anonymous usage gets 250 free tests per hour with up to 50 probes per measurement โ€” sufficient for most teams. Create a free account to increase limits. Running your own probe earns credits. Become a GitHub Sponsor for $10/month and get a hardware probe to install in your home or office network. ## Uptime Kuma + Globalping โ€” the native integration This is where both tools become genuinely more valuable together. With a typical Uptime Kuma setup, you monitor from the location where the tool is running. Now that Globalping is integrated, Uptime Kuma can offer you more than single-location monitoring: you can monitor from anywhere. Setting up a Globalping monitor in Uptime Kuma: 1. Add a new monitor in Uptime Kuma 2. Select **"Globalping - Access global monitoring probes"** from the Monitor Type dropdown 3. Configure the subtype: `ping`, `dns`, or `http` 4. Set the hostname: your domain or IP 5. Set the location: `world`, `Germany+datacenter-network`, `Brazil`, or any Globalping location string 6. Optionally add your Globalping API token under Settings โ†’ About to increase your free test limits You can fine-tune probe selection and tell Globalping where you want to monitor from. You can provide locations such as continents, countries, cities, ASNs, networks, and network types. Practical monitoring setups with the combination: * **Primary monitoring** โ€” local HTTP monitor every 60s for fast alerting on your local server * **Global availability** โ€” Globalping HTTP monitor from `world` every 5 minutes to confirm global reachability * **Region-specific** โ€” Globalping DNS monitors from EU, US, and Asia to verify DNS propagation after changes * **ISP coverage** โ€” Globalping ping from eyeball networks to verify end-user reachability, not just datacenter reachability # Example: verify CDN is routing correctly post-deployment globalping http devopspack.com from EU --limit 10 --protocol HTTPS # Check DNS propagation globalping dns devopspack.com from world --limit 20 --type A ## The broader monitoring picture Uptime Kuma and Globalping cover uptime and availability. They don't replace a full observability stack (Grafana + Prometheus for metrics, SigNoz for traces and logs). The right mental model: * **Uptime Kuma** โ€” is it up? Alert me when it's not. Status page for my users. * **Globalping** โ€” is it up everywhere? What does the routing look like from Japan? * **Grafana + Prometheus** โ€” how is it performing? Memory, CPU, request latency, error rates. * **SigNoz** โ€” why did that request fail? Trace it through the stack. Each tool has a clear job. Uptime Kuma + Globalping handles the "is it reachable?" layer simply and for free. ## Who it's for **Uptime Kuma:** * Any team running self-hosted services who wants to know immediately when something goes down * Teams that need a public-facing status page without paying for Statuspage * Anyone running cron jobs who wants heartbeat monitoring * Solo developers who want UptimeRobot's functionality without the limitations and data leaving their server **Globalping:** * Teams debugging CDN, DNS, or routing issues and needing multi-location visibility * Anyone who has ever asked "is it down just for me?" and wanted a real answer * DevOps teams verifying DNS propagation after DNS changes * Teams with global users who need to verify availability from specific regions or ISPs ## My take Uptime Kuma is the monitoring tool I recommend to every team that isn't already running one. The deployment is trivial, the interface is genuinely pleasant to use, the notification integrations cover everything, and the 20-second check interval beats most paid alternatives. It earns its 67,000+ stars. Just deploy it. Globalping solves a problem that sounds simple but is surprisingly hard: how do you know your service is reachable from a residential connection in Brazil, or from a Comcast subscriber in California, without maintaining probes in those places? The community probe network is the answer, and the integration with Uptime Kuma means you get global monitoring without building anything beyond your existing self-hosted stack. The combination gives you what teams typically pay hundreds of dollars a month for (Pingdom, Better Uptime, Checkly) for the cost of infrastructure and one Docker container. For any team running a self-hosted stack, this is the monitoring setup I'd start with. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help setting up monitoring for your stack? Deploying Uptime Kuma, configuring monitors across your self-hosted services, wiring Globalping for global coverage, setting up notification channels, and building a status page โ€” takes an afternoon done properly. I can set up a complete monitoring layer for your infrastructure and connect it to your alerting workflow. You get visibility from day one. Get in touch at pipoline.com โ†’

devopspack.com

Windmill turns scripts into APIs, webhooks, scheduled jobs, and auto-generated UIs โ€” without the infrastructure overhead. AGPLv3 open source, 13x faster than Airflow, self-hostable on Docker or Kubernetes. The developer platform that replaces a shelf of internal tools.

Windmill: Turn Scripts Into Workflows, APIs, and Internal Apps

Every engineering team eventually builds the same things: a cron job that syncs data between systems, a script that rotates API keys, an admin panel that lets ops trigger a workflow without SSH access, a data pipeline that runs nightly and needs to be monitored. Each of these starts as a quick script and ends up as a maintenance burden โ€” deployed somewhere nobody remembers, undocumented, and definitely not tested. Windmill is the platform that consolidates all of it. Write a script in Python, TypeScript, Go, Bash, or SQL โ€” Windmill turns it into an API endpoint, a scheduled job, a webhook handler, and an auto-generated UI that non-engineers can trigger safely. Chain scripts into visual workflows. Build internal apps on top of them. Keep everything in Git. That's the entire value proposition, and it's genuinely compelling. ## What Windmill is Windmill is an open-source developer platform and workflow engine for building, deploying, and monitoring internal automation and tooling at scale. It's written in Rust (backend) with a Svelte frontend and PostgreSQL as the only database dependency. **AGPLv3 licensed** , self-hostable, and benchmarked at 13x faster than Airflow for workflow execution. The platform has three distinct layers that work together: * **Scripts** โ€” single-file programs in Python, TypeScript, Go, Bash, SQL, Rust, GraphQL, PowerShell, and more. Each script gets an auto-generated form UI, an API endpoint, a webhook, and can be scheduled as a cron job โ€” automatically, with no boilerplate. * **Flows** โ€” visual workflow editor for chaining scripts into multi-step pipelines with branching, parallelism, retries, error handling, and human-in-the-loop approval steps. * **Apps** โ€” low-code app builder for creating internal dashboards and tools that trigger workflows and scripts through custom UIs, with granular permissions so non-engineers can use them safely. Windmill is a Y Combinator company used in production at organizations including Pave, Investing.com, and others running hundreds of scripts and flows in business-critical automations. ## The license โ€” AGPLv3 with commercial carve-outs Windmill's core is AGPLv3 โ€” one of the strongest copyleft licenses. The key implications: * **Self-hosting for internal use** : completely free, no license required * **Using Windmill's APIs internally** : completely free * **Wrapping Windmill in your SaaS product to offer to customers** : requires a commercial license from Windmill Labs, or your product must be AGPLv3 Enterprise features (SAML SSO, audit logs, distributed dependency cache backed by S3, global cache sync for large clusters) are available in the Enterprise Edition. For self-hosted internal use, the Community Edition covers everything most teams need: the full workflow engine, all script languages, flows, apps, secrets management, scheduling, webhooks, and Git sync. ## Scripts โ€” the foundation The script is Windmill's atomic unit. Write a function with typed parameters, and Windmill handles everything else automatically. A Python script that takes a username and plan might look like: # upgrade_user.py # Requirements: psycopg2-binary import psycopg2 def main(username: str, plan: str, notify: bool = True) -> dict: """Upgrade a user's plan in the database.""" conn = psycopg2.connect(wmill.get_resource("u/admin/postgres_prod")) # ... query logic return {"upgraded": username, "plan": plan} Windmill reads the type hints, generates a form with the right input types (text field for username, dropdown for plan, checkbox for notify), creates an API endpoint at `/api/w/{workspace}/jobs/run/p/{path}`, adds a webhook URL, and makes it schedulable as a cron job. The dependencies (`psycopg2-binary`) are installed and cached automatically โ€” no Dockerfile, no requirements.txt to maintain separately, no deployment pipeline to set up. Resources (database credentials, API keys, OAuth tokens) are stored encrypted in Windmill and injected into scripts via `wmill.get_resource()`. Scripts never contain credentials directly โ€” they reference named resources that are managed centrally with granular access controls. ## Flows โ€” visual workflow orchestration Flows chain scripts together into multi-step workflows using a visual editor. Each step is a script โ€” from your workspace, from WindmillHub (the community script library), or written inline. The flow editor supports: * **Branching** โ€” conditional logic that routes to different steps based on previous output * **Parallelism** โ€” fan out to multiple steps running concurrently, then collect results * **For-each loops** โ€” iterate over a list with each item processed as a separate job * **Error handling** โ€” retry policies, error branches, and compensation steps * **Human-in-the-loop** โ€” suspend the workflow and send an approval request via email, Slack, or a form; resume when approved * **Input transforms** โ€” JavaScript expressions that transform the output of one step into the input of the next Flows are version-controlled, testable at each step, and can be triggered the same ways as scripts: API, webhook, schedule, or app button. ## Workflow-as-code โ€” the newest capability Launched in April 2026, workflow-as-code lets you define complex workflows entirely in TypeScript or Python using `@workflow` and `@task` annotations. This is the same model as Temporal or Inngest โ€” durable execution, checkpointing, parallelism โ€” but with zero additional infrastructure and standard language tooling: // etl_pipeline.ts import { task, workflow } from "windmill-client"; @workflow export async function etlPipeline(source: string, dest: string) { const data = await task(extractData, { source }); const transformed = await Promise.all( data.chunks.map(chunk => task(transformChunk, chunk)) ); await task(loadData, { records: transformed.flat(), dest }); return { loaded: transformed.flat().length }; } @task async function extractData(source: string) { /* ... */ } @task async function transformChunk(chunk: object) { /* ... */ } @task async function loadData(records: object[], dest: string) { /* ... */ } Each `task()` call runs as a separate Windmill job โ€” logged, retryable, with its own timeline entry. Between tasks, **the workflow fully suspends and releases its worker**. A workflow sleeping for 24 hours consumes zero worker resources during the wait. A workflow with 100 parallel tasks doesn't hold 100 workers simultaneously. This is durable execution without the operational complexity of running Temporal. ## Git sync and local development Windmill keeps everything in Git. A synced workspace looks like: f/ โ”œโ”€โ”€ etl/ โ”‚ โ”œโ”€โ”€ stripe_to_postgres.flow.yaml โ”‚ โ””โ”€โ”€ stripe_to_postgres/ โ”‚ โ”œโ”€โ”€ fetch_invoices.ts โ”‚ โ””โ”€โ”€ transform.py โ”œโ”€โ”€ devops/ โ”‚ โ””โ”€โ”€ rotate_iam_keys.ts โ”œโ”€โ”€ apps/ โ”‚ โ””โ”€โ”€ billing_dashboard.app/ โ”œโ”€โ”€ resources/ โ”‚ โ”œโ”€โ”€ postgres_prod.resource.yaml โ”‚ โ””โ”€โ”€ slack_webhook.resource.yaml โ””โ”€โ”€ schedules/ โ””โ”€โ”€ stripe_sync.schedule.yaml Scripts, flows, apps, resources, and schedules all live in version control. Pull requests for changes to automation. Diffs that show exactly what changed. Rollback by reverting a commit. The `wmill sync push` command deploys changes from your local machine or CI/CD pipeline. Windmill also has a VS Code extension for local development with IDE features (autocomplete, type checking) and preview against your remote instance. ## Triggers Scripts and flows can be triggered by: * **Schedule** โ€” cron expressions, with monitoring and alerting on failure * **Webhook** โ€” unique URL per script/flow, supports sync and async execution * **HTTP routes** โ€” custom REST API routes your scripts serve * **Kafka / WebSocket / Email** โ€” event-driven triggers for reactive workflows * **Slack command** โ€” trigger flows directly from Slack * **App button** โ€” UI buttons in Windmill apps * **CLI** โ€” `wmill run` for local execution ## Self-hosting Windmill Docker Compose is the standard path. The stack is lean compared to most platforms โ€” Windmill server, workers, and PostgreSQL: # Clone the docker-compose setup git clone https://github.com/windmill-labs/windmill cd windmill # Configure your .env (set WM_BASE_URL, SECRET_KEY, etc.) cp .env.example .env # Start docker compose up -d The default setup runs the server (stateless API), workers (pull jobs from the Postgres queue), and PostgreSQL. Add more workers by scaling the worker service horizontally โ€” Windmill's architecture is stateless API + worker pool + Postgres queue, so horizontal scaling is straightforward. Minimum viable server: 2 CPU cores and 2GB RAM for small workloads. Production with parallel workflows and many concurrent jobs benefits from more worker replicas and a dedicated database. A Helm chart is available for Kubernetes deployments. ## Windmill vs the alternatives **vs n8n** โ€” n8n is a visual automation platform focused on connecting SaaS APIs with no-code blocks. Windmill is code-first โ€” you write real programs and the platform handles the infrastructure. n8n is better for non-technical users and API integration workflows. Windmill is better for engineering teams who want real code, version control, and production-grade orchestration. They serve different primary audiences. **vs Airflow** โ€” Airflow is the incumbent for data pipeline orchestration, Python-based, DAG-driven. Windmill benchmarks at 13x faster for task execution, supports more languages, and has a significantly better developer experience (no Airflow DAG boilerplate, no Celery to manage, no separate webserver/scheduler/worker architecture). For new projects, Windmill is the better choice for most data pipeline use cases. For organizations already deep in Airflow, the migration cost matters. **vs Temporal** โ€” Temporal is the gold standard for durable workflow execution at scale โ€” used at Stripe, Netflix, and others. It's also complex to operate: separate server, history service, matching service, and frontend service, plus SDK boilerplate. Windmill's workflow-as-code feature covers the core Temporal use case (durable execution, checkpointing, parallelism) with much lower operational complexity. For most teams, Windmill is sufficient. For Temporal-scale requirements (millions of concurrent workflows), Temporal's maturity is worth the operational cost. **vs Retool** โ€” Retool is a proprietary internal tools platform. Windmill's App builder covers the same use case โ€” internal dashboards, admin panels, ops tools โ€” with the code-first advantage that scripts underlying the UI are reusable in workflows, and everything is in Git. Retool wins on UI polish; Windmill wins on data sovereignty, cost, and code ownership. **vs Prefect / Dagster** โ€” these are Python-first data orchestration platforms with strong data engineering ecosystems. Windmill covers data pipeline use cases but is more general-purpose. For teams primarily building data pipelines with Python, Prefect or Dagster's richer data-specific features (lineage, asset management, data catalog) may be worth the specialization. For teams building a mix of data pipelines, internal tools, and automation, Windmill's unified platform avoids running multiple systems. ## Who it's for **Good fit:** * Engineering teams with a shelf of scripts and cron jobs they want to consolidate into one observable, version-controlled platform * Teams that want to give non-engineers safe access to trigger engineering workflows without SSH access * Organizations building data pipelines, ETL jobs, and automation that want production-grade orchestration without Airflow's complexity * Teams replacing Retool or Airplane with an open source, self-hostable alternative * DevOps teams who want to automate infrastructure operations with a developer-friendly platform **Not the right fit:** * Non-technical users who want pure no-code automation โ€” n8n or Make are simpler * Teams that need deep data catalog, lineage, and asset management โ€” Dagster or Prefect are more specialized * Organizations building consumer-facing products โ€” Windmill is for internal tooling ## My take Windmill solves the "script graveyard" problem โ€” the accumulation of undocumented scripts, cron jobs running on forgotten servers, and ad-hoc automations that only the person who wrote them can operate. By turning scripts into first-class, observable, version-controlled, triggerable artifacts with auto-generated UIs, Windmill makes the gap between "someone wrote a script" and "anyone on the team can run this safely" disappear. The workflow-as-code feature is the most interesting recent development. Getting Temporal-style durable execution without running Temporal's infrastructure is a meaningful practical improvement for teams that need it. The two-annotation model โ€” `@workflow` and `@task` on regular TypeScript or Python functions โ€” is elegant and the zero-worker-consumption-during-wait architecture is correct. For DevOps teams specifically, Windmill is the platform I'd use to consolidate infrastructure automation: key rotation scripts, database maintenance jobs, deployment triggers, incident response runbooks that need a UI. The resource management (credentials stored centrally, referenced by name) and the approval workflow (suspend until a human approves, zero resources consumed while waiting) are exactly the right primitives for operational tooling. The AGPLv3 license means you run it internally for free forever. Self-hosting on the same server running your other tools โ€” Gitea, Traefik, Outline, Plane โ€” adds negligible overhead for the capabilities it delivers. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help setting up Windmill? Getting Windmill into production โ€” Docker Compose, worker scaling, Git sync configuration, resource setup for your databases and APIs, Traefik for HTTPS, and migrating your existing scripts and cron jobs into Windmill workflows โ€” takes an afternoon to do properly. I can handle the full setup and build your first few workflows so your team sees the value immediately. Get in touch at pipoline.com โ†’

devopspack.com

OpenRAG is the single-command RAG platform from IBM and Langflow โ€” Docling for document parsing, OpenSearch for semantic search, Langflow for visual workflow orchestration, and a built-in MCP server so your AI tools can query your knowledge base directly. Zero RAG plumbing required.

OpenRAG: Single-Command RAG Platform Built on Langflow, Docling, and OpenSearch

Building a production-grade RAG pipeline from scratch in 2026 still takes weeks. You need a document parser that handles messy real-world formats, a vector store that scales, an orchestration layer for retrieval workflows, and a frontend your team can actually use. Then you need to wire all of it together, debug why the chunking strategy loses important context, and figure out why retrieval quality drops at scale. OpenRAG collapses that entire stack into one deployable package. It's an open-source RAG platform from IBM and the Langflow team that combines three best-in-class components โ€” Langflow for agentic workflow orchestration, OpenSearch for production-grade semantic search, and Docling for intelligent document parsing โ€” and ships them together with a web UI, REST API, Python and TypeScript SDKs, and a built-in MCP server. From zero to a functional document Q&A system in one command. ## What OpenRAG is OpenRAG is a comprehensive, single-package RAG platform that enables intelligent document search and AI-powered conversations. Users upload documents through a drag-and-drop interface, and the platform handles parsing, chunking, embedding, indexing, and retrieval automatically. The chat interface returns answers with source citations. Under the hood it's an agentic workflow powered by Langflow that you can inspect and customize. The project lives at github.com/langflow-ai/openrag and openr.ag. It has approximately 1,000 GitHub stars with 95 forks and 51 releases, including the 0.3.0 milestone shipped in March 2026. Built by the Langflow team in collaboration with IBM's open source AI ecosystem. ## The three components ### Docling โ€” document parsing Docling is IBM Research's open source document parsing library that handles real-world document formats intelligently. PDF, Word, PowerPoint, HTML, images, scanned copies, Excel โ€” Docling extracts structured content including tables, figures, and complex layouts that naive text extractors mangle. For RAG systems, document parsing quality is the first failure point: if the chunking strategy doesn't understand document structure, retrieval quality suffers from the start. Docling's layout-aware parsing is what makes OpenRAG handle enterprise document formats that other RAG systems struggle with. ### OpenSearch โ€” semantic search OpenSearch (Apache 2.0, the AWS-maintained Elasticsearch fork) is the vector store and search backend. It provides hybrid search combining dense vector similarity with BM25 keyword matching. OpenSearch stores document chunks with their embeddings and handles both semantic similarity queries and exact keyword retrieval, with configurable weighting between the two signals. ### Langflow โ€” workflow orchestration Langflow is the visual workflow builder that orchestrates the entire RAG pipeline. Every step โ€” document ingestion, chunking strategy, embedding model selection, retrieval, re-ranking, LLM call, response generation โ€” is a node in a visual graph you can inspect, modify, and debug. When retrieval fails you can see exactly where in the pipeline it failed, without instrumenting code yourself. Langflow also handles the agentic features โ€” multi-agent coordination, re-ranking workflows, and intelligent nudges that steer the system toward better answers. ## Features * **Pre-packaged and ready to run** โ€” all components are wired together out of the box * **Agentic RAG workflows** โ€” advanced orchestration with re-ranking and multi-agent coordination * **Document ingestion** โ€” drag-and-drop upload via web UI or programmatic upload via API * **Visual workflow builder** โ€” Langflow canvas for inspecting and customizing every pipeline step * **REST API** โ€” every operation available as an API endpoint * **Python and TypeScript SDKs** โ€” official SDKs for programmatic access * **Built-in MCP server** โ€” mounted at /mcp on your instance for IDE and AI tool integration * **Source citations** โ€” answers include traceable citations linking to source documents * **Kubernetes and Docker support** โ€” Helm charts, Docker Compose, GPU support included ## SDK examples from openrag import OpenRAGClient client = OpenRAGClient() response = client.chat.create( message="What does our security policy say about access control?" ) print(response.response) print(response.citations) import { OpenRAGClient } from "openrag-sdk"; const client = new OpenRAGClient(); const response = await client.chat.create({ message: "Summarize our Q1 engineering report" }); console.log(response.response); ## Getting started git clone https://github.com/langflow-ai/openrag cd openrag docker compose up Navigate to the web interface, upload your documents, and start asking questions. The entire stack โ€” OpenSearch, Langflow, Docling, the FastAPI backend, and the Next.js frontend โ€” comes up together. No separate configuration of each component, no wiring together endpoints manually. ## The MCP server โ€” queryable documentation from your IDE Every OpenRAG instance includes an MCP (Model Context Protocol) server at `/mcp`. MCP is the protocol that lets AI tools like Cursor, Claude Desktop, and VS Code extensions call external tools as part of their reasoning loop. In practice: upload your team's documentation to OpenRAG โ€” architecture docs, runbooks, API specs, incident reports, onboarding guides โ€” and query it directly from your IDE. Cursor can call your OpenRAG instance to retrieve relevant documentation while you're writing code. Claude Desktop can query your runbooks when you're debugging an incident. Any MCP-compatible tool accesses your knowledge base as a tool in its reasoning loop. This is what distinguishes OpenRAG from a simple document Q&A tool. It's your entire documentation corpus becoming a queryable tool available to every AI assistant your team uses โ€” automatically, from the IDE. ## OpenRAG vs alternatives **vs Dify** โ€” Dify is a full LLM application platform with visual workflows, RAG, agents, and more. OpenRAG is narrower: specifically a RAG platform optimized for document search, built on three best-in-class components rather than a single vertically-integrated platform. Dify's broader scope means more features but more complexity. OpenRAG's focused scope means faster setup for document Q&A with agentic retrieval. **vs RAGFlow** โ€” RAGFlow (infiniflow) is a dedicated open source RAG engine with 46,000+ stars and strong enterprise focus: deep document understanding, complex format support, and a mature agent framework. RAGFlow is more mature and feature-complete. OpenRAG is newer, easier to set up, and has the MCP server and Langflow visual workflow builder as differentiators. **vs building on Langflow directly** โ€” OpenRAG is essentially a pre-configured, production-ready Langflow deployment with OpenSearch and Docling pre-wired. OpenRAG trades flexibility for speed โ€” you can still customize the Langflow workflows, but the initial setup is handled. **vs Supabase + pgvector** โ€” Supabase with pgvector is excellent for applications needing vector search alongside relational data. OpenRAG is optimized specifically for document ingestion and retrieval at scale with OpenSearch providing better performance for large document corpora. ## DevOps use cases * **Runbook Q &A** โ€” upload all your runbooks and query them via MCP from Cursor or Claude Desktop during incidents * **Architecture documentation search** โ€” upload ADRs and search them semantically * **Compliance and audit documentation** โ€” make compliance policies queryable for security questionnaires * **Onboarding knowledge base** โ€” new engineers query docs from their IDE without switching context * **Post-mortem search** โ€” upload incident reports and find similar past incidents when diagnosing a new one ## Who it's for **Good fit:** * Engineering teams who want a complete RAG platform without building the stack themselves * Teams who want documentation queryable from their IDE via MCP * Organizations building internal knowledge bases on top of enterprise documents (PDF, Word, PowerPoint) * Teams already using Langflow who want a pre-configured RAG deployment * IBM ecosystem users who want Docling + OpenSearch in a ready-to-deploy package **Not the right fit:** * Teams that need a general-purpose LLM application builder โ€” use Dify or Langflow standalone * Teams that need mature enterprise RAG with proven scale โ€” RAGFlow is more mature at 46k stars * Simple single-document Q&A where a direct LLM call with context is enough ## My take OpenRAG solves a real problem: the gap between "I want to chat with my documents" and "I have a production RAG pipeline that actually works." Most teams that try to build RAG from scratch underestimate how much work the document parsing layer is, how much retrieval quality depends on chunking strategy, and how hard it is to debug why the system returns wrong answers. OpenRAG packages the right components for each job โ€” Docling for parsing, OpenSearch for search, Langflow for orchestration โ€” and pre-wires them together. The MCP server is the feature I'd highlight to any engineering team. Having your documentation corpus queryable from Cursor or Claude Desktop changes how you interact with your own knowledge base. It's the difference between "I need to find that runbook" and "I'll ask about it while I'm debugging." That workflow improvement alone justifies the deployment overhead. At ~1,000 GitHub stars, OpenRAG is young compared to RAGFlow or Dify. The IBM and Langflow team backing gives it credibility, but it hasn't yet accumulated the community validation that older projects have. Worth watching โ€” and worth deploying if the use case fits. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help deploying OpenRAG? Getting OpenRAG into production โ€” Docker Compose or Kubernetes, GPU configuration for local embeddings, Traefik for HTTPS, MCP server setup for your IDE integrations, and ingesting your existing documentation corpus โ€” is straightforward once you know the steps. I can handle the full deployment and set up MCP connections to your team's tools. You get a production-ready RAG platform with your documentation queryable from day one. Get in touch at pipoline.com โ†’

devopspack.com

Gitea is the lightweight self-hosted GitHub alternative โ€” single Go binary, 55k+ stars, GitHub Actions compatibility, runs on a Raspberry Pi. There's also Forgejo, its community fork that many now recommend instead. Here's what both are and when to pick which.

Gitea and Forgejo: Self-Hosted GitHub Alternative That Runs on a Raspberry Pi

Every team that reaches for self-hosted infrastructure eventually asks the same question about their code: do we really want our repositories on GitHub or GitLab's servers? GitHub is fine until it isn't โ€” acquisition concerns, outages, pricing changes, or simply the principle that production infrastructure should live somewhere you control. GitLab self-hosted solves this but brings a significant operational footprint with it. Gitea sits in the middle: the GitHub-style experience you're used to โ€” repositories, pull requests, issues, releases, CI/CD โ€” in a single Go binary that runs on hardware as modest as a Raspberry Pi. This post covers Gitea, its community fork Forgejo, when to choose each, and how to get either running in production. ## What Gitea is Gitea is a self-hosted Git service written in Go. It started in 2016 as a community fork of Gogs, motivated by Gogs' slow release pace, and has grown into the most popular standalone open source Git server with **55,000+ GitHub stars**. The core bet: pack GitHub's core feature set into a single binary with no runtime dependencies, deployable anywhere from a Raspberry Pi to a Kubernetes cluster. It's MIT licensed. One binary, a database (SQLite for small setups, PostgreSQL for production), and optional Redis for caching. That's the entire stack. Updates are a binary swap. The feature set covers everything a development team actually needs day-to-day: * **Git hosting** โ€” repositories, branches, tags, releases, Git LFS * **Code review** โ€” pull requests with inline comments, review requests, protected branches * **Issues and projects** โ€” issue tracker, milestones, labels, kanban-style project boards * **Gitea Actions** โ€” CI/CD using the same YAML syntax as GitHub Actions, with the open source `act_runner` executor * **Container registry** โ€” Docker image hosting built in, no separate registry required * **Package registry** โ€” npm, PyPI, Maven, NuGet, Cargo, Helm, and more * **Wiki** โ€” per-repository wikis backed by Git * **Webhooks and API** โ€” REST API covering all resources, compatible with many GitHub API clients * **OAuth2 and LDAP** โ€” sign in with GitHub, Google, GitLab, or any OIDC provider; LDAP/Active Directory integration ## The Forgejo fork โ€” and why it matters in 2026 In late 2022, several long-time Gitea contributors and maintainers objected to governance decisions around the project โ€” specifically concerns about the Gitea company potentially holding back features for a commercial tier and the lack of democratic project oversight. Those contributors forked the project as **Forgejo** (pronounced "for-JAY-oh"), now governed by an elected council under the umbrella of Codeberg e.V., a German non-profit. This matters because Forgejo and Gitea have diverged in meaningful ways since the fork: * **License** โ€” Forgejo uses GPL v3 (copyleft), Gitea uses MIT. For organizations with procurement policies around copyleft, this matters. * **Governance** โ€” Forgejo has an elected council, public roadmap discussions, and no commercial entity. Gitea has a company (Gitea Limited) that makes decisions. * **ActivityPub federation** โ€” Forgejo is implementing ForgeFed, which will allow repositories and issues to federate across instances the way Mastodon federates across social servers. Gitea's roadmap on federation is less clear. * **Forgejo Actions** โ€” shipped GitHub Actions compatibility before Gitea Actions did. Both now have it. * **API compatibility** โ€” both share the same database schema and API at the core, so migration between them is straightforward. The practical recommendation in 2026: **for most new self-hosters, Forgejo is the safer default**. Better governance, no commercial entity, more aggressive federation roadmap. If you need Gitea Enterprise features (SAML, advanced audit logs) or are deeply invested in the existing Gitea ecosystem, Gitea remains a valid choice. But if you're starting fresh, Forgejo is where the community momentum is. ## Gitea Actions โ€” the feature that removes the migration blocker The biggest practical objection to leaving GitHub has always been the CI/CD rewrite cost. GitHub Actions has become the de facto standard for CI/CD workflows, with a huge ecosystem of pre-built actions and workflows. Rewriting everything to a different syntax is expensive. Gitea Actions (and Forgejo Actions) uses the **same YAML syntax as GitHub Actions**. Many workflows migrate with minimal changes: # .gitea/workflows/ci.yml (or .forgejo/workflows/ci.yml) name: CI on: push: branches: [main] pull_request: jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Run tests run: | go test ./... go build ./... The runner is `act_runner` โ€” a separate binary you deploy alongside Gitea that picks up jobs and executes them. You register runners against your instance, and they appear in the CI/CD dashboard exactly like GitHub-hosted runners. Not every GitHub Actions feature translates โ€” some marketplace actions have GitHub-specific dependencies, and the hosted runner ecosystem is smaller. But for standard build/test/deploy workflows, the compatibility is high enough that most teams can migrate without rewriting from scratch. ## Self-hosting Gitea Docker Compose is the simplest production path. Gitea with PostgreSQL: services: gitea: image: gitea/gitea:latest container_name: gitea restart: unless-stopped environment: USER_UID: 1000 USER_GID: 1000 GITEA__database__DB_TYPE: postgres GITEA__database__HOST: db:5432 GITEA__database__NAME: gitea GITEA__database__USER: gitea GITEA__database__PASSWD: ${POSTGRES_PASSWORD} volumes: - ./gitea-data:/data ports: - "3000:3000" - "2222:22" # SSH clone port depends_on: - db db: image: postgres:16 restart: unless-stopped environment: POSTGRES_DB: gitea POSTGRES_USER: gitea POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} volumes: - ./postgres-data:/var/lib/postgresql/data For Forgejo, replace `gitea/gitea:latest` with `codeberg.org/forgejo/forgejo:latest`. The rest is identical. Put Traefik in front for HTTPS and you have a complete Git hosting platform. Minimum viable server: 512MB RAM (SQLite) or 1GB+ (PostgreSQL). Gitea idles at around 400MB โ€” compared to GitLab's multi-GB footprint, this is a dramatic difference. A few production considerations: * **SSH port** โ€” expose port 22 or 2222 for SSH cloning. Without it, users are HTTPS-only. * **SMTP** โ€” configure for email notifications, password resets, and user registration emails. * **Storage** โ€” Git LFS and package registry artifacts need persistent storage. Plan accordingly. * **Backups** โ€” the `gitea-data` volume and PostgreSQL database are what you need to back up. Simple, predictable. ## Migration from GitHub Gitea and Forgejo both ship built-in migration tools that import from GitHub, GitLab, Bitbucket, and other Gitea/Forgejo instances โ€” including issues, pull requests, wiki pages, releases, and labels. The built-in importer handles most of it automatically. Author re-attribution requires each user to log in at least once before their commits get linked to their account โ€” commits aren't retroactively re-attributed, but new activity will be. For large organizations migrating many repositories, the REST API allows scripted migration. The GitHub-to-Gitea/Forgejo path is the cleanest โ€” better tooling and more predictable results than migrating from GitLab. ## Gitea vs GitLab vs GitHub **vs GitHub** โ€” GitHub has the network effect, the Actions marketplace, Copilot, and the world's open source community. Gitea/Forgejo replaces the code hosting, pull requests, issues, and CI/CD โ€” not the social graph. If your team needs to publish open source or wants contributors to find your code organically, GitHub's network is irreplaceable. For private team code hosting, Gitea/Forgejo is a completely viable alternative. **vs GitLab CE** โ€” GitLab is feature-complete and deeply integrated, but it comes with a multi-service stack (Sidekiq, Puma, Redis, PostgreSQL, MinIO, the list goes on) that requires 4-8GB of RAM minimum and dedicated server expertise to operate. Gitea/Forgejo runs at a tenth of the resource cost. GitLab CE wins on advanced security scanning (SAST, DAST, dependency scanning), compliance features, and the depth of its CI/CD system. Gitea/Forgejo wins on operational simplicity. The practical rule: if you have a dedicated platform team and need GitLab's feature depth, run GitLab. If you want Git hosting that just works on a modest server, run Gitea or Forgejo. ## Who it's for **Good fit:** * Teams who want GitHub-style code hosting on their own infrastructure without GitLab's operational overhead * Organizations with data sovereignty requirements โ€” source code can't live on GitHub or GitLab.com * Small to medium engineering teams (1-50 developers) who want a complete Git platform without dedicated DevOps to maintain it * Self-hosters who want Git hosting alongside their other self-hosted tools (Plane, Outline, Dokploy, etc.) * Teams already on GitHub Actions who want to self-host CI/CD without rewriting workflows **Not the right fit:** * Teams that need GitLab's advanced security scanning (SAST, DAST) โ€” stick with GitLab * Organizations that need the GitHub network effect for open source contributions * Teams that need Gitea Enterprise features (SAML, advanced audit logs) on the free tier โ€” those are paid ## My take Gitea and Forgejo are the answer to "we want GitHub-style code hosting, we want to own the data, and we don't want to run GitLab." That's a real requirement for a lot of teams, and both tools deliver on it cleanly. The Forgejo fork is the more interesting story in 2026. The governance improvements are meaningful โ€” having a non-profit council rather than a commercial entity making roadmap decisions matters for projects you intend to run for years. The ActivityPub federation work is ambitious and genuinely novel: if it ships well, it could change how open source collaboration works by removing the dependency on any single centralized forge. For a new self-hosted deployment today: start with Forgejo. It's a drop-in Gitea replacement with better governance and a more transparent roadmap. The migration path between the two is well-documented if you ever need to switch. The resource footprint is negligible โ€” add it to the same server running Traefik, Plane, and Outline and you barely notice it's there. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help setting up Gitea or Forgejo? Getting Gitea or Forgejo into production โ€” Docker Compose, PostgreSQL, SSH configuration, Traefik for HTTPS, SMTP, act_runner for Actions, and migrating your repositories from GitHub โ€” takes an afternoon to do properly. I can handle the full setup and migrate your existing repositories, issues, and CI/CD workflows. You get a production-ready self-hosted Git platform without the GitLab overhead. Get in touch at pipoline.com โ†’

devopspack.com

Fleet is the open source MDM that manages macOS, Windows, Linux, iOS, and Android from one platform โ€” with GitOps workflows, osquery-powered visibility, and no vendor lock-in. Here's what makes it different from Jamf and Intune.

Fleet: Open Source MDM With GitOps and Cross-Platform Device Management

Every organization with more than a handful of laptops eventually needs device management. You need to know what's installed, enforce security policies, push software, patch vulnerabilities, and prove compliance to auditors. The traditional answer is Jamf for Macs or Microsoft Intune for Windows โ€” but if you run a heterogeneous fleet, you end up with two or three tools, three different consoles, and no unified view of what's actually happening across your endpoints. Fleet is the open source MDM that manages all of it from one platform. macOS, Windows, Linux, iOS, Android โ€” one console, one API, one GitOps workflow. It's built on osquery, the open source endpoint agent originally created at Facebook, and it's the first MDM to ship native GitOps support. Configuration lives in YAML in your Git repository, changes go through pull requests, and your device state is auditable the same way your infrastructure is. ## What Fleet is Fleet is an open source device management platform (MDM) for macOS, Windows, Linux, iOS, iPadOS, Android, and ChromeOS. It gives IT and security teams a single system to enroll devices, enforce policies, deploy software, manage patches, run osquery queries, track vulnerabilities, and demonstrate compliance โ€” all from one place. The platform is built by Fleet Device Management Inc., a company whose business model is explicitly modeled on GitLab โ€” open core, with a free MIT-licensed tier and paid premium features. The free version under the MIT license includes core MDM, osquery management, and infrastructure-as-code workflows, and can be downloaded without leaving an email address. Fleet Premium at $7/host/month adds team-based access controls, advanced audit logging, SSO, vulnerability management integrations, and professional support. Fleet is used in production at organizations managing tens of thousands of devices, with a few large organizations managing 400,000 or more. The GitHub repo has 6,479 stars with active development. ## The license โ€” MIT core, commercial /ee The majority of Fleet is released under the MIT license. A separate set of paid features lives in an /ee directory under a commercial license. This is the same open core model used by GitLab, Metabase, and others โ€” the core platform is genuinely open source and free, while enterprise features like SSO, advanced RBAC, and vulnerability management integrations require a paid license. For most self-hosted deployments, the MIT core covers everything you need: MDM enrollment, policy enforcement, osquery queries, software deployment, patch management, and GitOps workflows. The /ee features are for larger organizations with compliance teams and enterprise integration requirements. ## Built on osquery This is what differentiates Fleet from traditional MDM platforms. osquery is an open source tool originally built at Facebook that exposes your operating system as a relational database โ€” you query device state with SQL. Instead of "show me devices with FileVault disabled," you write: SELECT hostname, username FROM disk_encryption JOIN logged_in_users ON logged_in_users.uid = disk_encryption.uid WHERE encrypted = 0; Fleet wraps osquery at scale. You can run queries across your entire fleet in real time, schedule queries that run continuously and alert on changes, and build compliance policies from SQL. The result is device visibility that goes far deeper than traditional MDM โ€” you're not limited to the attributes Apple or Microsoft chose to expose through their MDM protocols. If osquery can query it (and it can query almost everything), Fleet can report on it. Beyond queries, Fleet ships the **fleetd agent** โ€” a lightweight daemon that handles MDM enrollment, runs osquery, manages software installation, and reports telemetry. One agent, one configuration, all platforms. ## GitOps-first device management This is Fleet's most distinctive capability and the one most relevant to DevOps teams. Fleet is the first cross-platform GitOps-enabled MDM. Your device configuration โ€” MDM profiles, osquery policies, software installers, patch schedules โ€” lives in YAML in a Git repository. Changes go through pull requests. CI/CD applies them. Every change is peer-reviewed, version-controlled, and auditable. A Fleet GitOps repository looks like this: # default.yml โ€” applies to all devices controls: macos_settings: custom_settings: - path: ./profiles/filevault.mobileconfig - path: ./profiles/screensaver.mobileconfig windows_settings: custom_settings: - path: ./profiles/bitlocker.xml # Query policies policies: - name: "FileVault enabled" platform: darwin query: SELECT 1 FROM disk_encryption WHERE encrypted = 1; critical: true # Software to deploy software: packages: - url: https://example.com/app.pkg self_service: false Your CI/CD pipeline runs `fleetctl gitops` on merge to main, and Fleet applies the changes to enrolled devices. The same workflow you use for infrastructure โ€” Terraform, Ansible, Kubernetes manifests โ€” now manages your endpoints. No clicking through a console, no undocumented manual changes, no configuration drift. ## Cross-platform MDM Fleet implements the native MDM protocols for each platform: * **macOS** โ€” Apple MDM protocol + Declarative Device Management (DDM). Zero-touch enrollment through Apple Business Manager (ABM). FileVault management, configuration profiles, OS update enforcement, CIS Benchmark evaluation, Fleet-maintained app catalog. * **Windows** โ€” Windows MDM protocol (CSPs). BitLocker encryption enforcement with key escrow. Windows Update deadline enforcement. WDAC application control. Domain join via Autopilot. * **Linux** โ€” osquery-based management with full script execution, software deployment, patch management, and policy enforcement. First-class support across major distributions (Ubuntu, RHEL, Debian, Fedora, Amazon Linux). Linux MDM via Fleet is significantly more capable than any competing platform. * **iOS/iPadOS and Android** โ€” enrollment, app management, device posture, and basic policy enforcement for corporate and BYOD devices. The Linux story deserves emphasis. Most MDM platforms treat Linux as an afterthought โ€” if they support it at all. Fleet's Linux management is built on osquery and fleetd, giving you the same query-based visibility and policy enforcement as macOS and Windows. For engineering teams where Linux laptops are the norm, this is the practical differentiator. ## Vulnerability management Fleet continuously evaluates installed software across every device against the National Vulnerability Database (NVD) CVE feed. You get a real-time view of which devices have vulnerable software, which CVEs affect your fleet, and the severity of each finding. Fleet maintains its own generated CPE/CVE databases from NVD, updated regularly. The vulnerability data is queryable: "show me all devices with a critical CVE in the last 30 days that haven't been patched." Combine this with Fleet's software deployment capability and you have a complete remediation workflow โ€” detect the vulnerability, deploy the patch, verify the fix. ## Self-hosting Fleet Fleet is a Go binary with a MySQL database and Redis for pub/sub. Docker Compose is the quickest self-hosted path: services: fleet: image: fleetdm/fleet:latest command: fleet serve environment: FLEET_MYSQL_ADDRESS: mysql:3306 FLEET_MYSQL_DATABASE: fleet FLEET_MYSQL_USERNAME: fleet FLEET_MYSQL_PASSWORD: ${MYSQL_PASSWORD} FLEET_REDIS_ADDRESS: redis:6379 FLEET_SERVER_TLS: "false" # handle TLS at Traefik FLEET_AUTH_JWT_KEY: ${JWT_KEY} ports: - "8080:8080" depends_on: - mysql - redis mysql: image: mysql:8.0 environment: MYSQL_DATABASE: fleet MYSQL_USER: fleet MYSQL_PASSWORD: ${MYSQL_PASSWORD} MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD} redis: image: redis:alpine For production Fleet also ships Terraform modules, a Helm chart for Kubernetes, and deployment guides for AWS, GCP, Azure, and air-gapped environments. The TLS certificate handling is critical โ€” Apple MDM enrollment requires a valid TLS certificate, so make sure Traefik or your load balancer is handling HTTPS correctly before enrolling any devices. Minimum viable server: 2 CPU cores, 4GB RAM. For larger fleets (1,000+ devices), Fleet recommends dedicated MySQL with read replicas and Redis cluster. ## Fleet vs the alternatives **vs Jamf** โ€” Jamf is the gold standard for Apple device management with the deepest macOS/iOS feature set, the largest ecosystem of integrations, and the strongest name recognition with enterprise security teams. It's also expensive, Apple-only, and a black box. Fleet manages macOS at feature parity for Apple MDM tasks while adding Linux, Windows, and cross-platform osquery visibility that Jamf simply doesn't offer. For organizations that need to manage heterogeneous fleets, Fleet's unified platform eliminates the "Jamf for Macs, Intune for Windows, nothing for Linux" problem. **vs Microsoft Intune** โ€” Intune is deeply integrated with Microsoft 365, Azure AD, and the Microsoft ecosystem. If your organization runs primarily on Windows and Microsoft services, Intune's tight integrations are compelling. It's also proprietary SaaS with no self-hosting option. Fleet's Windows MDM coverage is competitive for most use cases, and adding macOS and Linux management through Fleet avoids needing a second platform. **vs Kandji** โ€” Kandji is a modern Apple MDM with an excellent UI and strong automation features, but it's Apple-only and SaaS-only. No Linux, no self-hosting, no GitOps. Foursquare publicly migrated from Jamf to Fleet โ€” the quote on Fleet's site: "Thanks for a great run Jamf. Foursquare has officially completed the migration to Fleet as our new device management platform." **vs NinjaRMM / NinjaOne** โ€” NinjaRMM targets MSPs with remote monitoring and management (RMM) alongside MDM. Strong Windows RMM capabilities, good for managed service providers. Fleet doesn't have built-in ticketing or the full RMM feature set, but the GitOps model and osquery visibility make Fleet the better choice for internal IT teams that treat infrastructure as code. ## Who it's for **Good fit:** * Engineering organizations with heterogeneous fleets (Mac + Windows + Linux) who don't want three separate management tools * DevOps and platform teams who want to manage endpoints the same way they manage infrastructure โ€” as code, in Git, through pull requests * Security teams who need deep endpoint visibility beyond what traditional MDM provides * Organizations with data residency or compliance requirements that rule out SaaS-only MDM * Teams who want to use osquery at scale without building their own management layer **Not the right fit:** * Small teams that want zero-infrastructure MDM โ€” Jamf or Kandji are easier to start with * Microsoft-only shops deeply integrated with Intune and Azure AD โ€” the switching cost is real * Teams that need enterprise SLA support without a Premium contract โ€” the free tier is community-supported ## My take Fleet is the MDM I'd reach for when building infrastructure for an engineering organization. The GitOps model is the right answer to the "how do we manage device configuration without undocumented manual changes" problem โ€” and the fact that it's the only MDM that delivers this at production scale is a genuine differentiator. The osquery foundation gives you endpoint visibility that no traditional MDM can match. The ability to ask any device an arbitrary SQL question, across every OS, at scale, is powerful. Combined with vulnerability management and software deployment, Fleet gives you a complete endpoint operations platform rather than just a checkbox compliance tool. The Linux management story is the practical reason many engineering teams end up here. If your engineers run Ubuntu or Fedora and your current MDM ignores those machines, Fleet solves the problem in a way Jamf never will. For any organization where Linux endpoints are first-class citizens alongside Macs and Windows machines, Fleet is the only serious option in the open source space. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help deploying Fleet? Standing up Fleet in production โ€” MySQL, Redis, TLS configuration, Apple Business Manager enrollment setup, GitOps repository structure, osquery policy configuration, and enrolling your first devices across macOS, Windows, and Linux โ€” has more moving parts than most infrastructure tools. I can handle the full deployment and set up your GitOps workflow so your team manages endpoints as code from day one. Get in touch at pipoline.com โ†’

devopspack.com

Flagsmith is the open source feature flag and remote config platform that decouples deployment from release. Self-host for free with no user limits, or use the managed cloud. BSD-3-Clause licensed, 15+ SDKs, and a built-in MCP Server for AI agent workflows.

Flagsmith: Open Source Feature Flags and Remote Config Without the LaunchDarkly Bill

Feature flags are one of those engineering practices that feel optional until you've shipped a broken feature to everyone at once and spent the next three hours on an emergency rollback. Once you've experienced that, you start thinking about how to separate deployment from release โ€” push code whenever it's ready, turn it on for real users only when you're confident. LaunchDarkly is the category leader and it's excellent. It's also expensive โ€” pricing that made sense when you had ten flags and a hundred users starts hurting at scale. Flagsmith is the open source alternative: the same feature flag and remote config workflow, BSD-3-Clause licensed, self-hostable for free with no user or request limits, or available as managed cloud starting at $45/month. ## What Flagsmith is Flagsmith is an open-source feature flag and remote configuration platform. It lets you toggle features on or off in production without deploying new code, target flags to specific users or segments based on traits, run percentage-based rollouts, and change application configuration values at runtime. It's written in Python (Django) on the backend with a React frontend, BSD-3-Clause licensed, and has 6,300+ GitHub stars. The core value proposition: **decouple deployment from release**. Deploy code continuously, control who sees new features through flag targeting. Ship faster because new code is off by default. Roll back instantly by flipping a flag โ€” no code change, no redeployment, no waiting for pipelines. Flagsmith covers three categories of use: * **Feature flags** โ€” boolean on/off controls for features, per environment, per user, per segment * **Remote configuration** โ€” string, number, or JSON values you can change at runtime without a deployment * **A/B testing and multivariate flags** โ€” percentage-based rollouts and variant testing across user segments ## The license โ€” BSD-3-Clause Flagsmith uses the **BSD 3-Clause license** โ€” one of the most permissive OSI-approved open source licenses available. No commercial-use restrictions, no multi-tenant clauses, no logo requirements. Self-host it, fork it, modify it, use it in commercial products โ€” BSD 3-Clause permits all of it without any conditions beyond attribution. This matters in the feature flag space because several competitors use source-available licenses or have moved to more restrictive terms. Flagsmith's core functionality stays open, always โ€” the team has committed to this explicitly. Enterprise governance features (audit logs, SAML SSO, role-based access control, change requests) require an Enterprise license, but the core flag management is BSD-3-Clause forever. ## How feature flags work in Flagsmith The mental model is straightforward. You create a flag in the Flagsmith dashboard, set its default state per environment (development, staging, production), and query it in your application code via an SDK: # Python SDK from flagsmith import Flagsmith flagsmith = Flagsmith(environment_key="your-env-key") # Simple boolean flag flags = flagsmith.get_environment_flags() if flags.is_feature_enabled("new_dashboard"): render_new_dashboard() else: render_legacy_dashboard() # Remote config value api_rate_limit = flags.get_feature_value("api_rate_limit") # returns 100, or whatever you set in dashboard For user-level targeting, you pass an identity: # Target flags to a specific user with traits flags = flagsmith.get_identity_flags( identifier="user-123", traits={"plan": "pro", "country": "sk", "days_since_signup": 14} ) if flags.is_feature_enabled("pro_export_feature"): # Only Pro users see this enable_export() The SDK caches flag state locally. Evaluation happens in-process โ€” no network round-trip on each flag check. Flags update in the background and propagate globally in under 100ms. ## Environments and targeting Flagsmith organizes flags across environments โ€” development, staging, production, or any custom environments you define. The same flag can be on in development, rolling out to 10% in staging, and off in production. Each environment has its own API key. **Segments** let you target groups of users based on traits: "all users on Pro plan", "users who signed up in the last 30 days", "users in the EU". Create a segment, assign a flag to it, and every user matching the trait criteria gets the flag โ€” without code changes. **Percentage rollouts** let you gradually increase exposure: start a new feature at 1% of users, watch error rates, expand to 10%, then 50%, then full rollout. If something goes wrong, set it back to 0% โ€” instant rollback without a deployment. **Multivariate flags** support A/B and multivariate testing: define variants with string or JSON values, assign percentages, and different users get different variants consistently. Track which variant each user got for analysis. ## Remote configuration This is the underrated half of Flagsmith. Feature flags are boolean โ€” on or off. Remote config is a flag with a value โ€” a string, number, or JSON object you can change at runtime. Practical examples: * Change the number of items per page without a deployment: `items_per_page = 25` โ†’ `50` * Update copy, colors, or promotional banners in real time * Control rate limits, timeouts, or cache TTLs without touching code * Store entire JSON configs for complex feature behavior: `{"max_file_size_mb": 10, "allowed_types": ["pdf", "csv"]}` * Version prompt templates for AI features without redeploying The last one is increasingly relevant: teams building LLM features use remote config to iterate on system prompts, model parameters, and temperature settings in production without code changes. Update the prompt, watch the results, roll back if needed โ€” same deploy-free workflow as feature flags. ## The Edge Proxy For latency-sensitive applications, Flagsmith ships an Edge Proxy โ€” a lightweight service you deploy close to your application. It caches all flag data locally and evaluates flags in-process with sub-millisecond latency, no network call to the Flagsmith API. The proxy syncs with the API in the background. This is particularly valuable for server-side applications where flag evaluation happens on every request โ€” you get the developer experience of Flagsmith without adding latency to your request path. ## SDK support Flagsmith supports 15+ official SDKs: JavaScript/TypeScript, Python, Go, Ruby, PHP, Java, .NET, iOS/Swift, Android/Kotlin, Flutter, Rust, Elixir, Node.js, and more. Each SDK supports both server-side and client-side evaluation modes. The OpenFeature provider means Flagsmith works with the OpenFeature standard if you want to keep your flag evaluation code vendor-neutral. ## MCP Server for AI agents Worth highlighting for teams building AI-assisted workflows: Flagsmith ships an official MCP Server that lets AI agents manage feature flags directly from IDEs and CI/CD pipelines. An agent can read current flag states, toggle flags, and adjust remote config values as part of an automated deployment workflow โ€” without leaving the agentic loop. This is a newer capability that maps well to AI-first development workflows where you want the LLM to manage flag state during a deployment. ## Self-hosting Flagsmith Docker Compose is the standard path for self-hosting. Flagsmith requires PostgreSQL and optionally Redis for caching: # Clone and start git clone https://github.com/Flagsmith/flagsmith.git cd flagsmith/docker docker compose -f docker-compose.yml up -d The default Docker Compose setup includes the API, frontend, PostgreSQL, and an NGINX proxy. For production you'll want to configure: * A proper PostgreSQL instance with backups * SMTP for user invitations and notifications * Traefik or Nginx in front for HTTPS * Optionally Redis for the Edge Proxy caching layer Self-hosted Flagsmith has **no user limits, no request limits, and no feature limitations** on the core platform. You pay for infrastructure, not for usage. Enterprise features (SAML SSO, audit logs, RBAC, change requests, scheduled flags) require an Enterprise license โ€” but for most teams the open source core covers everything they need. Minimum server size: 1 CPU core and 2GB RAM for a small team. The API is lightweight and the main resource consumer is PostgreSQL. ## Terraform provider Flagsmith has an official Terraform provider, which deserves a mention for DevOps-first teams. Managing flags as code means: resource "flagsmith_feature" "new_dashboard" { feature_name = "new_dashboard" project_id = var.project_id description = "New dashboard redesign" type = "STANDARD" default_enabled = false } resource "flagsmith_feature_state" "new_dashboard_production" { environment_key = var.prod_environment_key feature_id = flagsmith_feature.new_dashboard.id enabled = false # off in production until ready } Flags live in version control. Changes go through pull requests. State is auditable. No configuration drift between environments. For teams already managing infrastructure as code with Terraform, this is the natural way to manage flags too. ## Flagsmith vs the alternatives **vs LaunchDarkly** โ€” LaunchDarkly is the category leader: mature, polished, deeply integrated with every CI/CD tool imaginable, with the best analytics and experimentation features in the space. It's also priced for enterprises โ€” the cost becomes significant at scale. Flagsmith covers the core use cases (flags, targeting, rollouts, remote config) at a fraction of the cost or free when self-hosted. LaunchDarkly wins on depth and ecosystem; Flagsmith wins on cost and data ownership. **vs Unleash** โ€” Unleash is the other major open source feature flag platform, also Apache 2.0 licensed. Unleash has strong enterprise features and is particularly well-regarded for large-scale deployments in regulated industries. Flagsmith has a cleaner UI, better remote config story, and a more approachable onboarding. Both are solid choices โ€” evaluate based on your specific scale and compliance requirements. **vs GrowthBook** โ€” GrowthBook is open source and focused on A/B testing and experimentation with feature flags as a secondary capability. If your primary use case is statistical experimentation and conversion optimization, GrowthBook is worth considering. If you want feature flags with targeting and remote config with experimentation as a secondary feature, Flagsmith fits better. **vs self-built** โ€” some teams build their own feature flag system with Redis and a config service. This works until it doesn't โ€” you end up building targeting, environments, audit logs, SDKs, and a dashboard. Flagsmith gives you all of that, maintained by a dedicated team, for free when self-hosted. The opportunity cost of building and maintaining your own flag system is almost never worth it. ## Who it's for **Good fit:** * Teams practicing continuous deployment who want to separate deploy from release * Organizations with compliance or data residency requirements that rule out SaaS flag tools * Teams currently paying LaunchDarkly and looking for a cost-effective alternative * DevOps-first teams who want to manage flags as code via Terraform * Teams building LLM features who want to iterate on prompts and model params without redeploying * Anyone who has ever done a 2am rollback by reverting a commit and redeploying **Not the right fit:** * Teams primarily needing deep statistical experimentation โ€” GrowthBook or LaunchDarkly are better * Very small teams with simple release processes where flags add complexity without proportional value * Teams that need enterprise governance features (SAML, RBAC, audit logs) on the open source tier โ€” those require the Enterprise license ## My take Feature flags are one of those practices that feel like overhead until they save you. The first time you ship a bad feature to 100% of users and have to roll it back via a deployment, you'll want a flag. The first time you graduate a feature from 1% to 100% over a week, watching metrics the whole way, you'll understand why the category exists. Flagsmith is the right open source answer to this problem. BSD-3-Clause with no commercial restrictions, self-hostable for free with no usage limits, 15+ SDKs, and a clean UI that non-engineers can use. The remote config capability extends the value beyond pure feature toggling โ€” being able to change application behavior at runtime without a deployment is genuinely useful for everything from copy changes to AI prompt tuning. For any team running self-hosted infrastructure and doing continuous deployment, Flagsmith is a natural addition to the stack. One more Docker Compose deployment, and you gain the ability to deploy code confidently and control releases deliberately โ€” which is, ultimately, what CI/CD is supposed to give you. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help setting up Flagsmith? Getting Flagsmith into production โ€” Docker Compose, PostgreSQL, Traefik for HTTPS, Terraform provider setup, Edge Proxy deployment, and integrating flag checks into your existing CI/CD pipelines โ€” takes an afternoon to do properly. I can handle the full setup and wire feature flags into your deployment workflow so your team ships confidently from day one. Get in touch at pipoline.com โ†’

devopspack.com

Supabase is the open source Firebase alternative built on PostgreSQL โ€” auth, real-time database, storage, edge functions, and auto-generated APIs in one platform. Self-hostable, Apache 2.0, and genuinely production-ready in 2026.

Supabase: The Open Source Firebase Alternative Built on PostgreSQL

Firebase solved a real problem: give developers a complete backend without requiring backend expertise. Authentication, a database, file storage, and real-time updates โ€” all accessible through a clean SDK, deployed in minutes. Millions of apps run on it. The problem is what you trade for that convenience: your data lives in Google's proprietary Firestore format, your queries are constrained by a NoSQL model, and migrating away means rewriting your data layer from scratch. Supabase offers the same developer experience with a fundamentally different foundation. Instead of a proprietary NoSQL engine, it's PostgreSQL โ€” the world's most trusted relational database. Instead of vendor lock-in, it's Apache 2.0-licensed and fully self-hostable. The pitch is Firebase's developer experience with SQL and data portability. In 2026 Supabase has **103,000+ GitHub stars** , a $5 billion valuation, 1,893 contributors, and powers everything from solo projects to production apps at publicly traded companies. It's not a Firebase clone โ€” it's a genuinely mature platform that happens to feel familiar. ## What Supabase is Supabase is an open-source Backend-as-a-Service platform built on PostgreSQL. It wraps a set of open source tools โ€” each independently useful โ€” into a unified platform with a single dashboard and a consistent client SDK: * **PostgreSQL** โ€” a real, full-featured Postgres database. Not a simplified subset, not a proprietary engine with SQL syntax bolted on. Real Postgres, with all extensions, full SQL, RLS, triggers, and functions. * **Auth** โ€” user authentication with email/password, magic links, OAuth (Google, GitHub, Apple, and 20+ more providers), phone OTP, and SAML for enterprise SSO. Built on GoTrue, Apache 2.0 licensed. * **Realtime** โ€” listen to database changes, broadcast messages, and track presence via WebSockets. Built with Elixir/Phoenix, capable of millions of concurrent connections. * **Storage** โ€” S3-compatible file storage with CDN, image transformations, and fine-grained access control through RLS policies. Apache 2.0 licensed. * **Edge Functions** โ€” globally distributed TypeScript/JavaScript functions running on Deno. Deploy serverless logic close to your users. * **Auto-generated APIs** โ€” every table automatically gets a REST API (via PostgREST) and a GraphQL API. Zero configuration, secured by RLS. * **pgvector** โ€” the PostgreSQL extension for vector embeddings ships as a default. Supabase became the fastest path to a RAG backend in 2023โ€“2024 for exactly this reason. ## The license โ€” genuinely Apache 2.0 After a string of posts on this blog covering source-available tools (Outline's BSL, Invoice Ninja's ELv2, Dify's modified Apache 2.0, Nomad's BUSL), Supabase is worth calling out explicitly: it's **Apache 2.0, genuinely OSI-approved open source** , with no commercial-use clauses, no multi-tenant restrictions, no logo requirements. Use it however you want. Self-host it, fork it, build a competing hosted service โ€” Apache 2.0 permits all of it. The company's philosophy from the GitHub README: "If the tools and communities exist with an MIT, Apache 2, or equivalent open license, we will use and support that tool. If the tool doesn't exist, we build and open source it ourselves." They've followed through โ€” every component in the stack is independently open source. ## Row Level Security โ€” the key concept The feature that makes Supabase's approach coherent is Row Level Security (RLS). In a traditional BaaS, access control is managed in the API layer โ€” your serverless functions check whether a user is allowed to see a row before returning it. In Supabase, access control lives in the database itself as PostgreSQL policies. A policy might look like this: -- Users can only see their own data create policy "Users can view own profile" on profiles for select using ( auth.uid() = user_id ); -- Only owners can update their records create policy "Users can update own profile" on profiles for update using ( auth.uid() = user_id ); These policies enforce at the database layer โ€” even if someone bypasses your API and queries the database directly, they still can't see data they're not authorized to see. The auto-generated REST and GraphQL APIs respect these policies automatically. You write the policy once and every access path is covered. This is a genuinely different security model than most BaaS platforms, and it's one of Supabase's strongest architectural arguments. ## Auto-generated TypeScript types One quality-of-life feature worth highlighting: Supabase generates fully typed TypeScript types from your database schema. Every table, every column, every foreign key relationship โ€” typed automatically. supabase gen types typescript --project-id your-project-id > database.types.ts The result is end-to-end type safety from your database through to your frontend. Change a column type in the database, regenerate types, and TypeScript will catch every affected query and component. For teams building TypeScript applications, this removes an entire category of runtime errors. ## pgvector and AI applications Supabase ships the `pgvector` extension by default, which makes it a natural backend for AI applications that need vector search. Store embeddings alongside your regular data in the same database, query with standard SQL, and combine semantic similarity search with structured filters in a single query: -- Find similar documents, only from public posts select id, title, content from documents where status = 'published' order by embedding <-> query_embedding limit 10; This "one database for everything" approach โ€” relational data, vector embeddings, and full-text search all in PostgreSQL โ€” is what made Supabase the default choice for RAG-backed applications. You get `pg_trgm` for fuzzy search, `pgvector` for semantic search, and standard SQL for structured filters, all in one query, without a separate vector database to manage. ## Self-hosting Supabase Supabase is self-hostable via Docker Compose. The stack is more complex than most tools on this blog โ€” it runs around a dozen services โ€” but the official Docker Compose configuration handles the wiring: # Clone the repo git clone --depth 1 https://github.com/supabase/supabase cd supabase/docker # Copy the example env and configure cp .env.example .env # Edit .env: set POSTGRES_PASSWORD, JWT_SECRET, ANON_KEY, SERVICE_ROLE_KEY # Pull and start docker compose pull docker compose up -d The full stack includes: PostgreSQL, PostgREST (auto REST API), GoTrue (auth), Realtime (websockets), Storage API, Kong (API gateway), Postgres Meta (database management), Supavisor (connection pooler), and the Studio dashboard. It's a lot of services, but each is independently useful and the Docker Compose configuration is well-maintained. Minimum viable server: 4GB RAM, 2 CPU cores. For production, 8GB+ and separate database storage is recommended. The official Supabase self-hosting docs are comprehensive and actively maintained โ€” this is not an afterthought. ## Supabase vs Firebase This is the comparison that matters for most teams evaluating Supabase. **Data model** โ€” Supabase is PostgreSQL: relational, SQL, JOINs, transactions, foreign keys, complex queries. Firebase Firestore is NoSQL: documents, collections, no JOINs, no multi-document transactions (except in limited form). For any data with relationships โ€” users, posts, comments, orders, products โ€” PostgreSQL's model is significantly more expressive. **Data portability** โ€” Supabase's data is in standard PostgreSQL. Export with `pg_dump`, connect any SQL tool, migrate to RDS, Google Cloud SQL, or a self-hosted Postgres. Firebase data is in Firestore's proprietary format โ€” exporting and migrating requires custom scripts and model transformation. Every year you use Firebase, migration gets harder. **Lock-in** โ€” Firebase Auth tokens are Firebase-specific. Cloud Functions run on Google Cloud only. Firestore's query language is proprietary. Every convenience ties you deeper into Google's ecosystem. Supabase's components are independently open source โ€” GoTrue for auth, PostgREST for APIs, PostgreSQL for data. You could replace any component independently. **Real-time** โ€” Firebase's real-time was the original killer feature. Supabase Realtime is competitive and uses standard PostgreSQL CDC (change data capture), meaning it reflects actual database state rather than a separate real-time layer. **Ecosystem** โ€” Firebase has a decade head start and deeper mobile SDK integrations (especially for iOS/Android), push notifications, Firebase Analytics, and Crashlytics. For mobile-first apps, Firebase's broader service set is still relevant. For web and API-first apps, Supabase covers the core backend needs well. ## Supabase vs Appwrite Appwrite is the other major open source BaaS alternative, and it's worth a direct comparison since both target the same audience. Supabase is PostgreSQL-first โ€” the database is the product, and everything else wraps around it. If you want the power of a real relational database with auto-generated APIs and auth on top, Supabase is the better choice. Appwrite uses its own database abstraction layer over multiple backends, which is more flexible but gives up some of PostgreSQL's depth. Appwrite has a stronger multi-platform story (native SDKs for more platforms), a built-in messaging system, and arguably simpler self-hosting. For mobile-first applications or teams that prefer a more abstracted data model, Appwrite is worth evaluating. For web applications and teams who want real SQL, Supabase wins. ## Pricing Supabase Cloud's free tier is generous: **500MB database, 1GB storage, 50K monthly active users, unlimited API requests**. The Pro plan is $25/month for 8GB storage and 250GB bandwidth. Self-hosted is free beyond infrastructure costs โ€” no license fees, no feature gates, no user limits. All features including the Studio dashboard, Edge Functions, and Realtime are available in the self-hosted version. ## Who it's for **Good fit:** * Teams building web apps or SaaS products that want a complete backend without writing backend code * Projects coming from Firebase that want data portability and SQL * AI application developers who need vector search alongside relational data (pgvector) * TypeScript-first teams who want database-to-frontend type safety * Teams with compliance or data residency requirements โ€” self-host and own everything * Developers who know SQL and want to use it, not work around a NoSQL limitation **Not the right fit:** * Mobile-first apps needing Firebase's push notifications, Analytics, and Crashlytics โ€” Firebase's mobile ecosystem is deeper * Teams needing a simple, lightweight single-binary backend โ€” PocketBase is far simpler to self-host * Applications with pure document-based data models and no relational needs โ€” Firebase/Firestore works better for those * Teams without capacity to operate a 10+ service Docker stack in self-hosted mode ## My take Supabase is one of the cleanest examples of what open source done right looks like. The license is genuinely Apache 2.0 โ€” not "Apache 2.0 but not really." Every component in the stack is independently open source. The data sits in standard PostgreSQL. And the developer experience is genuinely good: the dashboard is polished, the SDKs are well-typed, and the auto-generated APIs with RLS policies eliminate a class of backend code you'd otherwise have to write. The self-hosting story is also mature in a way that most BaaS platforms aren't โ€” this isn't an afterthought for compliance cases, it's a first-class deployment path that the team actively maintains. For teams with data sovereignty requirements, or simply teams that want to not pay per-MAU fees as they scale, self-hosted Supabase is a real option. The complexity trade-off is real: the self-hosted stack is a dozen services, and operating it correctly requires more DevOps discipline than most simpler tools. But if you're already running a self-hosted infrastructure stack โ€” and if you're reading this blog you probably are โ€” Supabase fits naturally into that picture. It's one more Docker Compose deployment, and what you get in return is a complete, standards-based backend for every application you want to build. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help self-hosting Supabase? Getting Supabase into production โ€” Docker Compose, PostgreSQL storage configuration, Traefik for HTTPS, JWT key generation, SMTP for auth emails, S3-compatible storage setup, and proper backup procedures โ€” has more moving parts than the managed cloud version. I can handle the full setup and configure RLS policies for your data model. You get a production-ready backend platform with full data ownership, without spending a week figuring out the details. Get in touch at pipoline.com โ†’

devopspack.com

Dify is the visual LLM app platform with 138k+ stars that lets you build RAG pipelines, AI agents, and multi-model workflows in an afternoon. Self-hostable, model-agnostic, and production-ready. One honest caveat about the license.

Dify: Build AI Agents and LLM Workflows Without Writing the Plumbing

Building LLM-powered products used to mean assembling a fragile stack of API wrappers, vector database clients, prompt templates, context management logic, and retry handlers. You'd spend more time writing orchestration boilerplate than building the thing you actually wanted. LangChain helped โ€” then became a different kind of complexity problem. Most alternatives were either too opinionated or not production-ready. Dify takes a different approach: give developers a visual canvas to wire LLM workflows together, backed by a production-grade infrastructure stack, with the full source available to self-host. It's become the fastest path from "I want to build an AI product" to a working, deployed application โ€” and with 138,000+ GitHub stars and over a million deployed apps, it's clearly resonating. ## What Dify is Dify (short for "Do It For You") is an LLM application development platform that bundles everything needed to ship AI products into a single self-hostable stack: a visual workflow builder, a RAG pipeline, an agent framework, model management for 100+ providers, and LLMOps observability. It launched in March 2023 and has grown to 138,000+ GitHub stars โ€” more than Flowise (~40K) and approaching n8n (~130K) โ€” with over 1 million deployed applications and 180,000+ developers using it. The core proposition: instead of writing orchestration code, you drag and drop components onto a canvas. Instead of managing separate vector database clients, RAG pipelines, and model provider integrations, you configure them through a UI. And instead of paying for a proprietary AI app platform, you self-host the whole stack on your own infrastructure with zero feature restrictions compared to the cloud version. ## The license situation โ€” modified Apache 2.0 Before anything else, the licensing deserves a clear explanation because it's commonly misunderstood and Dify markets itself as "open source" in a way that's technically inaccurate. Dify uses a **modified Apache 2.0 license with additional restrictions** โ€” sometimes called the "Dify Open Source License." The community has raised this repeatedly on GitHub, with contributors correctly pointing out that adding restrictions to Apache 2.0 means it no longer qualifies as an OSI-approved open source license. It's more accurately described as source-available. The two key restrictions: * **Multi-tenant SaaS** โ€” you cannot use Dify to operate a multi-tenant environment (where one workspace = one tenant) without written authorization from Dify. In practice this means: building a hosted Dify service for others requires a commercial license. * **Logo and copyright** โ€” you cannot remove or modify the Dify logo or copyright notices from the frontend (the `web/` directory). What this means in practice for the overwhelming majority of users: **nothing**. Self-hosting Dify to build internal tools, chatbots, and AI workflows for your own organization is fully permitted with no restrictions. The license only bites if you're building a competing hosted Dify platform for others or want to strip the branding. For teams with strict OSI-approved-only procurement requirements, this is a genuine blocker. For everyone else โ€” including DevOps teams building internal AI tooling โ€” the effective experience is identical to a permissive open source license. ## Core capabilities ### Visual workflow builder The workflow builder is Dify's centrepiece. You connect nodes on a canvas โ€” LLM calls, knowledge base retrievals, conditional logic, HTTP requests, code execution, variable manipulation โ€” and wire them into a pipeline. What would be dozens of lines of LangChain or LlamaIndex code becomes a visual graph you can reason about and iterate on without touching code. Node types include: LLM (call any connected model), Knowledge Retrieval (query your RAG knowledge bases), Code (execute Python or JavaScript in a sandbox), HTTP Request (call external APIs), Conditional (branch logic), Template Transform (manipulate strings and variables), Question Classifier, and more. The workflow is the application โ€” you publish it as a chatbot, API endpoint, or embedded widget. ### RAG knowledge base pipeline Upload documents (PDF, Markdown, HTML, Notion pages, web crawls), and Dify handles chunking, embedding, vector storage, and retrieval. The pipeline supports hybrid search combining vector similarity with keyword matching โ€” which outperforms pure vector search for technical content where exact terms matter. Each stage is observable: you can see chunk sizes, embedding models used, retrieval scores, and latency. Knowledge bases are queryable via API, so your existing applications can use Dify as an external RAG service without going through the full workflow builder. This is particularly useful for adding RAG to existing applications without migrating the entire stack. ### Agent framework Beyond linear workflows, Dify supports autonomous agent loops where the model decides which tools to call based on the task. Agents have access to 50+ built-in tools: web search, code interpreter, image generation, HTTP requests, Wikipedia, weather, and more. You can also add custom tools by pointing at any OpenAPI spec โ€” Dify generates the tool integration automatically. Multi-agent workflows let you chain specialized agents: one for research, one for writing, one for fact-checking โ€” each with its own system prompt, model, and tool access, coordinated by an orchestrator agent. ### Model management โ€” 100+ providers Dify connects to any LLM through a unified plugin runtime: OpenAI, Anthropic (Claude), Google (Gemini), Mistral, Cohere, Azure OpenAI, AWS Bedrock, and self-hosted models via Ollama or any OpenAI-compatible inference server. You configure credentials once and switch models per workflow or even per node within a workflow. For teams running local models with Ollama โ€” Llama 3, Mistral, Qwen, or fine-tuned variants โ€” Dify works completely offline. No API costs, no data leaving your network. ### LLMOps observability Production AI applications need visibility into what's happening: token counts, costs, latency per node, retrieval quality, user feedback. Dify logs every request with full trace data โ€” model, prompt, completion, token usage, latency, and cost โ€” and surfaces it in a built-in dashboard. You can annotate responses, build golden datasets for evaluation, and track quality over time. This is the "Ops" in LLMOps: the tooling to actually run and improve AI applications in production. ## Self-hosting Dify Dify's self-hosted stack is more complex than most tools in this blog โ€” it runs eight services. Docker Compose handles it cleanly: # Clone the repo git clone https://github.com/langgenius/dify.git cd dify/docker # Copy and configure env cp .env.example .env # Edit .env: set SECRET_KEY, database passwords, storage settings # Start everything docker compose up -d The full stack includes: * **api** โ€” Flask backend, the core application server * **worker** โ€” Celery worker for async tasks (document indexing, long-running workflows) * **web** โ€” Next.js frontend * **plugin-daemon** โ€” model provider and tool plugin runtime * **sandbox** โ€” isolated environment for executing model-generated code safely * **db** โ€” PostgreSQL for metadata * **redis** โ€” queue and cache * **weaviate** (or pgvector, Qdrant, Milvus, Chroma) โ€” vector database for knowledge bases Minimum viable server: 2 CPU cores and 4GB RAM. For production with active knowledge bases and parallel workflows, 4+ cores and 8GB gives comfortable headroom. Put Traefik or Nginx in front for HTTPS. One practical note: Dify's `.env.example` is well-documented and the setup is more straightforward than it looks. The Railway template mentioned in the search results shows the full architecture pre-wired if you want a reference. ## Dify vs the alternatives **vs Flowise** โ€” Flowise is the most direct open source competitor: a visual LangChain workflow builder, MIT licensed (genuinely OSI open source, unlike Dify's modified license), simpler stack, easier to self-host. Dify wins on features โ€” more mature RAG pipeline, better observability, broader model support, multi-agent capabilities. Flowise wins on license clarity and lower operational overhead. For a small team that wants the simplest possible self-hosted visual workflow builder, Flowise is worth considering. For anything production-grade with serious RAG requirements, Dify's feature set pulls ahead. **vs n8n** โ€” n8n is a general-purpose automation platform (like Zapier, self-hosted) that added AI/LLM nodes. It's excellent for automations that involve LLMs as one step among many โ€” send an email, parse a PDF, call an API, summarize with GPT. Dify is built specifically for LLM applications end-to-end. They're complementary: n8n for automation workflows with AI assistance, Dify for AI-first applications. **vs LangChain / LlamaIndex** โ€” these are code-first frameworks, not platforms. They give you maximum flexibility at the cost of writing and maintaining orchestration code. Dify's visual builder compiles to the same underlying patterns LangChain/LlamaIndex implement in code. Use the frameworks if you need programmatic control and custom components; use Dify if you want to iterate faster and have the platform handle the infrastructure. **vs Langflow** โ€” Langflow is a visual LangChain builder (MIT licensed) similar to Flowise. Less mature than Dify, smaller community, but genuinely open source. Worth evaluating if OSI compliance is a hard requirement. **vs hosted LLM app platforms (OpenAI Assistants API, Anthropic, AWS Bedrock Agents)** โ€” these lock you to one vendor's models and pricing. Dify self-hosted is model-agnostic and data stays on your infrastructure. The trade-off is operational responsibility; the gain is control, cost, and privacy. ## Practical use cases for DevOps teams Dify is particularly well-suited for the kind of internal tooling DevOps teams actually need: * **Internal documentation chatbot** โ€” ingest your runbooks, architecture docs, and wikis into a knowledge base; build a chatbot that answers "how do we rotate secrets in production?" from your actual docs. * **Incident response assistant** โ€” a workflow that takes an alert, queries relevant runbooks, retrieves recent similar incidents from your knowledge base, and drafts an initial response. * **Code review summarizer** โ€” pipe pull request diffs to a workflow that summarizes changes, flags potential issues, and tags relevant team members. * **Infrastructure Q &A** โ€” connect Dify to your Terraform state, deployment logs, or monitoring dashboards via HTTP tool nodes; ask natural language questions about your infrastructure. * **Onboarding assistant** โ€” an agent that answers "how do I set up my dev environment" by retrieving from your onboarding docs and walking through steps interactively. ## Who it's for **Good fit:** * Teams who want to build LLM-powered internal tools without writing orchestration boilerplate * Organizations with compliance or privacy requirements where data can't leave their network * Teams running local models via Ollama who want a production-grade application layer on top * Developers who want to prototype AI workflows fast and iterate without code changes * Anyone currently paying for proprietary AI app platforms (OpenAI Assistants, Azure AI Studio) **Not the right fit:** * Teams with strict OSI open source requirements โ€” Flowise or Langflow instead * Anyone wanting to offer Dify as a multi-tenant hosted service โ€” requires a commercial license * Simple single-step LLM integrations โ€” a direct API call is simpler than deploying the full stack * Teams without DevOps capacity to maintain an 8-service Docker stack ## My take Dify is the most complete self-hosted platform for building LLM applications in 2026. The visual workflow builder genuinely accelerates development โ€” what takes a day of LangChain plumbing takes an hour in Dify. The RAG pipeline is production-grade. The model-agnostic architecture means you're not locked into any provider. And the observability story is better than most proprietary alternatives. The license is worth being honest about: Dify is not genuinely open source despite marketing itself that way. For self-hosting internal tools, this doesn't matter at all in practice. But the community's frustration with the "Apache 2.0 but not really" framing is legitimate โ€” it's the same pattern as BSL tools claiming open source heritage while adding commercial restrictions. For DevOps teams specifically, the internal tooling angle is compelling. A documentation chatbot powered by your actual runbooks, built on Dify, running on your own server alongside Outline or Plane โ€” that's a genuinely useful addition to your self-hosted stack. The combination of local model support (Ollama) and full data ownership means you can build AI tooling that never touches a third-party API if that's what your security requirements demand. Start with the Docker Compose setup on a modest VPS. Build a simple knowledge base from your existing docs. See how fast the workflow builder lets you iterate. That's the right way to evaluate whether Dify fits your team's needs. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help self-hosting Dify? Getting Dify into production โ€” Docker Compose, PostgreSQL, Redis, vector database selection, Traefik for HTTPS, Ollama integration for local models, and wiring your first knowledge base from existing documentation โ€” has more moving parts than most self-hosted tools. I can handle the full setup and build your first RAG workflow from your actual runbooks and docs. You get a production-ready AI application platform without spending a week on it. Get in touch at pipoline.com โ†’

devopspack.com

Nomad is the orchestrator I reach for when Kubernetes is too much machine for the job. Here's what it is, how the Nomad Autoscaler handles both apps and cluster nodes, and where it fits.

HashiCorp Nomad + Autoscaler: Orchestration Without the Kubernetes Tax

Not every workload needs Kubernetes. I say that as someone who runs Kubernetes in anger โ€” and who has also spent enough late nights debugging a control plane to know when the complexity isn't paying for itself. For a lot of teams, especially ones running a mix of containers and plain old binaries on a handful of nodes, Kubernetes is too much machine for the job. That's the gap HashiCorp Nomad fills. It's a scheduler and orchestrator that does one thing well โ€” places workloads on machines and keeps them running โ€” without dragging in a dozen other moving parts. And once you pair it with the Nomad Autoscaler, you get the elastic, scale-with-demand behaviour that most people assume only Kubernetes can give you. This is an honest look at what Nomad is, how the autoscaler actually works, where it shines, and where it doesn't. ## What Nomad actually is Nomad is a workload orchestrator from HashiCorp. You give it a job โ€” "run 5 instances of this container, here are the resources each needs" โ€” and Nomad figures out which machines have room, schedules the work there, restarts anything that dies, and reschedules onto healthy nodes when a machine goes down. That's the core loop. The part that sets it apart is what it's willing to schedule. Kubernetes orchestrates containers, full stop. Nomad orchestrates containers _and_ raw binaries, Java JARs, QEMU virtual machines, and batch jobs โ€” through a pluggable task driver model. If you have a legacy service that was never containerised, Nomad will still run it under the same scheduler as everything else. That single trait is why a lot of brownfield shops pick it. A few things worth knowing about the architecture: * **One binary.** The same `nomad` binary runs as a server (the control plane, using Raft consensus) or as a client (the agent that runs your workloads). No etcd, no separate scheduler, controller, and API server processes to babysit. * **It integrates, it doesn't absorb.** Service discovery, secrets, and networking are handled by its siblings Consul and Vault if you want them โ€” but Nomad also has built-in service discovery now, so a small setup needs nothing else. * **Multi-region and multi-datacenter** are first-class concepts, not bolt-ons. * **It scales far.** Nomad has famously run clusters in the tens of thousands of nodes, and it's used in production by the likes of Cloudflare and others. The simplicity isn't a toy-scale tradeoff. As of mid-2026 the current line is **Nomad 2.0** , which arrived alongside HashiCorp's new versioning and support model. It's a mature project, not a moving target. ## A word on licensing (be honest about this) Nomad is not open source anymore, and I'd rather say that plainly than let you find out later. In August 2023 HashiCorp moved Nomad โ€” along with Terraform, Vault, Consul and the rest โ€” from the MPL 2.0 open-source licence to the **Business Source License (BSL/BUSL) 1.1**. It's now "source-available": you can read, modify, and use it freely, including in production, for basically everything _except_ offering a competing commercial product or hosted Nomad service. Each release also re-licenses to MPL 2.0 four years after it ships. For the vast majority of self-hosters and internal platform teams, nothing about your day-to-day changes. But it's a real consideration if your business model is "we host orchestration for others." HashiCorp itself is now part of IBM, following the acquisition that closed in 2025 โ€” worth keeping in mind when you're betting infrastructure on a vendor's long-term direction. ## Getting a cluster running Unlike most tools I cover here, Nomad isn't really a "docker compose up" affair โ€” it's a single binary you run as a system service. For local experimentation, though, you can have a working cluster in one command: # Single-node dev cluster โ€” server + client in one process nomad agent -dev -bind 0.0.0.0 -network-interface eth0 That gives you the full API and UI on `http://localhost:4646`. From there a job spec is just HCL. Here's a minimal one running an nginx container: job "web" { group "frontend" { count = 2 network { port "http" { to = 80 } } task "nginx" { driver = "docker" config { image = "nginx:stable" ports = ["http"] } resources { cpu = 200 # MHz memory = 128 # MB } } } } `nomad job run web.nomad.hcl` and you have two load-balanced nginx allocations. For production you'd run the binary under systemd on each node, point clients at the servers, and front it with Consul or a reverse proxy โ€” but the job spec is identical whether it's your laptop or a 50-node cluster. ## The Nomad Autoscaler โ€” the actual point of this post Out of the box, Nomad keeps the count you asked for. It does not change that count on its own. The **Nomad Autoscaler** is what makes the cluster elastic, and it's a deliberately separate piece of software: its own binary, its own release cycle, its own GitHub repo. You run it as a long-lived daemon โ€” almost always deployed as a Nomad job itself, so the thing that scales your cluster is scheduled by the cluster. The whole design is plugin-based, and it helps to think in three plugin categories: * **APM plugins** โ€” _where the metrics come from._ Nomad's own metrics, Prometheus, or Datadog. This is the signal that drives decisions. * **Target plugins** โ€” _what actually gets scaled._ A Nomad task group, or a cloud autoscaling group: AWS ASG, GCP managed instance group, Azure VMSS. * **Strategy plugins** โ€” _how the decision is made._ The common one is `target-value` (keep some metric near a target, e.g. 70% CPU), plus `threshold`, `pass-through`, and `fixed-value`. With those pieces, the autoscaler covers two distinct jobs. ### 1. Horizontal application autoscaling This changes the **allocation count of a task group** โ€” more copies of your service when load rises, fewer when it falls. You declare it right inside the job spec with a `scaling` block: group "frontend" { count = 2 scaling { enabled = true min = 2 max = 10 policy { cooldown = "1m" evaluation_interval = "10s" check "cpu_load" { source = "prometheus" query = "avg(nomad_client_allocs_cpu_total_percent{task_group='frontend'})" strategy "target-value" { target = 70 } } } } } This says: keep average CPU around 70%, never drop below 2 or climb above 10 allocations, and wait a minute after any change before acting again. Note the `check` block โ€” a policy can have several, querying different metrics, and the autoscaler reconciles them. That's a big step up from the early days when a policy could only watch one number. ### The built-in Nomad APM โ€” scaling without Prometheus You don't actually need Prometheus to get started. The autoscaler ships with a built-in **Nomad APM** that reads CPU and memory straight from Nomad's own state โ€” no external monitoring stack at all. It's the default: if you omit the `source` field, this is what runs. Queries use a simple `<operation>_<metric>` form instead of PromQL: check "cpu_usage" { # No `source` line also works โ€” the Nomad APM is the default source = "nomad-apm" query = "avg_cpu-allocated" # avg CPU across the group's allocations query_window = "1m" strategy "target-value" { target = 70 } } Operations are `avg`, `min`, `max` and `sum`; metrics are `cpu`, `memory`, `cpu-allocated` and `memory-allocated`. There's one honest limit worth knowing: the Nomad APM only understands CPU and memory. The moment you want to scale on request latency, queue depth, or anything application-specific โ€” or scale a cluster all the way down to zero clients โ€” you reach for Prometheus or Datadog instead. But for the bread-and-butter case of "run more copies when CPU climbs," the built-in APM gets you there with zero extra infrastructure, which is exactly the kind of low-friction default that fits Nomad's whole philosophy. ### 2. Horizontal cluster autoscaling The other half: adding and removing **actual client nodes**. When your jobs can't be placed because there's no room, the autoscaler talks to your cloud provider's scaling group and brings up more machines; when the cluster is over-provisioned, it drains a node gracefully (so allocations migrate cleanly) and terminates it. The target here is something like `aws-asg` or `gce-mig` instead of a task group, but the policy structure is the same. This is the piece that turns "fixed fleet of servers" into "pay for what you're actually running." ### A note on vertical scaling There's also **Dynamic Application Sizing** โ€” the autoscaler recommending right-sized CPU/memory values for your tasks rather than changing counts. Be aware this one is an **Enterprise-only** feature, not in the community build. The two horizontal modes above are free. ## Nomad vs Kubernetes โ€” the honest comparison This is the question everyone actually has, so let me not dodge it. **Where Nomad wins:** operational simplicity. One binary, a config file, and you have a cluster โ€” the conceptual surface area is a fraction of Kubernetes. It schedules non-containerised workloads, which K8s simply can't. It's lighter on resources, so it's viable on small clusters and edge nodes where a full K8s control plane would be absurd. For a team that wants orchestration without hiring a platform team to run the orchestrator, it's a genuinely different cost structure. **Where Kubernetes wins:** the ecosystem, and it's not close. Helm charts, operators, CNI plugins, service meshes, a CNCF universe of tooling, and an enormous hiring pool already fluent in it. If you need something, someone has built a K8s solution for it. Nomad's autoscaler is clean and capable, but the Kubernetes scaling story โ€” HPA, VPA, Cluster Autoscaler, KEDA for event-driven scaling โ€” is broader and more battle-tested across edge cases. And "everyone already knows Kubernetes" is a real, unglamorous advantage when you're hiring. The honest summary: Nomad is the better tool for a surprising number of teams, and the worse _career_ bet for a surprising number of engineers. Both of those things are true at once. ## When Nomad fits โ€” and when it doesn't **Pick Nomad if:** you run a mix of containerised and non-containerised workloads; you want orchestration without a dedicated platform team; you're at small-to-medium scale, on-prem, or at the edge; or you value being able to understand your whole stack in an afternoon. The autoscaler then gives you elasticity without bolting on a separate scaling system. **Skip Nomad if:** your team and tooling are already deep in Kubernetes and it's working; you depend heavily on the CNCF ecosystem (operators, service meshes, the Helm world); you need vertical autoscaling and don't want to pay for Enterprise; or the BSL licensing is a dealbreaker for your organisation. In those cases the friction of being a smaller community isn't worth it. ## My take Nomad is one of those tools that quietly makes you question how much accidental complexity you've been carrying. The first time you run a real workload on it and realise there's no control plane to nurse, no etcd to back up, no fifteen YAML files for a single service โ€” it's a small relief that adds up. The autoscaler extends that same philosophy: it does horizontal app and cluster scaling cleanly, it's configured in the same HCL you already write, and it stays out of your way. I won't pretend it's the right call everywhere. The licensing change is a real mark against it, and the gravitational pull of the Kubernetes ecosystem is hard to argue with. But for the right workload โ€” heterogeneous, modest-scale, run by a small team โ€” Nomad plus the autoscaler is a genuinely sane place to be. It's the orchestrator I reach for when Kubernetes feels like answering a question nobody asked. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help setting up a Nomad cluster with autoscaling? Standing up a production Nomad cluster โ€” servers in Raft consensus, clients with the right task drivers, Consul for service discovery, Vault for secrets, the Autoscaler as a Nomad job with Prometheus or the built-in APM, plus cluster autoscaling tied to AWS ASG, GCP MIG or Azure VMSS โ€” takes experience to get right. I can handle the full setup and tune the scaling policies to your actual traffic instead of guesswork. You get orchestration with elastic scaling that stays boring โ€” which is the highest compliment infrastructure can earn. Get in touch at pipoline.com โ†’

devopspack.com

Dokploy is the open source PaaS that gives you Heroku-style deployments on your own VPS โ€” Git push to deploy, automatic SSL, databases, and Docker Compose support, all on infrastructure you own. Here's how it works and how it compares to Coolify and CapRover.

Dokploy: Open Source PaaS That Replaces Heroku on Your Own VPS

The managed PaaS providers โ€” Heroku, Vercel, Railway, Render โ€” solved a real problem: deploying an app shouldn't require configuring Nginx, provisioning SSL, writing deployment scripts, and managing servers. Push your code, get a URL. That convenience is genuinely valuable. The problem is the bill. Those platforms keep raising prices, adding per-seat fees, and charging for bandwidth that used to be free. At some point you look at a $200/month Render bill for what's running on infrastructure you could rent for $12 and wonder why you're paying the difference. Dokploy gives you the same push-to-deploy experience on your own VPS. Open source, Docker-based, with automatic SSL via Traefik โ€” you get Heroku's workflow on a $6/month server you control. ## What Dokploy is Dokploy is a free, open-source, self-hostable Platform-as-a-Service built on Docker and Traefik. It provides a clean web dashboard for deploying applications and databases on your own infrastructure, without the complexity of Kubernetes or the recurring fees of managed platforms. It's Apache 2.0 licensed โ€” genuinely open source, not source-available โ€” with 32,500+ GitHub stars. You install it with a single command on any VPS or bare metal server, and start deploying in minutes. There's also a managed Dokploy Cloud option billed per server, where Dokploy runs the management dashboard while your apps stay on your own servers. The core proposition: the developer experience of Heroku or Vercel, the cost structure of a plain VPS, and full ownership of your data and infrastructure. ## Core features * **Git-based deployments** โ€” connect a GitHub, GitLab, Gitea, or Bitbucket repository and Dokploy deploys automatically on push. The push-to-deploy workflow that made Heroku famous. * **Docker & Docker Compose** โ€” deploy any Dockerized application, or bring a full `docker-compose.yml` and Dokploy runs the whole stack. * **Automatic SSL** โ€” Traefik handles Let's Encrypt certificates automatically. Add a domain, get HTTPS, no certbot. * **Database provisioning** โ€” one-click PostgreSQL, MySQL, MariaDB, MongoDB, and Redis with backups. * **Preview deployments** โ€” spin up a temporary environment for each pull request, just like Vercel. * **Multi-server & Docker Swarm** โ€” manage deployments across multiple servers and scale with Swarm clusters from one dashboard. * **Templates** โ€” one-click deploy for common open source apps (many of the tools covered on this blog). * **Monitoring** โ€” real-time CPU, memory, and deployment status from the dashboard. * **API & CLI** โ€” automate deployments programmatically. ## Built on Traefik Worth highlighting for readers who've followed the Traefik post on this blog: Dokploy uses Traefik as its reverse proxy under the hood. This is why SSL and routing "just work" โ€” when you add a domain to an app in Dokploy, it's configuring Traefik labels for you behind the scenes. If you already understand Traefik, Dokploy will feel familiar โ€” it's essentially a polished management layer over the same Docker + Traefik stack you'd otherwise configure by hand. The difference is the dashboard, the Git integration, and the database provisioning that you'd otherwise wire together yourself. ## Installation Dokploy installs with a single command on a fresh VPS running a recent Linux distribution: curl -sSL https://dokploy.com/install.sh | sh This installs Docker if it's not present, sets up Dokploy itself, and starts the dashboard on port 3000. Point your browser at `http://your-server-ip:3000`, create an admin account, and you're ready to deploy. The whole process takes a few minutes. The recommended minimum is a VPS with 2GB RAM, though 4GB+ gives you comfortable headroom for running multiple apps and databases. Providers like Hetzner and DigitalOcean are popular choices โ€” a Hetzner CX22 (2 vCPU, 4GB RAM) at around โ‚ฌ4/month runs a meaningful number of small apps. ## Deploying your first app The typical workflow: 1. Create a new project in the dashboard 2. Add an application, connect your Git repository 3. Choose the build method โ€” Dockerfile, Nixpacks (auto-detect), or Docker Compose 4. Set environment variables 5. Add a domain โ€” Dokploy provisions SSL automatically via Traefik 6. Deploy โ€” every subsequent push to the configured branch redeploys automatically For a Docker Compose project, you point Dokploy at the repo, it reads your `docker-compose.yml`, and runs the full stack. This makes it trivial to self-host any of the Docker Compose-based tools covered on this blog โ€” Ghost, Outline, Formbricks, Plane โ€” through Dokploy's dashboard rather than SSHing in and running compose commands manually. ## Dokploy vs the alternatives **vs Coolify** โ€” Coolify is the most popular open source PaaS and the most direct competitor. Both are Apache-licensed, Docker-based, and self-hostable. Coolify is more mature with a larger community and more features; Dokploy has a cleaner, more minimal interface and strong Docker Swarm multi-server support. If you want the most battle-tested option, Coolify. If you want a more modern, minimal experience, Dokploy. **vs CapRover** โ€” CapRover is the established, stable choice that's been around longest. It's proven and reliable but feels dated compared to newer tools. Dokploy has a more modern UI and better Docker Compose support. CapRover wins on maturity and stability; Dokploy on developer experience. **vs Heroku / Render / Railway** โ€” the managed platforms require zero infrastructure management โ€” no server to maintain, no updates to apply. You pay for that convenience with recurring fees that scale with usage. Dokploy trades a small amount of operational responsibility (you maintain the VPS) for dramatically lower costs and full data ownership. For a side project the managed platforms' free tiers may be simpler; at any real scale, Dokploy on a VPS is far cheaper. **vs Kubernetes** โ€” Kubernetes is the answer when you genuinely need orchestration at scale: hundreds of services, complex scaling, multi-region. For the vast majority of projects, Kubernetes is massive overkill and Dokploy delivers the same deploy-and-forget experience without the operational burden. Dokploy explicitly positions itself as "none of the Kubernetes complexity." ## Who it's for **Good fit:** * Developers and small teams who want Heroku-style deployments without the cost * Anyone tired of managed PaaS pricing scaling faster than their usage * Teams who want to self-host multiple apps and databases on a single VPS * People already comfortable with Docker who want a management layer over it * Agencies deploying client projects who want full infrastructure control * Anyone running the self-hosted tools covered on this blog who wants a dashboard to manage them **Not the right fit:** * Teams who want zero infrastructure responsibility โ€” a managed PaaS is simpler * Organizations genuinely operating at Kubernetes scale โ€” use Kubernetes * Non-technical users uncomfortable maintaining a Linux server ## My take Dokploy hits a sweet spot that matters for anyone running their own infrastructure. It gives you the push-to-deploy convenience that makes managed platforms attractive, on a VPS that costs a fraction of what those platforms charge, with full ownership of your data. For readers of this blog specifically, Dokploy is a natural fit. The tools I've covered โ€” Ghost, Outline, Formbricks, Plane, Cap, Authentik, Invoice Ninja โ€” are all Docker-based and self-hostable. Dokploy gives you a single dashboard to deploy and manage all of them, with automatic SSL via the Traefik stack underneath. Instead of managing a dozen Docker Compose files over SSH, you get a clean interface. The Apache 2.0 license is worth noting after a string of source-available tools (Outline's BSL, Invoice Ninja's ELv2) โ€” Dokploy is genuinely open source with no commercial-use restrictions. Combined with the active development and the fact that it's free to self-host indefinitely, it's one of the most compelling pieces of infrastructure tooling available right now. If you're paying a managed PaaS more than the cost of a VPS, or if you're manually managing Docker deployments across your servers, Dokploy is worth an afternoon of evaluation. The single-command install makes it cheap to try. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help setting up Dokploy? Getting Dokploy into production โ€” VPS provisioning, the initial install, domain and SSL setup, connecting your Git repositories, and deploying your first apps and databases โ€” is straightforward once you know the steps. I can handle the full setup and migrate your existing apps onto it. You get a self-hosted PaaS that costs a fraction of managed platforms, without spending the afternoon figuring it out. Get in touch at pipoline.com โ†’

devopspack.com

Invoice Ninja is the self-hostable invoicing platform that replaces FreshBooks and QuickBooks. Invoices, quotes, recurring billing, 45+ payment gateways, time tracking โ€” your data on your server. Here's what it does and the license catch.

Invoice Ninja: Self-Hosted Invoicing With Full Data Ownership

Freelancers and agencies all eventually face the same question: how do you send professional invoices, accept payments, and track who owes you what โ€” without handing your entire financial history to a SaaS company that can raise prices, change terms, or shut down whenever it wants? Invoice Ninja is the answer for people who want to own their billing data. It's a full invoicing, quoting, and payment platform that you can self-host on your own server, with support for 45+ payment gateways and a feature set that competes directly with FreshBooks and QuickBooks. There's one licensing nuance worth understanding upfront, which we'll cover clearly. ## What Invoice Ninja is Invoice Ninja is an invoicing, billing, and payment management platform built with Laravel (PHP) on the backend and Flutter on the frontend, giving it web, mobile, and desktop apps from a single codebase. It launched in 2014, and version 5 was a complete ground-up rewrite. The current version is in the v5.x line with an active, fast release cycle. It covers the full billing workflow: create and send branded invoices, generate quotes and proposals, set up recurring invoices with auto-billing, track expenses, log billable time, manage projects with Kanban boards, and accept online payments through more than 45 gateways. The client portal lets your customers view invoices, see their payment history, and pay online. It has 9,600+ GitHub stars and is widely used by freelancers and small agencies who want billing software they control. ## The license situation โ€” ELv2 Like Outline, Invoice Ninja deserves a clear explanation of its license before anything else. Invoice Ninja is licensed under the **Elastic License v2 (ELv2)** โ€” the same license Elastic used for Elasticsearch. ELv2 is _source-available_ , not OSI-approved open source. The source code is fully public on GitHub, and you can self-host it freely. What ELv2 allows: * Full access to the source code * Self-hosting for your own business, with all Pro and Enterprise features included * Modifying the code for your own use What ELv2 prohibits: * Offering Invoice Ninja as a hosted service to third parties (a managed SaaS competing with their own hosted offering) * Circumventing the license key functionality * Removing or altering licensing/copyright notices For the typical user โ€” a freelancer or agency self-hosting Invoice Ninja to bill their own clients โ€” ELv2 imposes no practical restriction. You get the full feature set, including everything that's paid on the hosted plans, for free. The restriction only matters if you intend to resell Invoice Ninja as a service to others. Worth noting: when you self-host, all Pro and Enterprise features from the hosted app are included in the source-available code. You're not getting a crippled community edition โ€” you get everything. ## Core features ### Invoicing and quotes Create branded invoices with custom fields, custom CSS, and custom invoice designs. The free tier includes 4 templates; self-hosted gives you all 11 plus full design control. Generate quotes that convert to invoices on approval, create proposals, and set up recurring invoices that bill automatically on a schedule. ### Payments โ€” 45+ gateways This is Invoice Ninja's standout feature. It integrates with more payment gateways than any competitor: Stripe, PayPal, Braintree, Authorize.net, Square, GoCardless, Mollie, WePay, and dozens more. It accepts credit cards, ACH bank transfers, and even crypto. Critically, Invoice Ninja charges no additional fees beyond the gateway's own standard rates โ€” unlike some competitors who take a cut. ### Auto-billing and reminders Set up recurring invoices that automatically charge a client's saved payment method on schedule. Configure automatic payment reminders that chase overdue invoices without you lifting a finger. For agencies with retainer clients or subscription billing, this automates the entire recurring revenue workflow. ### Time tracking and projects Log billable hours, organize work into projects, and visualize task flow with Kanban boards. Time entries link directly to invoices, so you can track work and bill for it without switching tools. ### Expenses Record and categorize business expenses, attach receipts, and link expenses to clients or projects for accurate billing and reporting. Convert billable expenses directly into invoice line items. ### Multi-currency and multi-language Support for multiple currencies with automatic conversion, and multiple languages for both the interface and client-facing documents. For agencies with international clients, this handles the complexity of billing across borders. ### Client portal Each client gets a portal where they can view their invoices, see payment history, approve quotes, and pay online. Self-hosting with the white-label license removes all Invoice Ninja branding so the portal is fully yours. ## Self-hosting Invoice Ninja Invoice Ninja runs on a standard LAMP-style stack: PHP (Laravel), MySQL/MariaDB, and a web server. Docker is the cleanest deployment path. The official Docker Compose setup: services: app: image: invoiceninja/invoiceninja:5 depends_on: - mysql environment: APP_URL: https://invoices.example.com APP_KEY: ${APP_KEY} DB_HOST: mysql DB_DATABASE: ninja DB_USERNAME: ninja DB_PASSWORD: ${DB_PASSWORD} volumes: - ./public:/var/www/app/public - ./storage:/var/www/app/storage ports: - "8000:80" mysql: image: mysql:8 environment: MYSQL_DATABASE: ninja MYSQL_USER: ninja MYSQL_PASSWORD: ${DB_PASSWORD} MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD} volumes: - mysql-data:/var/lib/mysql volumes: mysql-data: Generate the `APP_KEY` with `php artisan key:generate` or use a 32-character random string. Put Traefik or Nginx in front for HTTPS, configure SMTP for sending invoice emails, and you have a production-ready instance. One important note: email deliverability matters more for Invoice Ninja than most self-hosted tools. Your invoices need to actually reach clients' inboxes, not their spam folders. Use a proper transactional email service (Postmark, SendGrid, Amazon SES, or Mailgun) rather than trying to send directly from your server. This is the difference between getting paid on time and clients never seeing the invoice. The minimum viable server is modest โ€” 1-2 CPU cores and 2GB RAM handle a freelancer or small agency comfortably. ## Invoice Ninja vs the alternatives **vs FreshBooks** โ€” FreshBooks is the polished SaaS default for freelancers, with excellent UX and strong accounting features. It's also subscription-priced per client and stores your data on their servers. Invoice Ninja matches most of the invoicing feature set, costs nothing when self-hosted, and gives you full data ownership. FreshBooks wins on polish and built-in accounting depth; Invoice Ninja wins on cost and control. **vs QuickBooks** โ€” QuickBooks is full accounting software; Invoice Ninja is focused on invoicing and payments. If you need full double-entry bookkeeping, tax preparation, and payroll, QuickBooks does more. If you primarily need to send invoices and get paid โ€” and handle accounting separately โ€” Invoice Ninja is leaner and cheaper. **vs Wave** โ€” Wave is free and cloud-based, popular with freelancers. But Wave is SaaS-only with no self-hosting, and has been narrowing its free tier over time. Invoice Ninja gives you the same core functionality with self-hosting and no risk of feature removal. **vs Stripe Invoicing** โ€” Stripe's built-in invoicing is simple and tightly integrated with Stripe payments, but it locks you to Stripe and lacks the broader features (time tracking, projects, expenses, multi-gateway). Invoice Ninja is a full platform; Stripe Invoicing is a feature of a payment processor. **vs Crater / SolidInvoice** โ€” these are genuinely open source (not source-available) invoicing tools. If OSI-approved licensing is a hard requirement, they're worth evaluating. Both are less mature and have fewer payment gateway integrations than Invoice Ninja, but the licensing is cleaner for some use cases. ## Who it's for **Good fit:** * Freelancers and agencies who want to own their billing data * Businesses needing a wide range of payment gateway options * Anyone billing international clients (multi-currency, multi-language) * Teams who want invoicing, time tracking, and expenses in one self-hosted tool * People already running self-hosted infrastructure who want to add billing * Anyone tired of per-client SaaS invoicing pricing **Not the right fit:** * Non-technical users who want zero setup โ€” the hosted plan or FreshBooks is easier * Businesses needing full accounting (bookkeeping, payroll, tax) โ€” QuickBooks does more * Teams with strict OSI open source requirements โ€” Crater or SolidInvoice instead * Anyone who wants the most polished mobile experience โ€” the mobile app lags the web version ## My take Invoice Ninja is the right tool for freelancers and agencies who take data ownership seriously and don't want their invoicing history living on someone else's server. The 45+ payment gateway support is genuinely best-in-class โ€” whatever payment method your clients prefer, it's probably supported. And the fact that self-hosting unlocks all the Pro and Enterprise features for free makes it a remarkable value. The ELv2 license is worth understanding but won't affect you unless you're trying to resell it as a service. For self-hosting to bill your own clients, you get the complete feature set with no restrictions. The one thing I'd emphasize: invest in proper email deliverability from day one. An invoicing tool that sends invoices to spam is worse than useless. Wire it to a transactional email provider and verify your domain's SPF, DKIM, and DMARC records. Get that right and Invoice Ninja becomes a billing system you fully control โ€” which, for anyone running a business on their own terms, is exactly the point. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help self-hosting Invoice Ninja? Getting Invoice Ninja into production โ€” Docker, MySQL, SSL via Traefik, and especially proper email deliverability with SPF/DKIM/DMARC so your invoices actually reach clients โ€” takes experience to get right. I can handle the full setup and wire it into your existing stack. You get a billing platform you fully control, with invoices that land in the inbox. Get in touch at pipoline.com โ†’

devopspack.com

Outline is the fastest, most polished team wiki available โ€” self-hostable, real-time collaborative, and Notion-inspired. There's one catch: it's not actually open source. Here's what it is, how it works, and whether that matters for your team.

Outline: The Best Self-Hosted Team Wiki (And Why It's Not Actually Open Source)

Every growing team eventually hits the documentation problem. Knowledge lives in Slack threads, Google Docs scattered across drives, Notion pages nobody maintains, and the heads of people who've been there longest. Getting that knowledge organized, searchable, and actually used requires a tool people will open voluntarily โ€” which means it needs to be fast, clean, and not feel like work. Outline solves this. It's a team wiki and knowledge base that feels like a modern SaaS product rather than an enterprise content management system from 2008. The editing experience is genuinely good. Search is fast. And you can run it on your own server. There's one important thing to understand before you deploy it: Outline is not open source. ## What Outline is Outline is a team knowledge base and wiki platform built for speed, collaboration, and a clean editing experience. It's written in Node.js and React, with a Notion-inspired editor, real-time collaborative editing, structured collections, full-text search, and integrations with Slack, GitHub, and dozens of other tools. It's available as a hosted cloud service at getoutline.com, or self-hostable on your own infrastructure. The source code is publicly available on GitHub. It has 30,000+ GitHub stars and is widely used in the tech community as an internal documentation platform. What it's not: truly open source. More on that below. ## The license situation โ€” BSL 1.1 This matters and deserves a clear explanation before anything else. Outline is licensed under **Business Source License 1.1 (BSL)** โ€” the same license HashiCorp used when it moved Terraform away from MPL 2.0 in 2023. BSL is not recognized as an open source license by the Open Source Initiative. It's more accurately described as _source-available_. Outline's BSL converts to Apache 2.0 on March 18, 2030. What BSL allows: * Access to the full source code * Self-hosting for internal use within your organization * Modifying the code for your own use What BSL prohibits: * Selling Outline as a hosted service to others * Reselling Outline or hosting it as a service for customers * Any commercial use that competes with Outline's own business For the vast majority of teams โ€” those who want to self-host a wiki for their own organization โ€” BSL is not a problem at all. You can self-host Outline, use it internally, and modify it to your needs without any license concerns. The restriction hits if you try to resell it or offer it as a hosted service. For teams with strict open source procurement requirements โ€” government agencies, enterprises with OSI-approved-only policies โ€” BSL disqualifies Outline. In that case, AGPL-3.0-licensed alternatives like AppFlowy, Docmost, or Wiki.js are the right path. With that said clearly: if you're self-hosting for your own team, BSL is fine and Outline is excellent. ## Core features ### Editor The editor is Outline's biggest differentiator. It's a block-based rich text editor with Markdown shortcuts โ€” type `##` for a heading, `---` for a divider, ````` for a code block. It supports slash commands for inserting any block type, inline comments, mentions, and embeds from external services. Writing in Outline feels closer to writing in Notion than filling in a wiki form. ### Collections and structure Documents live inside Collections โ€” roughly equivalent to spaces or sections. A collection might be "Engineering", "Product", "HR", or "Onboarding". Within collections, documents nest infinitely. The sidebar shows the hierarchy, and navigation is fast. Permissions are set at the collection level: public (anyone in the workspace), members-only (specific invited people), or view-only. This gives you a simple but functional access control model for keeping some documentation restricted to specific teams. ### Real-time collaboration Multiple people can edit the same document simultaneously. Changes appear in real time with user cursors visible. For teams working on documentation together โ€” writing a spec, updating a runbook โ€” this works cleanly and without the conflicts you'd get in a traditional wiki. ### Search Full-text search across all documents in your workspace. Outline's search is fast and surfaces results inline as you type. Given that a knowledge base is only useful if people can find things, this matters more than most features. Search in Outline is noticeably faster than Confluence and most other team wikis. ### Integrations Outline integrates natively with: * **Slack** โ€” search Outline from Slack, get unfurl previews for shared links, post document updates to channels * **GitHub** โ€” link pull requests and issues directly in documents * **Figma, Miro, Loom, Airtable** โ€” embed live previews inline in documents * **Linear, Jira** โ€” link issues to documentation * **Google Docs, Dropbox Paper** โ€” import existing documentation * **Zapier / n8n** โ€” trigger automations on document events via webhooks ### API Outline has a REST API covering documents, collections, users, and search. This enables automation: sync docs from your codebase, create runbooks programmatically, or build integrations with your internal tools. The API is well-documented and covers all core resources. ## Self-hosting Outline Outline's self-hosted stack requires Node.js, PostgreSQL, Redis, and storage (local filesystem, S3, or S3-compatible like MinIO). Docker Compose is the standard deployment path. The official Docker Compose setup: services: outline: image: outlinewiki/outline:latest env_file: .env ports: - "3000:3000" depends_on: - postgres - redis postgres: image: postgres:16 environment: POSTGRES_DB: outline POSTGRES_USER: outline POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} volumes: - postgres-data:/var/lib/postgresql/data redis: image: redis:alpine volumes: postgres-data: Key environment variables you'll need to configure in `.env`: SECRET_KEY= # generate with: openssl rand -hex 32 UTILS_SECRET= # generate with: openssl rand -hex 32 DATABASE_URL=postgres://outline:${POSTGRES_PASSWORD}@postgres:5432/outline REDIS_URL=redis://redis:6379 URL=https://wiki.example.com PORT=3000 # Auth โ€” pick one or more: SLACK_CLIENT_ID= SLACK_CLIENT_SECRET= GOOGLE_CLIENT_ID= GOOGLE_CLIENT_SECRET= OIDC_CLIENT_ID= # works with Authentik, Keycloak, etc. OIDC_CLIENT_SECRET= OIDC_AUTH_URI= # Storage AWS_S3_UPLOAD_BUCKET_URL= AWS_ACCESS_KEY_ID= AWS_SECRET_ACCESS_KEY= One important note: Outline requires an external authentication provider. It doesn't ship with its own username/password auth โ€” you need to connect Slack, Google, GitHub, or an OIDC provider. For self-hosted setups, Authentik is a natural pairing: configure Authentik as the OIDC provider, and Outline uses it for login. Put Traefik or Nginx in front for HTTPS and you have a production-ready instance. Minimum viable server is 1-2 CPU cores and 2GB RAM for small teams; scale PostgreSQL and Redis as usage grows. ## Outline vs the alternatives **vs Confluence** โ€” Confluence is the enterprise default, deeply integrated with the Atlassian ecosystem (Jira, Bitbucket). It's feature-complete but slow, visually dated, and expensive at scale. Outline is dramatically faster, more pleasant to write in, and significantly cheaper. If you're not locked into the Atlassian ecosystem, Outline is the better writing experience. **vs Notion** โ€” Notion is the modern benchmark for all-in-one workspaces: docs, databases, kanban boards, calendars. Outline is more focused โ€” it's specifically a knowledge base and wiki, not a general workspace. Outline is faster and cleaner for documentation specifically. Notion can't be self-hosted. For teams that want Notion's editor feel with data ownership, Outline is the closest match for documentation. For Notion's full feature set including databases, AppFlowy is the closer match โ€” see below. **vs AppFlowy** โ€” AppFlowy is the closest open source replacement for Notion's full workspace experience, not just documentation. AGPL-3.0 licensed (genuinely open source, unlike Outline's BSL), built with Flutter and Rust, with native desktop apps for macOS, Windows, and Linux that run offline by default and sync to AppFlowy Cloud when available. Where AppFlowy wins: full Notion-style relational databases (grid, kanban, calendar, gallery views), local-first architecture with SQLite, native apps with offline support, AI features that can be pointed at local Ollama models for full privacy, and a strict OSI-approved license. Where Outline wins: the focused wiki experience is more polished for documentation specifically, search is faster, Slack integration is deeper, and the web-based architecture means no client app to install. Resource footprint also differs โ€” AppFlowy Cloud self-hosted needs 4-8 GB RAM, Outline runs comfortably on 2 GB. **Pick Outline if** your primary use case is team documentation and a fast wiki. **Pick AppFlowy if** you need a full Notion replacement with databases, kanban boards, and offline native apps. They're solving different problems despite the visual similarity. **vs Docmost** โ€” Docmost is an AGPL-3.0-licensed alternative that's genuinely open source (unlike Outline's BSL). It supports real-time collaboration, Drawio/Excalidraw/Mermaid diagrams natively, and built-in email/password auth โ€” no external OIDC required. It's less mature and has fewer integrations than Outline, but it's the right choice for teams that need a true open source license without AppFlowy's resource footprint. **vs BookStack** โ€” BookStack is PHP-based, simpler, and genuinely open source (MIT). It has a books/chapters/pages structure that's intuitive for non-technical users. Outline has a better editing experience and better search. BookStack is easier to set up and requires no external auth provider. **vs Wiki.js** โ€” Wiki.js is AGPL-3.0, highly configurable, and supports multiple storage backends including Git. It has more configuration options than Outline but requires more setup. Outline is faster and more polished out of the box. ## Who it's for **Good fit:** * Engineering and product teams who want a fast, modern wiki for internal documentation * Teams coming from Notion who want self-hosting and data sovereignty for their docs * Organizations that need Slack integration as a first-class feature * Teams already running Authentik or another OIDC provider for SSO * Anyone who has suffered through Confluence and wants something better **Not the right fit:** * Teams needing a full Notion replacement with relational databases and kanban โ€” use AppFlowy * Teams with strict OSI open source requirements โ€” use AppFlowy, Docmost, or Wiki.js instead * Teams without an existing auth provider โ€” Outline requires one, which adds setup overhead * Non-technical users who need the simplest possible setup โ€” BookStack is easier * Teams that need native desktop apps with offline support โ€” AppFlowy is the answer ## My take Outline is the best wiki experience available for self-hosted teams. The editor is fast, the search works, the Slack integration is genuinely useful, and the overall UX is closer to what you'd expect from a paid SaaS product than an open source tool. For any team that's been fighting Confluence or managing scattered Notion pages for documentation, it's worth deploying. The BSL license is worth being clear about: it's not open source, and if you have procurement policies that require OSI-approved licenses, AppFlowy or Docmost are your answers. But for the overwhelming majority of teams self-hosting for internal use, BSL doesn't affect you and Outline is excellent. If you need the full Notion replacement experience โ€” databases, kanban boards, calendars, native offline apps โ€” AppFlowy is the better choice. It's genuinely open source under AGPL-3.0 and the closest open source project to feature parity with Notion. The trade-off is heavier resource requirements and a less polished web experience compared to Outline. Pick the tool that matches what you're actually trying to replace. The auth requirement is the friction point most teams hit first with Outline. If you're already running Authentik โ€” which we've covered on this blog โ€” wiring it to Outline is straightforward and the result is SSO across your entire self-hosted stack. If you're starting from scratch, plan for the auth setup as part of the deployment. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help setting up Outline or AppFlowy? Getting either Outline or AppFlowy into production โ€” PostgreSQL, Redis, storage, OIDC auth via Authentik, SSL via Traefik, and backups โ€” has more moving parts than most self-hosted tools. I can handle the full setup for whichever fits your use case and wire it into your existing stack. You get a production-ready team workspace without spending a day on it. Get in touch at pipoline.com โ†’

devopspack.com

Plane is the open source project management tool that replaces Jira, Linear, and Asana. Issues, cycles, modules, and roadmaps โ€” self-hostable, with full data ownership. Here's what it does and how it compares.

Plane: Open Source Project Management That Replaces Jira

Project management tools are a category where the open source options have historically been weak. Jira is the enterprise default and most people have a complicated relationship with it. Linear is beautiful but closed-source and SaaS-only. Asana, Monday, ClickUp โ€” all proprietary, all priced per seat, all storing your project data on their servers. Plane is the open source answer. Issue tracking, cycles, modules, roadmaps, and project planning in a tool you can self-host and own completely. It's the project management platform for teams that want Linear's modern UX without giving up control of their data. ## What Plane is Plane is an open-source project management and issue tracking tool. It covers the full workflow most software teams need: issues with rich properties, sprint planning through cycles, feature grouping through modules, long-term planning through roadmaps, and documentation through an integrated wiki-style Pages feature. The project is licensed primarily under AGPL-3.0 with some components under Apache 2.0, has 50,000+ GitHub stars, and is one of the fastest-growing open source projects in the productivity space. It's available as managed cloud, a self-hosted Community Edition, and Commercial/Enterprise editions with additional features. ## Core concepts * **Issues** โ€” the atomic unit of work. Rich text descriptions, sub-issues, properties (priority, state, assignees, labels), attachments, links, and comments. The foundation everything else builds on. * **Cycles** โ€” time-boxed sprints. Assign issues to a cycle, track burndown, and see what your team committed to versus completed. This is Plane's sprint mechanism. * **Modules** โ€” group related issues into a larger feature or initiative that spans multiple cycles. Track progress on a feature independent of which sprint the work happens in. * **Views** โ€” saved filters and groupings. List, Kanban board, calendar, spreadsheet, and Gantt views of your issues with custom filters you can save and share. * **Pages** โ€” a built-in wiki/docs feature with AI assistance. Write specs, meeting notes, and documentation right next to your issues. * **Roadmaps** โ€” long-term planning view showing initiatives and their timelines across the project. ## Views and flexibility Plane's view system is one of its strengths. The same set of issues can be displayed as a List for quick scanning, a Kanban board for workflow visualization, a Calendar for deadline-driven work, a Spreadsheet for bulk editing, or a Gantt chart for timeline planning. Filters and grouping are saveable as named Views that you can share with your team โ€” "my open high-priority issues", "everything due this week", "the current cycle grouped by assignee". This flexibility means Plane adapts to how different teams and individuals want to work rather than forcing one workflow. ## Self-hosting Plane Plane is self-hostable via Docker. The Community Edition is free and covers the core project management feature set. The stack includes the Plane app, PostgreSQL, Redis, and MinIO for file storage. The recommended setup uses the official installation script: curl -fsSL https://raw.githubusercontent.com/makeplane/plane/master/deploy/1-click/install.sh | sh This sets up the full stack via Docker Compose with sensible defaults. For production you'll want to configure external PostgreSQL, set up proper backups, and put a reverse proxy like Traefik or Nginx in front for HTTPS. The minimum viable server is modest โ€” 2 CPU cores and 4GB RAM handle a small team comfortably. Larger teams will want to scale the database and add resources, but Plane isn't resource-hungry for typical usage. ## Plane vs the alternatives **vs Jira** โ€” Jira is the enterprise incumbent with the deepest feature set and the widest integration ecosystem. It's also complex, slow, and expensive. Plane is dramatically simpler, faster, and self-hostable. For teams that find Jira overwhelming โ€” which is most teams โ€” Plane covers the actual workflow without the overhead. Jira wins on enterprise-scale features, compliance certifications, and the integration marketplace. **vs Linear** โ€” Linear is the modern benchmark for issue tracking UX, and Plane is clearly inspired by it. Linear is more polished and has a faster, more refined interface. Plane's advantage is open source and self-hosting โ€” Linear is SaaS-only and closed. For teams that love Linear's approach but need data ownership or want to avoid per-seat pricing, Plane is the closest open source equivalent. **vs Asana / Monday / ClickUp** โ€” these are general-purpose work management tools aimed at broader audiences than software teams. Plane is more developer-focused with its issue/cycle/module model. If your team is engineering-led, Plane fits more naturally. If you need broad cross-functional work management, the others may fit better. **vs OpenProject / Redmine** โ€” the established open source project management tools. Both are powerful but feel dated. Plane offers a significantly more modern interface and developer experience while remaining open source. ## Who it's for **Good fit:** * Software teams who want Linear-style issue tracking without SaaS lock-in * Teams with data sovereignty or compliance requirements that rule out cloud PM tools * Organizations tired of Jira's complexity and looking for something simpler * Teams already self-hosting infrastructure who want to add project management to their stack * Startups who want to avoid per-seat pricing as they grow **Not the right fit:** * Teams needing deep enterprise integrations and a large app marketplace โ€” Jira still wins there * Non-technical teams who want the absolute most polished SaaS experience โ€” Linear or Asana * Teams who don't want to manage any infrastructure and prefer a fully managed tool without self-hosting consideration ## My take Plane is the most credible open source project management tool available right now. It hits the sweet spot between Jira's overwhelming complexity and the closed-source nature of Linear. The issue/cycle/module model maps cleanly to how software teams actually work, and the multiple view types mean it adapts to different working styles. For any team running self-hosted infrastructure โ€” especially one already using tools like Gitea, GitLab, or the others covered on this blog โ€” Plane completes the picture. You get modern project management that lives on your own servers, with your data under your control, and no per-seat pricing as your team grows. It's not as polished as Linear yet, and it's not as feature-complete as Jira for enterprise edge cases. But for the vast majority of software teams, Plane covers what you actually need with a far better experience than the alternatives โ€” and it's open source. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help self-hosting Plane? Getting Plane into production โ€” Docker, PostgreSQL, Redis, MinIO, SSL via Traefik, SMTP for notifications, and backups โ€” takes time to set up properly. I can handle the full deployment and wire it into your existing stack. You get a production-ready project management platform without spending a day on it. Get in touch at pipoline.com โ†’

devopspack.com

Formbricks is the open source survey platform that replaces Typeform, SurveyMonkey, and Hotjar's feedback widgets in one self-hostable tool. Unlimited responses, in-app micro-surveys, event-based targeting, and full data ownership.

Formbricks: Open Source Surveys, In-App Feedback and Full Data Ownership

Every SaaS product eventually needs to ask users questions. How satisfied are you? Why are you cancelling? What feature would you pay for? The answers are worth a lot โ€” but the tools to collect them are surprisingly expensive, privacy-questionable, and often overkill for what you actually need. Typeform charges per response at scale. SurveyMonkey is enterprise-priced and closed-source. Hotjar bundles surveys into a broader analytics platform you might not want. And all of them store your user feedback on their servers. Formbricks is the open source answer: a full survey and experience management platform that combines Typeform-style link surveys, website feedback widgets, and in-app micro-surveys in one self-hostable product. Unlimited responses, your data, your server. ## What Formbricks is Formbricks is an open-source survey and experience management platform. It lets you create and deploy surveys across multiple channels from a single dashboard: * **Link surveys** โ€” a dedicated URL you share via email, social, or embed anywhere. Works like Typeform. * **Website surveys** โ€” popup or inline surveys that appear on specific pages. Works like Hotjar Ask. * **In-app surveys** โ€” targeted micro-surveys triggered by user behavior inside your web application. The most powerful and differentiated capability. * **Email surveys** โ€” embed survey questions directly into emails, no redirect required. The project is AGPLv3 licensed with 12,000+ GitHub stars, trusted by teams including Siemens, Cal.com, and the Ethereum Foundation. Version 4.7 ships attribute data types, SOC 2 Type II certification, advanced CSS customization, improved self-hosting tooling, and a long list of quality-of-life improvements. ## The in-app survey engine This is what separates Formbricks from simple form builders. The in-app survey SDK lets you trigger surveys based on user behavior โ€” not just "show this to everyone" but "show this to users who have been on the pricing page for more than 30 seconds" or "show this when a user completes their third export." The event-based triggering system works by installing a lightweight JavaScript SDK in your application: import { formbricks } from "@formbricks/js"; formbricks.init({ environmentId: "your-environment-id", apiHost: "https://formbricks.example.com", }); // Trigger a survey on a custom event formbricks.track("export_completed"); // Or set user attributes for targeting formbricks.setAttributes({ plan: "pro", company_size: "50-200", days_since_signup: 14, }); In the Formbricks dashboard you then define survey triggers: "show the churn survey when a user clicks the cancel button" or "show the feature discovery survey to Pro users who haven't used the export feature after 7 days." No code changes required after the initial SDK integration โ€” the survey logic lives in the dashboard. This is the capability that makes Formbricks genuinely powerful for product teams. You can run targeted NPS surveys to users on specific plans, show onboarding surveys to new signups, trigger cancellation surveys at the exact moment someone tries to leave, and collect feature feedback from users who have actually used that feature. ## Survey types and question formats Formbricks supports the full range of question types you'd expect: * Rating scales (NPS, star rating, numerical) * Multiple choice (single and multi-select) * Open text (short and long form) * Picture choice * Date picker * File upload * Matrix questions * Ranking * Address fields * Contact info Survey logic lets you branch based on previous answers โ€” show different follow-up questions depending on NPS score, skip sections for specific user segments, and end the survey early for users who aren't relevant targets. Multi-language surveys are now free for everyone. The template library covers the most common survey use cases out of the box: NPS, CSAT, PMF (Product-Market Fit), churn surveys, feature discovery, onboarding feedback, and more. Starting from a template rather than blank is the right call for standard feedback collection. ## Analytics and response handling Formbricks now tracks impressions, starts, completions, and drop-offs in one view. You can also trigger surveys based on page dwell time. The response dashboard shows individual responses and aggregate data with filtering by user attributes, date ranges, and survey variants. For more sophisticated analysis, Formbricks integrates with the tools you're already using: Slack (post new responses to a channel), Notion (create database entries), Airtable, Google Sheets, HubSpot, Zapier, Make.com, and n8n. The webhook integration covers custom destinations. ## Self-hosting Docker Compose is the standard self-hosting path. The stack requires Formbricks itself plus PostgreSQL: services: postgres: image: postgres:15 environment: POSTGRES_DB: formbricks POSTGRES_USER: formbricks POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} volumes: - postgres_data:/var/lib/postgresql/data formbricks: image: ghcr.io/formbricks/formbricks:latest depends_on: - postgres ports: - "3000:3000" environment: DATABASE_URL: postgresql://formbricks:${POSTGRES_PASSWORD}@postgres:5432/formbricks NEXTAUTH_SECRET: ${NEXTAUTH_SECRET} NEXTAUTH_URL: https://formbricks.example.com ENCRYPTION_KEY: ${ENCRYPTION_KEY} volumes: postgres_data: Put Traefik or Nginx in front for HTTPS and you have a production-ready Formbricks instance. The self-hosted version has no response limits โ€” you pay for infrastructure, not per answer. Formbricks offers flexible deployment: self-host via Docker for data sovereignty or use GDPR-compliant managed cloud. For EU teams with GDPR requirements, self-hosting removes any question about where survey response data lives. ## Pricing The free cloud tier includes 1,000 responses per month, unlimited surveys, and all integrations. The Startup plan at $49/month unlocks in-app surveys, advanced targeting, and removes response limits. Self-hosting is free beyond infrastructure costs with no feature gates on the core platform. Compared to Typeform: Formbricks offers more features on the free plan, is roughly 30% cheaper on paid plans, and is the only open source Typeform alternative that lets you self-host for complete data ownership. ## Formbricks vs the alternatives **vs Typeform** โ€” Typeform is more polished and has the brand recognition. Formbricks is open source, self-hostable, cheaper, and adds in-app survey capabilities Typeform doesn't have. Typeform doesn't support in-app micro-surveys, pop-up surveys, or targeted feedback widgets. Team collaboration is capped at 3 members even on paid plans. **vs Google Forms** โ€” Google Forms is free and everyone knows how to use it. For simple internal surveys it's hard to beat. For anything requiring custom branding, targeting, in-app deployment, or data privacy โ€” Formbricks. **vs Hotjar Ask / Sprig / Refiner** โ€” these are in-app survey tools that charge per monthly tracked user, often $50-200+/month. Formbricks self-hosted covers the same in-app survey use case with no per-user pricing. **vs SurveyMonkey** โ€” SurveyMonkey is enterprise-priced and overkill for most product teams. SurveyMonkey lacks in-app survey deployment and self-hosting options. **vs Tally** โ€” Tally is great for standalone forms but does not offer in-app surveys or the targeting capabilities that make Formbricks powerful for product teams. ## Who it's for **Good fit:** * SaaS product teams who need in-app micro-surveys with event-based targeting * Teams with GDPR or data sovereignty requirements โ€” self-host and your responses never leave your infrastructure * Startups who need Typeform-quality surveys without Typeform pricing * Developers who want to embed surveys in their application with a proper SDK * Teams already running self-hosted infrastructure who want to consolidate tools **Not the right fit:** * Non-technical users who want the absolute simplest setup โ€” Google Forms or Tally are easier * Enterprise teams needing complex offline survey distribution or kiosk modes * Teams that need only simple contact forms โ€” a lightweight form handler is simpler ## My take Formbricks earns its standout status by solving a real problem โ€” collecting contextual user feedback โ€” with a transparent open source approach. The in-app survey capabilities are genuinely impressive for a free tool. Self-hosting with unlimited responses removes the cost anxiety that plagues most survey platforms. For any team building a SaaS product, the in-app survey engine is the feature that matters most. Being able to ask the right user the right question at the right moment in their journey โ€” triggered by actual behavior, not a random timer โ€” is the difference between actionable product feedback and noise. Formbricks delivers this without requiring an enterprise contract. The AGPLv3 license is worth noting: if you distribute a modified version of Formbricks, you need to open-source your changes. For internal use or self-hosting without distribution, this isn't a concern. * * * PIPOLINE ยท DEVOPS CONSULTING ### Need help self-hosting Formbricks? Getting Formbricks into production โ€” PostgreSQL, Docker, SSL via Traefik, SMTP for notifications, SDK integration in your application โ€” is straightforward if you know what you're doing. I can handle the full setup and connect it to your existing stack. You get a production-ready survey platform without spending a day on it. Get in touch at pipoline.com โ†’

devopspack.com