Warmbly is the open-source platform for email warmup and cold outreach. Everything that decides whether your email lands in the inbox is in a public repository, and you can run all of it yourself.
For years the main tools for cold email have charged by the mailbox while keeping their warmup logic, sending rules and abuse thresholds closed. You paid for volume. You never got to see how decisions about your reputation were made.
We started Warmbly to take that away. The workers that send your mail, the warmup pools, the encryption and the health rules all live in a public repository under Apache 2.0.
So when Warmbly slows a mailbox down, the dashboard says why in a full sentence, and the sentence is written by code you can open. The figure beside this is a real one: the reason a throttled mailbox shows, and the lines of service.go that wrote it.
Founders, agencies, sales teams, recruiters and fundraisers can read the engine, run it on their own servers if they want, and stop paying a tax on every mailbox they add.
We are a small team building in public. We say what we are working on, we don’t invent numbers, and the product gets better where everyone can see it.
When deliverability breaks on a closed platform, you can’t read the code that broke it. You can only write to support and wait.
These aren’t values for a slide. They are written into the codebase, and a feature that breaks one doesn’t ship. Each pair below sits next to the code or the record that proves it.
The whole platform is on GitHub under Apache 2.0: sending, warmup pools, health thresholds and abuse checks. If you want to know why a mailbox was paused, you can read the code that paused it.
The changelog is public and dated, and every entry maps to a merged change. We don’t invent metrics or pretend to be bigger than we are.
A safe day of sending is the sum of what each mailbox can safely send. We will not ship a feature that pushes a mailbox past its own limits to make a chart look better.
Our thresholds for the shared warmup pool are stricter than the points where Google or Amazon SES start penalising a sender. By the time a provider would act, the mailbox has already been slowed down.
Mailbox credentials are encrypted with a dedicated credentials key, and message content with a data key that belongs to your workspace alone.
Every health state, suppression and pool block comes with a reason you can read in the dashboard, and the rules behind them are documented.
Adding capacity means adding small workers, not growing one giant server. Your mailbox provider delivers the mail, so a worker is only where your mailbox signs in from, and Warmbly keeps that stable.
The backend and consumer hold your data, decide which mailbox sends what and when, and assign each mailbox to a worker.
Commands go out on a topic per worker and results come back on one shared stream, over NATS or Kafka.
They sign in to your mailboxes, send, sync and report back. They hold no database connection, so one that goes away is simply replaced.
| Warmbly | Closed-source tools | |
|---|---|---|
| Source code | Apache 2.0 on GitHub. Read it, fork it, run it. | Closed. You see the dashboard, not the engine. |
| Where it runs | Our cloud, or your own servers with one command. | Their cloud only. |
| Health rules | Documented, and stricter than provider enforcement. | Undocumented until something goes wrong. |
| Changelog | Public and dated, one entry per merged change. | Announcements on a marketing schedule. |
| Pricing | Per workspace, with unlimited mailboxes and warmup. | Often per mailbox or per seat. |
This describes how Warmbly is built. We don’t speak for any other company’s plans or pricing.
Start free on Warmbly Cloud, or install the whole platform on your own server with one command.
