The cold outreach
platform you can read.
Warmbly is the open-source alternative to the closed-source warmup and cold outreach suites. Same surface area, fewer black boxes. The whole engine is on GitHub.
Cold outreach deserves an open engine.
For years, the dominant tools in this category have charged near a hundred dollars per inbox, per month, while keeping their warmup logic, sending heuristics, and abuse-detection thresholds completely closed. You paid for throughput. You did not get to see how decisions were made on your behalf.
When deliverability breaks on a closed platform, you cannot read the code that broke it. You can only ask support, then wait.
We started Warmbly to remove that opacity. The control plane, the workers, the warmup pools, the encryption model, the quarantine bands. Everything that decides whether your mail lands in the inbox or the spam folder lives in a public repository under Apache 2.0.
The positioning is straightforward. Warmbly is the only credible open-source alternative in cold outreach. Founders, agencies, sales teams, recruiters, and fundraisers can read the engine, run it on their own infrastructure if they want, and stop paying per-inbox tax to closed competitors.
We are a small team building in public. We do not hide what we are working on. We do not invent metrics. We do not pretend to be larger than we are. The product gets better in public.
Two planes. One rule per lane.
The backend decides. The workers execute. They communicate through Kafka and nothing else. This separation is the reason we can scale send volume by adding small workers instead of growing one giant runtime.
Owns the relational state. Decides which mailbox sends what, when, and on which worker. Reads Postgres. Speaks to Stripe, KMS, S3. Never opens an SMTP socket itself.
One process per machine. One IP per worker. Receives commands from a worker-specific Kafka topic. Sends, syncs, validates, heartbeats. State is disposable. A crashed worker is replaced by another reading the same topic.
Six rules we will not bend.
These are not marketing values. They are constraints written into the codebase and the migrations. If a feature breaks one of them, we do not ship it.
The whole platform is on GitHub under Apache 2.0. Sending logic, warmup pools, abuse thresholds, fraud heuristics. If you want to audit how a quarantine decision was made, you can read the code that made it.
A worker is not a flat send limit. Its safe daily volume is the sum of its mailbox budgets, full stop. We will not ship a feature that bypasses the per-mailbox cap to make a chart look better.
Sending is intentionally distributed. No central choke-point that becomes a single reputation liability. Adding volume means adding mailboxes and workers, not cranking a few harder.
Our thresholds for the shared paid warmup pool are stricter than what Google, Microsoft, or SES will tolerate. We act in the warning band, not the catastrophe band. By the time a provider penalises you, we have already pulled the mailbox.
Application secrets and sensitive payloads use AWS KMS envelope encryption. A per-organization DEK. AES-256-GCM at the field level. Plaintext keys only ever live in a Redis cache with a TTL. The repo says it. The migrations enforce it.
Every health band, every suppression entry, every pool block has a reason you can read in the dashboard and a row you can read in the database. The product owes you the same explanation in both places.
Open engine versus closed engine.
A factual comparison of posture, not a feature audit. Other tools in this category may match individual capabilities. None of them open up the engine.
Comparison reflects how Warmbly is built. We do not speak for any other vendor's plans or pricing.
What is in the repository.
The full platform, top-level. Backend, consumer, workers, tracking, realtime, web, and the encryption primitives that hold them together.
Small team. Built in public. Open source.
We are a small group of engineers. We will not pretend to be a global enterprise. Issues on GitHub are read by the people writing the code. Contact emails reach a person, not a queue.
Because the team is small, the constraints we put on the codebase have to do the heavy lifting. Safe defaults, conservative warmup, layered abuse controls, encryption everywhere we touch user secrets. We would rather ship one fewer feature than ship a feature that puts your sending reputation at risk.
You can follow the work in public. Open issues, pull requests, and the changelog. Everything that matters is visible.
Read the engine. Run the engine. Improve the engine.
The open engine for cold outreach.
Read the source. Run it yourself. Or start sending today on the hosted platform.