Company ·DarDev Team · 5 min read

Why DarDev self-hosts open source software

DarDev runs Twenty CRM, Listmonk, Stalwart, and product stacks on infrastructure we operate—not because SaaS is bad, but because open source self-hosting matches Deployed Realities.

Open source containers and self-hosted infrastructure diagram on a server rack

DarDev self-hosts open source software because we sell operational credibility, not slide decks. Twenty CRM, Listmonk, Stalwart MTA, and a custom sync worker run on a VPS we patch and back up ourselves. Product workloads ship through the same Kubernetes-native pipeline we document for clients. That trades vendor convenience for inspectable code, consent models we can explain to lawyers, and failures we feel before recommending the pattern externally.

This is not an anti-SaaS manifesto. We document when SaaS wins in our self-hosted email decision record. We self-host where integration depth, sending identity, and CRM-to-campaign boundaries matter more than shaving two weeks off initial setup.

What we run and why it is open source

The Unified Mailer stack on dardev-vps is the clearest example. Twenty holds prospect and customer records. Listmonk sends opted-in product news. Stalwart terminates SMTP for send.dardev.net. A sync worker promotes contacts to Listmonk lists only when consent fields change—never on cold CSV import. Each component is open source with a license we can read and upgrade paths that do not require a sales call.

  • Twenty CRM: workspace permissions, webhooks, GraphQL API we audit for bulk imports
  • Listmonk: list-centric campaigns, SQL-friendly subscriber tables, REST hooks
  • Stalwart: queue visibility, DKIM signing, SMTP logs for deliverability postmortems
  • PostgreSQL and Redis: standard persistence we snapshot in runbooks

Product engineering—Hesabi, DarDevLab, and internal services—runs on Kubernetes with GitLab CI, Prometheus, and Grafana, as described in our Kubernetes-native product pipeline guide. Prefer components whose behavior we can trace in source and reproduce in staging.

Four reasons self-hosting won for us

Deployed Realities requires dogfooding—we publish architecture we operate, as defined in what we mean by Deployed Realities. Recommending CRM-driven list sync without running it would violate that bar. When a webhook secret expires or a DKIM key needs rotation, our engineer learns it before a client does.

Consent routing is custom. Hesabi, DarDevLab, and EscaHire waitlist interest each map to distinct Listmonk audiences only after explicit opt-in; cold imports stay in Twenty until promotion. SaaS hubs can approximate this with enterprise tiers and Zapier chains; self-hosting encodes rules in a worker we diff in git.

Sending identity must stay separate from corporate inbound mail. Campaigns use send.dardev.net with dedicated SPF, DKIM, and DMARC while root @dardev.net mail stays on Zoho. Operating Stalwart means we own bounce classification instead of waiting on a vendor ticket during a launch.

At our scale, contact-tier SaaS pricing climbs faster than a modest VPS once multi-product lists grow. We pay in engineer hours—patching, backups, Twenty API rate limits—but that cost is visible on our roadmap instead of hidden in renewal invoices.

Tradeoffs we accept openly

Self-hosting shifts work from subscriptions to runbooks. On dardev-vps we compose Docker stacks, terminate TLS at host nginx, and monitor sync worker health before large sends. We own Postgres disk pressure, webhook rotation, and cert expiry on mta.dardev.net—parallel to the cluster ownership tradeoffs in managed versus self-hosted Kubernetes in MENA.

  • Major Twenty or Listmonk releases get staging before production overlay bump
  • OS and container patches on a weekly cadence, not when a vendor emails
  • Prometheus alerts on queue depth, sync lag, and HTTP 5xx

When we would choose SaaS instead

We advise SaaS when the team sends one newsletter, lacks ops capacity for MTA maintenance, or needs vendor SOC reports for procurement. Startups validating message-market fit before compliance hardening benefit from managed warming. Open source does not automatically mean self-host—we pick managed Postgres where it reduces toil and self-host where the integration surface is the differentiator.

How this shapes what we publish and sell

Articles like Inside the Unified Mailer stack and our self-hosted email decision record describe wiring we maintain. DarDev Services engagements start from those records—not generic slides. When we say a pattern works, it is because we restarted the sync worker at 02:00 or rolled back a bad Listmonk deploy last quarter.

Open source application logos connected to a self-hosted Docker and Kubernetes deployment
Self-hosting open source buys inspectable integrations; SaaS buys speed when requirements stay simple.
Why open source instead of proprietary self-hosted tools?

Source availability and portable skills matter for a consulting shop hiring across MENA. Engineers can read Twenty or Listmonk behavior under pressure and carry knowledge to the next client without a proprietary certification track.

Does self-hosting mean DarDev never uses SaaS?

No. We use SaaS where integration depth is shallow and vendor SLAs beat operator time—corporate inbound mail on Zoho is the everyday example. Self-host where consent routing, sending identity, or CRM sync is the differentiator.

How does this relate to Hesabi and DarDevLab?

Hesabi and DarDevLab are product accounts with their own application mail rules. The Unified Mailer handles marketing and opted-in product news lists. Hesabi fiscal features are Tunisia-only; self-hosting philosophy does not change regional availability.

What is the biggest mistake teams make when self-hosting open source?

Treating install as done. Production requires backup restore drills, upgrade staging, and on-call ownership. Teams that skip staging fidelity—SQLite in dev, Postgres in prod—debug fiction.

Can DarDev help our team adopt a similar stack?

Yes through DarDev Services. Scope includes consent model design, DNS identity, CRM-to-Listmonk sync, and runbooks—not only docker compose up. We recommend patterns we operate on dardev-vps and client clusters.

Get company news

Releases and announcements — confirm from your inbox.

Subscribe to updates