Warmbly combines outreach operations under your control
Warmbly puts several pieces of a cold-outreach stack into 1 self-hosted system. Campaign sequences, mailbox warmup, a unified inbox, CRM records, deliverability data, automations, and integrations sit together. That helps teams avoid copying state between a sender, pipeline, and automation service, but it also makes Warmbly a serious operational application.
The project looks young but active. The snapshot shows 238 GitHub stars, release v0.4.0 published on September 5, 2026, and a last push on September 6. Work continued after the release, and only 6 issues were open. Still, buyers should not assume years of production experience or a huge troubleshooting community.
What happened when we ran it
Our run used commit 885a7c2 in an unprivileged Debian container with 3 CPUs, 8 GB of RAM, no secrets, and golang:1.24-bookworm. Installation succeeded in 74 seconds and installed 797 packages. Dependency setup completed cleanly in a fresh environment rather than relying on a prepared developer machine.
The build succeeded in 250 seconds. Tests completed in 189 seconds, with 149 Go tests passed and 0 failed. We measured 3,790 files, about 470,378 lines of source, and a 29.4 MB checkout. The repository had 4 CI workflows and a Compose file, but our scan found no Dockerfile or dedicated tests directory. Those last 2 observations concern layout, not test quality.
This was a source test, not a production deployment. We connected 0 mailboxes, so provider authorization, inbox placement, event delivery, and backup restoration remain unverified. The passing tests establish build health at the tested commit, not campaign effectiveness.
The architecture is the clearest reason to choose it
Warmbly separates a control plane from an execution plane. The API, Postgres, Redis, and event bus own state, while Go workers send and synchronize mail without direct Postgres access. That 2-part design lets operators add workers while keeping database ownership centralized, and messages still leave through each mailbox provider rather than a worker IP.
The product layer is broad but coherent. Multi-step campaigns include per-mailbox caps and spacing; replies, opens, and clicks feed 1 shared dashboard; CRM objects cover contacts, pipelines, deals, tasks, and meetings. Visual reply playbooks can include AI steps, while HubSpot, Slack, Zapier, a REST API, and webhooks provide escape routes when Warmbly is not the system of record.
Self-hosting has received unusual attention for an early project. The installer claims to write an environment file, launch release images, and print a 1-time admin link. It supports a wizard, dry run, demo mode, and SHA-256 checksum. The source path requires Docker, Compose, Go 1.25, pnpm, and about 10 GB of free disk; make doctor reports failing instance checks.
Security and recovery are addressed concretely. Secrets use envelope encryption with a local AES master key or AWS KMS, and warmblyctl can access the database when sign-in is unavailable. The documentation covers retention, migration, accounts, configuration, health, troubleshooting, backups, scaling, HTTPS, and SSO. For v0.4.0, that operator focus is a real strength.
Its breadth also creates the main risks
A codebase of roughly 470,378 source lines carries a large maintenance and security surface. Operators own the application plus Postgres, Redis, the event bus, workers, encrypted secrets, mailbox credentials, HTTPS, and backups. The README's 1-command installation may start containers quickly, but a running stack is not a hardened, recoverable service.
The development and self-hosting paths need careful separation. The README warns that make dev and make up share 1 database and seeded fixture accounts can claim the instance. That is useful candor, but also an easy footgun on a future production host. Read the first-run guide and use dry-run before installation.
There is no supplied evidence that Warmbly improves inbox placement against competitors. It exposes bounces, complaints, suppression, and placement data, but features are not outcomes. With 238 stars and a v0.4.0 tag, pilot at controlled volume, confirm provider behavior, test suppression, and perform a real restore before a wider rollout.
Recent activity is healthy, but the community is still small
Release v0.4.0 was 2 days old on the review date, and the repository was pushed 1 day before review. Combined with 6 open issues and 4 CI workflows, that indicates active engineering. Discord and X offer support channels beyond GitHub, but the supplied evidence does not show response time, contributor diversity, or long-term release regularity.
The trending snippet reports a gain of 41 stars, suggesting a recent burst of attention. That is encouraging, but 238 total stars still describes an emerging project. Teams needing formal support should evaluate the advertised enterprise path directly, because a fresh release and low issue count cannot prove response quality.
It fits as the outreach control layer, not the mail server
Warmbly belongs between team workflows and existing mailbox providers. Its 2 planes coordinate campaign state, replies, CRM activity, and workers, while Gmail, Microsoft, or SMTP handles outbound transport. Another CRM can remain authoritative through integrations, and webhooks can carry events internally. Postal fits better when the need is mail-delivery infrastructure itself.
Choose listmonk for opt-in newsletters, or Mautic when broader marketing automation outweighs mailbox warmup and shared replies. Choose Warmbly when owned deployment, real mailbox providers, campaign operations, and 1 integrated inbox matter together. For v0.4.0, start with a limited pilot, harden production, measure provider results, and verify a backup restore before scaling workers.