Matthew Meszaros 50711a8e66 fix: a campaign's linked segments are its audience, so detaching one withdraws its leads (#510) (#523)
* fix: make a campaign's linked segments the audience rather than an accumulator, so detaching one withdraws the leads it enrolled instead of leaving the old list mixed in with the new, tracked by a new campaign_leads.source that keeps a hand-picked lead, an overlapping segment's member and anyone the campaign has already emailed out of the withdrawal, and reported back as withdrawn/contacted counts the dialog confirms and explains (issue #510)

* fix: serialize the linked-segment sweep against a link replacement by taking the same campaign lock, so a sweep that read the old set cannot re-enrol the audience the replacement just withdrew, and word the dialog's confirm and toast so the campaign, not the segment, is what has already emailed a lead

* fix: stop the one-shot segment enrol from re-stamping leads that are already in the campaign, since the Leads tab's Add back runs through it and pinning a whole linked audience as hand-picked because one held-out member was restored is the accumulation this change exists to end

* fix: lock the leads a detachment is about to withdraw before deciding, because a send is reserved by stamping campaign_contact_progress and only then locking the lead row, so a reservation committing mid-pass was invisible to the delete's snapshot and could withdraw a lead whose first email had already gone; and report the already-emailed count on every toast branch, since a detach where the whole audience had been emailed changed no count and said nothing after confirming a removal

* fix: add the campaign_leads.source check constraint NOT VALID, which still enforces every insert and update while skipping a full scan of the largest table in the product under ACCESS EXCLUSIVE to learn that a one-statement-old column holds its own default everywhere
2026-09-14 22:12:15 -07:00
2026-01-17 09:19:43 +00:00

Warmbly

The open-source agentic cold email and warmup platform.

Discord Follow @WarmblyHQ on X Docs CI status Latest release License

Features · How it works · Quick start · Self-hosting · Docs · Community · Support

⭐ Help us reach more senders and grow the Warmbly community. Star this repo!

Warmbly

Warmbly runs cold email campaigns from the mailboxes you already own and warms them so they keep landing in the inbox. Opens, clicks, and replies land in a shared dashboard the moment they happen, and it's AI-native, so your team and its agents work in it together, live.

https://github.com/user-attachments/assets/378a510a-bb99-425f-925e-04300184938b

Features

  • Campaigns - multi-step sequences with per-mailbox caps and spacing
  • Unified inbox - every mailbox and reply in one place
  • CRM - contacts, pipelines, deals, tasks, meetings
  • Warmup - a pool of monitored mailboxes, not throwaway accounts
  • Deliverability - bounces, complaints, suppression, inbox placement
  • Automations - visual reply playbooks with AI steps
  • Integrations - HubSpot, Slack, Zapier, REST API, webhooks
  • Realtime - live presence and edits across your team

Campaigns Unified inbox

How it works

Warmbly splits into a control plane (backend API, consumer, Postgres, Redis, and the event bus) that owns all state, and an execution plane of interchangeable Go workers that send and sync mail. Workers never touch Postgres, and outbound mail leaves through each mailbox's own provider, not the worker's IP, so you add throughput by running more workers.

flowchart LR
  MB["Your mailboxes"] --> API
  subgraph CP["Control plane"]
    direction TB
    API["Backend API"] --> DB[("Postgres")]
    API --> BUS{{"Event bus"}}
  end
  BUS --> W1["Worker"]
  BUS --> W2["Worker"]
  BUS --> W3["Worker"]
  W1 --> P["Gmail · Microsoft · SMTP"]
  W2 --> P
  W3 --> P
  P --> R["Recipients"]

Secrets use envelope encryption, with a local AES master key by default or AWS KMS if you prefer. Full write-up in the architecture docs.

Quick start

You need Docker, Go 1.25, and pnpm.

git clone https://github.com/warmbly/warmbly && cd warmbly
make dev

Open http://localhost:5173 and log in with dev@warmbly.com / password123; the login code lands in Mailpit at http://localhost:18025. Every make target, the native services, and how seeding works are in the local development guide.

Warning

make dev and make up share one database, and seeded fixture accounts claim the instance. Planning to self-host from the same machine? Read first run first.

Self-hosting

Runs on Docker Compose

Warmbly runs with no cloud account of any kind: no AWS, no GCP, no Stripe, no Kafka. One command brings up the whole platform on local, open-source pieces:

curl -fsSL https://warmbly.com/install.sh | sh

That pulls the published release images, writes a real .env, starts the stack and prints the one-time link that claims the instance and makes you its admin. No clone, no compiler, under two minutes. Add --wizard and it asks where each store lives, what is kept and for how long, and how it is backed up. The script is checksummed at install.sh.sha256 if you would rather download, verify and read it first, --dry-run prints every file it would write without touching anything, and --demo walks the whole wizard while installing nothing. Full flag list: install.

To build it from source instead:

git clone https://github.com/warmbly/warmbly && cd warmbly
make up

Either way you need Docker with Compose v2; the build path also wants about 10 GB of free disk. If anything looks wrong, make doctor prints the instance state and every failing check.

From here the self-hosting guide covers the rest: your own secrets, production hardening, mail and single sign-on, HTTPS, connecting Gmail and Microsoft mailboxes, scaling workers, and backups. Account recovery and every operator command live in warmblyctl, the CLI baked into the backend image; it talks to the database directly, so it works when signing in does not.

Documentation

The full docs live at docs.warmbly.com.

Read this To learn
Install The one-command install and its wizard: where the data lives, what is kept, how it is backed up
Self-hosting guide Building from source, then production, backups, and scaling the worker fleet
Data control Every store's location, every retention window, instance backups, and moving to another host
First run Claiming the instance, reissuing the setup link, and what to do when accounts already exist
Accounts and access Registration modes, inviting people with or without a mail relay, SSO, and recovering access
warmblyctl The operator CLI: creating accounts, setting passwords, granting admin, and instance status
Configuration reference Every environment variable, its default, and whether changing it needs a restart
Instance health The checks the admin panel runs against your deployment, and make doctor
Troubleshooting The errors self-hosters actually hit, and the command that fixes each one
Local development Every make target, the native services, and how seeding works
Architecture How the control plane and workers split the job, plus the encryption model
API reference Endpoints, auth, permissions, and webhooks

Community

Have a question, found a bug, or want to shape where Warmbly goes next?

  • Discord - chat with the team and other senders
  • GitHub Issues - report bugs and request features
  • X / @WarmblyHQ - follow along for updates and releases
  • Email - reach us at team@warmbly.com

Support and enterprise

Note

Need a hand? We are happy to help. Ask in Discord, open a GitHub issue, or email team@warmbly.com, and someone on the team will get back to you.

Running Warmbly at scale, or would you rather we run it for you? We offer enterprise support and managed infrastructure: we can host and operate the whole platform for your organization, help you deploy and scale the worker fleet, tune deliverability, migrate your sending onto Warmbly, and stand behind it with a support agreement built around your team. Tell us what you need at team@warmbly.com or reach out on X.

Follow @WarmblyHQ on X Join the Discord Email the team

Star the repository ⭐

warmbly-star

Contributing

Pull requests are welcome. Keep each one to a single logical change, and open an issue first for larger design or product changes. Before you open a PR, run the checks for the tree you touched (make fmt and make lint for Go, pnpm typecheck and pnpm lint for the frontends). See CONTRIBUTING.md.

Security

Found a vulnerability? Email team@warmbly.com instead of opening a public issue. We prefer responsible disclosure and credit reporters in the release notes.

License

Apache License 2.0. Copyright 2026 Mindroot Ltd. See LICENSE.

Languages
Go 50.6%
TypeScript 35.1%
Astro 5.2%
Swift 5.1%
Shell 1.1%
Other 2.8%