Warmbly Cloud for self-hosted instances

A self-hosted Warmbly instance warms mailboxes only against the other mailboxes on that same instance, which for most installs is a handful. Linking the instance to Warmbly Cloud lets those mailboxes warm in the hosted pool instead: thousands of real, monitored mailboxes exchanging natural-looking mail, with replies and inbox engagement handled for you.

Only warmup moves to the cloud. Campaigns, contacts, the unibox, tracking and every stored message stay on your server exactly as before. Linked instances also get Google and Microsoft sign-in through Warmbly's own OAuth apps, so there is no client to register: see Google and Microsoft mailboxes. They can also have Cloud serve a sending domain's root redirect, so the domain answers visitors without any proxy setup on your server.

New connections link one local workspace to one Warmbly Cloud workspace. A Cloud workspace can have only one active self-hosted connection, including any older instance-wide link. New connections for different local workspaces need different Cloud workspaces, each with its own plan. Existing server-wide connections keep serving their local workspaces without reconnecting or buying another plan. Self-hosted workspace creation itself is unlimited; hosted creation limits and request-rate protection are unchanged. When you enroll a mailbox, the instance sends that mailbox's SMTP/IMAP credential to the cloud, sealed in transit and at rest with the same envelope encryption the hosted product uses for every customer mailbox. From then on:

• Warmbly Cloud sends the mailbox's warmup mail, replies to partners, and rescues, opens and stars the warmup mail it receives, on Warmbly's own workers
• the mailbox's warmup ramp, hours and days belong to Warmbly Cloud from then on, starting from the ones it had on your instance, and its timezone stays your instance's (see warmup settings). Cloud does not automatically enable its weekday sending-behavior profile for these warmup-only mailboxes. A Cloud profile you explicitly configure still takes precedence while enabled.
• the cloud reads only verified warmup mail from the mailbox. Everything else that arrives is dropped unread; no history is imported and nothing is stored
• your instance stops its own warmup for that mailbox and takes it out of the local warmup pool, so no mailbox on your server writes to it any more, and keeps sending campaigns from it as usual
• your instance recognises both received warmup and the mailbox's own Sent copies and leaves them out of your unibox, asking the cloud to vouch for anything it cannot identify on its own

Verification accepts a cloud token only for the mailbox that sent or received that warmup message. It also recognises recorded message identifiers when a provider strips the header, including older messages and mail the cloud has already processed. If the cloud cannot answer, inbox ingestion retries verification before publishing the message. This can delay ordinary inbox arrivals for enrolled mailboxes during a cloud outage. Existing Unibox entries are checked automatically in background batches, and confirmed warmup is removed locally without deleting provider mail. When the cloud cannot answer for one mailbox, the rest of that mailbox's entries wait while every other mailbox's entries keep being checked. Once the current check has been through every mailbox, the waiting one is retried from where it stopped: straight away if it got through some entries before failing, otherwise 15 minutes later and then at doubling intervals until the next daily check. An entry that runs out of time in two background batches in a row holds its mailbox the same way.

Arrivals awaiting verification are stored in your instance's database and retried automatically, including after a consumer restart. Once verification succeeds, ordinary messages enter Unibox and warmup messages are discarded from the pending queue. Pending verification belongs to the instance and is not included in a workspace export.

• health, daily volume and 7 day totals show up in your instance's settings as the cloud reports them, and the health also gates the mailbox's campaigns here (see safety and enforcement)

On upgrade, Cloud disables untouched, inherited default sending profiles on existing instance-enrolled warmup-only mailboxes. Customer-edited profiles, Cloud-managed mailboxes and directly connected Cloud mailboxes keep their settings. Already queued tasks are not pulled forward or replayed; subsequent scheduling uses the corrected calendar, and dispatch still checks current sending rules.

Unenrolling an SMTP/IMAP mailbox, disconnecting the instance, or deleting the mailbox altogether deletes its credential on the cloud immediately. Deleting an enrolled mailbox revokes its enrollment before the record goes, so the pool cannot be left holding a password for a mailbox your instance no longer has; if the cloud cannot be reached at that moment the delete is refused, the mailbox is put back as it was, and retrying it once the cloud is reachable completes it. A mailbox that was signed in through Warmbly Cloud stays in the cloud workspace when you remove it from the instance; disconnecting the instance removes its mirrors of such mailboxes, since they cannot send without the link.

Enrolled mailboxes show Cloud's daily sends, replies, received warmup mail and target volumes in Mailboxes > Analytics. Their warmup placement reports include daily inbox, tabs, spam and rescued counts, provider and host breakdowns, and the trailing inbox rate. Workspace reports combine Cloud-enrolled mailboxes with mailboxes warming locally. Earlier local warmup history stays visible too.

Reports are fetched from Cloud when you open or refresh them, using the existing instance link. They are not copied into your instance's warmup tables and do not wait for the five-minute standing poll. Only enrolled mailboxes belonging to the selected local workspace are requested. A Cloud failure shows a load error and a retry action, not an empty chart.

Existing enrollments work without reconnecting or re-enrolling. Deploy the reporting support on Cloud before upgrading self-hosted instances. Against an older Cloud deployment without these endpoints, Analytics and placement reports that include an enrolled mailbox show a load error until Cloud is upgraded. The Warmbly Cloud card's existing summary counts and standing synchronization use separate endpoints and continue working. No database migration or history backfill is needed.

Once a mailbox is unenrolled, the instance no longer requests its Cloud history. SMTP/IMAP unenrollment deletes the Cloud mailbox and its warmup history; a Cloud-managed mailbox's history stays in its Cloud workspace. The instance's earlier local history is unchanged.

The link is offered on a self-hosted instance as the last step of onboarding when you first sign in, as a banner on Mailboxes until you connect or dismiss it, under Settings > Warmbly Cloud at any time, and on Sending domains when a root redirect could be served from Cloud. Whichever you use, the steps are the same:

1. Select the local workspace you want to connect, then press Connect to Warmbly Cloud. The instance shows an eight character code.
2. Press Open Warmbly Cloud, or go to app.warmbly.com/connect, sign in with your Warmbly account (create one if you do not have it, it is free), enter the code and pick the workspace to link to. The workspace needs the manage settings permission.
3. Your instance notices the approval within a few seconds and moves on to mailbox selection. Switch on the mailboxes you want warmed.

The whole flow takes about a minute. A code expires after 15 minutes if nobody approves it; start again from the instance.

The link belongs to the selected local workspace. Connecting and disconnecting it, and bringing in mailboxes from its Cloud workspace, still requires an instance administrator because credentials leave the server: it needs a platform admin account with the manage settings admin permission (the first owner has it) signed in with two-factor authentication. Once a workspace is linked, its members with the manage mailboxes permission can use that workspace's connection: enrolling, pausing and resuming, and connecting Google and Microsoft mailboxes through Warmbly Cloud. The onboarding step that links the instance is shown only to an administrator who can complete it.

Existing instance-wide connections

Upgrading does not revoke an existing connection or move its mailboxes. The migration records which connection enrolled each mailbox, and existing warmup, brokered access tokens, warmup verification, analytics, standing synchronization, redirects and placement results keep using that original connection. Old placement results and Cloud-served redirects are backfilled to that connection too.

Existing connections work normally after upgrading: you can enroll more mailboxes, connect Cloud mailboxes, sign in with Google or Microsoft, create Cloud-served redirects, and start placement tests within the connected Cloud workspace's plan. Settings > Warmbly Cloud shows the normal connection, plan and mailbox controls, with no separate migration step. You do not need to disconnect or buy another plan to keep using your existing connection.

The one-active-connection limit applies when creating an additional connection, not when using an existing one. A local workspace with an existing connection does not offer another connection setup. A Cloud workspace that already has a connection cannot approve another, including when that connection is shared across a self-hosted server's local workspaces. Existing connections and their mailboxes remain in place. New connection requests are scoped to an unconnected local workspace and require an unused Cloud workspace.

Disconnect is still deliberate and potentially disruptive. Disconnecting a shared server connection affects all local workspaces using it; the confirmation states that scope. Disconnecting a workspace's own connection affects only its mailboxes and redirects. Other connections are unaffected. Removing an SMTP/IMAP enrollment deletes its Cloud mailbox and history; enrolling it again starts a new Cloud enrollment. Cloud-managed mailboxes remain on Cloud, but disconnecting removes their local mirrors. None of this is required by an upgrade.

Deploy the Cloud backend and migration before publishing the self-hosted upgrade. Old self-hosted clients can keep using existing connections, including adding mailboxes, but cannot establish new instance-wide connections. New self-hosted clients refuse to connect to older Cloud versions that do not advertise workspace-scoped support. No new environment variable or data backfill is required for restoring use of existing connections.

On a linked instance, signing in one mailbox under Add account > Google or Add account > Microsoft no longer needs an OAuth client of your own. The sign-in window opens on a Warmbly Cloud page first. It names the address of the instance asking and the Cloud workspace the mailbox will join; press Continue and Warmbly's verified Google or Microsoft app takes over. If you did not start the sign-in yourself, close that page: the mailbox would join the workspace it names. When you approve:

• the mailbox is created in your Warmbly Cloud workspace, where its sign-in lives, and starts warming in the pool right away
• your instance gets a mirror of the mailbox with no credential on it. Campaigns, replies and the unibox work from your server as before; to send and sync, the instance asks the cloud for a short-lived access token (about an hour, cached) using its link token
• the refresh grant never leaves the cloud. Removing the mailbox from either side, unlinking the instance, or the cloud blocking the mailbox stops the instance sending from it within the hour

The sign-in only completes in the browser that pressed Continue, and Cloud only ever sends it back to the address the instance registered when it was linked (its APP_URL). An instance linked before it had an address set cannot use this until you set APP_URL, disconnect it and link it again. The exchange with Google or Microsoft is protected with PKCE, so an authorization code is useless to anyone but Cloud.

These mailboxes show the blue Cloud badge with "Signed in through Warmbly Cloud". The BOX_GOOGLE_* and BOX_OUTLOOK_* variables are still honoured when set, but an instance without them can now connect Google and Microsoft mailboxes as long as it is linked.

Mailboxes connected on the cloud

A Google or Microsoft mailbox you connect directly on app.warmbly.com shows up in your instance's Add account dialog under In your Warmbly Cloud workspace. Press Connect to add it to the instance the same way: the cloud keeps the sign-in, the instance sends with brokered tokens. A mailbox can be linked to one instance at a time.

This includes Google Workspace mailboxes connected on Cloud through Whole Workspace domain, using an administrator's delegation grant. The grant and service-account key stay on Cloud. Your instance receives only short-lived tokens for the individual mailbox, and needs neither its own Google OAuth app nor a domain grant. Cloud keeps the existing mailbox ID, warmup history, ramp and settings. Microsoft mailboxes connected through a whole-organization grant are not offered for adoption.

A Cloud mailbox connected by App password or SMTP/IMAP also appears when the same address has an active SMTP/IMAP connection in the selected local workspace. Connect associates those existing records. Each side keeps its own credentials, so separately generated app passwords work. The action preserves the Cloud mailbox ID, warmup history, settings and pause state, and keeps the local mailbox ID, campaigns and messages. It does not create another mailbox, transfer credentials or restart warmup. A Cloud mailbox used by an active Cloud campaign or another instance cannot be associated. The selected Cloud ID is saved before the request, so retries after a restart keep that exact association. Later local password changes stay local. Disconnecting its Cloud warmup retains both mailbox records and their credentials and history. Disconnecting it individually or disconnecting the whole instance both stop its Cloud warmup sending and receiving.

To keep warming on Cloud while sending campaigns from your instance:

1. Keep the existing Cloud mailboxes. Do not delete them or recreate them with app passwords.
2. On your instance, select the linked workspace and sign in as an instance administrator with two-factor authentication and permission to manage mailboxes.
3. Open Add account, find the addresses under In your Warmbly Cloud workspace, and press Connect for each one. This list does not depend on whether Sign in with Google is enabled for new connections.

Existing Cloud mailboxes appear before the new-account options, inside the Google and Microsoft method choices, and under Settings > Warmbly Cloud and its connection wizard. Search by address or name, then use Connect all or Connect matching to bring in several together. The review explains where warmup and campaigns run and how a matching local mailbox is reused. Progress and successful connections stay visible. A failed mailbox shows its own retry action while the others continue connecting. If the list cannot load, it shows a retry instead of hiding the Cloud option. Existing server-wide connections remain usable without disconnecting them.

If Warm in Warmbly Cloud finds that the address is already on Cloud, an instance administrator is taken directly to this picker, filtered to that address when it is available locally. Choose Connect to confirm the association. Other workspace members see which administrator action is needed. Nothing is associated by address alone, and no Cloud mailbox needs deleting.

When the Cloud mailbox uses Google or Microsoft sign-in or a Google domain grant, Connect switches an existing local app-password mailbox to Cloud-managed access in place. Its mailbox ID, campaigns, imported mail and local history stay. The app-password credential is removed locally after Cloud confirms the adoption. Sync starts from the current provider position rather than importing its history again. An unconfirmed enrollment left by an earlier Warm in Warmbly Cloud attempt can be replaced on the same connection; active enrollments, pending removals and mailboxes owned by another connection must be resolved first. Cancelling an adoption before conversion leaves the local app-password mailbox intact.

Local conversion and consent completion commit together. If the acknowledgement is lost after that commit, recovery keeps the existing local mailbox and retries its status, settings and worker load without treating it as an unfinished new mirror.

Update and settle every Cloud backend replica before adopting delegated mailboxes or associating existing app-password copies, then update self-hosted instances. Migration 000322 adds a nullable selected Cloud ID to existing local enrollment rows; existing rows and credentials are unchanged, with no backfill. The managed-consent protocol and worker messages stay compatible with v0.6.60 and v0.6.61. Those releases can continue reading and writing the expanded schema, and image rollback preserves the new association marker. Do not run the down migration while an association exists; it refuses to discard one. Self-host startup migrations remain the default. Older self-hosted clients can connect a delegated address that is not already present locally once Cloud is updated, but need the new client for the explicit app-password association and independent credential updates. Cloud advertises smtp_association_protocol: 1 for that action; absent support refuses it before local intent or credentials change. Cloud versions through v0.6.61 cannot broker delegated tokens, so keep Cloud on a version supporting delegation while adopted delegated mailboxes are in use. A Cloud rollback preserves mailboxes and history but delegated campaign access needs Cloud upgraded again; already-issued tokens keep their provider expiry. No unlinking, reenrollment or new setting is required.

Which existing mailboxes can be enrolled

Mailboxes connected with SMTP/IMAP (including Google Workspace and Microsoft 365 through an app password) can be enrolled as they are: the instance sends the credential to the cloud and keeps its own copy. Changing the mailbox's SMTP/IMAP settings on your instance later hands the new credential to the cloud as well.

The cloud connects to your mail server over the internet, so both SMTP and IMAP need TLS or STARTTLS. A mailbox set to security none, which only works for a mail server on your instance's own machine, is refused at enrollment with pool_link_cleartext_mailbox.

A Google or Microsoft mailbox that was signed in with your instance's own OAuth app cannot be enrolled, because that grant can only be refreshed by the app that issued it. Remove it and add it again through Warmbly Cloud to warm it there.

A mailbox can warm in the hosted pool without its password or sign-in ever leaving your server. Warmbly Cloud plans the mailbox's warmup as it does for any pool member, and your instance carries out every step with its own workers.

Who can turn it on

It is a separate permission on the linked Warmbly Cloud workspace, granted by Warmbly's operators and not included in any plan. Ask Warmbly support to enable it. Once granted, Settings > Warmbly Cloud offers a choice for each mailbox you can enroll: This server or Cloud. Keep all on this server moves every enrolled mailbox that can be moved at once. Enrolling and switching need the same manage mailboxes permission as any enrollment, and the API takes the same choice as {"executor": "instance"} or {"executor": "cloud"} on POST /cloud-link/mailboxes/:id/enroll. An empty body keeps an enrolled mailbox's current choice.

A mailbox already warming with its credential on Cloud can switch: Cloud deletes its stored credential and keeps the mailbox's ID, settings, history and standing. Switching back hands the current credential to Cloud again. A mailbox signed in through Warmbly Cloud, or one associated with an app-password copy on Cloud, has its credential there by design and cannot switch (cloud_link_self_execution_managed). Without the permission the choice is refused with cloud_link_self_execution_not_granted, and a Cloud too old to offer it refuses with cloud_link_self_execution_unavailable.

What Warmbly Cloud receives

• the mailbox's address, name and provider, as with any enrollment, and no credential of any kind
• warmup mail that arrives in the mailbox: the sender, subject, Message-ID, warmup token, the folder it landed in and its system flags, under an opaque handle your instance issues. Your instance reports only mail it has already recognised as warmup through the existing token and delivery checks. Nothing else in the mailbox is reported, and no message body leaves your server
• later changes to a reported warmup message: removed, moved to spam, or read, unread, starred or unstarred by someone at the mailbox. A change caused by an action Cloud asked for is not reported back as the owner's
• the result of every command: sent with the Message-ID the provider used, failed with an error code, refused with a reason, or expired

How the warmup runs on your server

The consumer asks Warmbly Cloud for due commands every 30 seconds and keeps each one in your database, sealed with the workspace's own key. A command is run at most once, whatever happens to the network or the consumer.

• Sends go through the same send admission as every warmup send on your instance: the mailbox must be active and on a live worker, its daily warmup limit, shared limit and test mode apply, a send to a recipient on the workspace's suppression list is answered refused, and a send waiting on another send or a full window is retried until its deadline. A reservation the worker never began is given back when its command expires, so it never holds the mailbox's campaign or unibox sends. The message goes out exactly as Cloud rendered it, plain text from the mailbox's own address and name
• Engagement (filing out of the inbox, rescuing from spam, marking read, important or starred, and checking where a removed message went) runs on your worker as the same actions local warmup uses, addressed by the handle your instance issued. Without a handle Cloud can only name the mailbox's own sent copy of a warmup message this instance sent for it. Each action carries the command it runs under, and your worker accepts it only for that command, until its deadline or its answer, whichever comes first. An action is reported done only once the worker has accepted it. Local warmup stays stopped for the mailbox either way
• your instance keeps received warmup mail and the mailbox's own sent copies out of your unibox, as it does for any enrolled mailbox, and leaves the filing to Cloud's commands

A command that reaches its deadline before it runs is answered expired and never run. Results and reports wait in a local outbox and are retried with backoff until Cloud takes them, so a Cloud outage delays reporting without losing it. Warmup mail that arrives while Cloud cannot be reached waits in the pending verification queue and is reported once Cloud answers. Settings > Warmbly Cloud shows credential stays on this server next to each such mailbox and a count of commands not run in the last day.

How Warmbly Cloud checks what your server reports

Without the credential Cloud cannot look into the mailbox, so it holds your instance's reports to evidence it can verify:

• Arrivals are recipient-bound. Cloud counts an arrival only when it carries a warmup token minted for that exact mailbox as recipient, or, when the provider stripped the header, the same sender address and Message-ID proof Cloud applies to its own mailboxes. The sender must be the partner that sent it, the Message-ID must match the one that partner's send recorded, and the arrival time cannot precede the send or lie in the future. A repeated report counts once
• Sends are proven by the receiver. A send from a mailbox on your server counts as delivered only when the partner that received it records the arrival. A mailbox whose reported sends never arrive anywhere is dropped from the pool by the same reachability rule every pool member is held to
• Placement is cross-checked. A folder cannot be proven without the credential, so Cloud compares the spam rate each mailbox reports against the rate Cloud itself observed for the same senders at mailboxes of the same provider family it runs directly, over 14 days, once there are enough reports and observations on both sides. A mailbox whose reports diverge goes on probation, and one that diverges further is marked untrusted: its placement reports stop counting toward any other sender's placement, Warmbly's operators are told, and its arrivals still count for reachability. It returns to trusted when its reports agree again
• Engagement must be answered. Cloud accepts an answer only for a command it issued to that connection, and builds the result from its own record of the command, never from identifiers in the report. Every command is answered once; a different second answer is refused. A server that stops asking for commands for five minutes is treated as offline: Cloud stops planning mail through its mailboxes until it returns, and commands it never answers expire and resolve as failures
• The permission can be withdrawn. When the permission is revoked or expires, Cloud leases no further commands, refuses new enrollments with the choice, and pauses warmup in both directions for the mailboxes that keep their credential on your server until it is granted again. Their standing on your instance shows the pause

Versions and rollback

It needs a Warmbly Cloud that advertises the command protocol (self_execution.protocol 1) and an instance with migration 000330. Your instance never calls the command routes on an older Cloud, and existing enrollments are unchanged: every mailbox keeps its credential on Cloud until you choose otherwise. Run the backend, consumer and workers on the same release: the consumer runs the commands, and a worker from an earlier release carries no command with an action, so the backend does not admit it and the action is reported as not run.

Once any mailbox keeps its credential on your server, keep Warmbly Cloud at or above the release that introduced the command protocol. An earlier Cloud release does not know that such a mailbox has no credential and would try to run it on Cloud's own workers. Switch every such mailbox back to Cloud before rolling Cloud below that release.

Rolling the instance back to an earlier release stops the commands, so mailboxes set to keep their credential stop warming until you upgrade again or switch them to Cloud. An earlier release does not know the choice, so changing such a mailbox's SMTP or IMAP settings while on it sends the new credential with its update. Cloud refuses that update (pool_link_executor_conflict) and does not store the credential; only an explicit switch to Cloud hands a credential over. The down migration refuses to run while any mailbox keeps its credential on your server; switch them to Cloud or remove them from the pool first.

Your instance keeps the handle of each reported warmup message until Cloud has had it deleted, until the mailbox stops keeping its credential here, or past the longest warmup retention Cloud can set. Commands, unsent results and these handles belong to the connection and are not included in a workspace export.

Once linked, the Mailboxes page marks every enrolled mailbox with a blue Cloud badge on its address and its avatar and a "Warmed by Warmbly Cloud" line under it (amber while paused), shows the cloud's daily count in the warmup column with the same warming animation local warmup uses, and offers Warm in Warmbly Cloud, pause, resume and remove in each row's warmup menu. The mailbox drawer's Warmup tab shows the same block with the cloud's numbers in place of the local controls. This is shown to members with the manage mailboxes permission.

Settings > Warmbly Cloud lists every active mailbox with a switch for whether it is in the pool. For enrolled mailboxes it shows the cloud's view:

Pause and resume per mailbox from the same row. Once a mailbox is enrolled, its warmup settings belong to Warmbly Cloud; see warmup settings.

Warmup settings

Warmbly Cloud owns an enrolled mailbox's starting volume, daily increase, maximum, reply rate, sending window and sending days. Your instance keeps a copy of them on the mailbox, so the Warmup tab, the API and campaign estimates show what Warmbly Cloud actually runs.

• The first enrollment proposes the settings the mailbox has on your instance. Enrolling it again, or refreshing its credential after a password change, never sends them again, so neither can undo a change made in Warmbly Cloud.
• Changing a setting on the Warmup tab, or through PATCH /emails/:id, sends it to Warmbly Cloud first. You can change the starting volume and other ramp settings while warmup is active without removing or enrolling the mailbox again. It is saved only once Warmbly Cloud has applied it, and the mailbox then shows the values Warmbly Cloud reports. If Warmbly Cloud cannot be reached, nothing changes. If it answers but does not apply a value, the rest of your change is not saved, the error names what was not applied, and the mailbox shows the values Warmbly Cloud reported.
• The copy is refreshed whenever the Cloud mailbox list loads, after every change, and every 15 minutes in the background, so a change made in Warmbly Cloud shows up here within 15 minutes. The Warmup tab shows when it was last refreshed.
• The timezone stays your instance's, because campaigns use it too. It travels with every change, and the background refresh sends it again whenever Warmbly Cloud's differs.
• Warmbly Cloud does not take 0 from an instance for the starting volume, maximum, daily increase or reply rate, so on an enrolled mailbox those fields start at 1. Sending every day is sent as all seven days.
• The content segment, warmup placement, folder and retention on your instance do not apply while Warmbly Cloud warms the mailbox, and the Warmup tab hides them.
• Participation and the shared daily and recipient limits are changed with the mailbox's Warmbly Cloud controls. Starting, pausing and resuming warmup are sent to Warmbly Cloud; to stop warmup, remove the mailbox from Warmbly Cloud.

The background refresh runs in the consumer, so upgrade the backend and consumer together.

Removing one Cloud-managed mailbox, through its Cloud warmup controls or Disconnect mailbox, stops both warmup sending and receiving on Cloud before releasing its link. Cloud keeps the mailbox, sign-in and history; the instance removes its mirror. If the stop fails, removal fails and keeps the link for retry. If releasing the link fails after the stop, warmup remains stopped while you retry. This also applies to existing managed enrollments and older self-hosted clients once Cloud is updated, without disconnecting or re-enrolling other mailboxes. On an older Cloud, removal may only release the mirror; stop participation directly on Cloud until it is updated.

Deleting a mailbox directly on Cloud also removes its instance association. Connecting the same address again creates a different Cloud record; it does not restore the old link. If an existing SMTP/IMAP mailbox is warming on Cloud but missing from its instance's linked list, contact support with the local mailbox ID and connection ID. Do not delete or re-enroll it to repair the association, and do not send passwords or connection tokens. Support can use the verified IDs to restore only the association, preserving the current Cloud mailbox, credentials, history and participation.

When Warmbly Cloud v0.6.62 or later handles the disconnect, disconnecting an entire instance, from the instance or from Settings > Linked instances on Cloud, stops Cloud warmup sending and receiving for every mailbox the connection linked, then releases them. Unstarted sends addressed to those mailboxes, including replies in existing warmup threads, are cancelled, and no new Cloud warmup or diagnostic mail is addressed to them. An enrollment that arrives while the disconnect runs is refused. Cloud-managed and explicitly associated mailboxes stay in the Cloud workspace with their sign-in, credentials, settings and history; restart their warmup there if you want Cloud to keep warming them. SMTP/IMAP mailboxes originally enrolled by sending the instance's credentials still delete their Cloud credential and history on removal. If Cloud cannot stop a mailbox, the disconnect fails, the connection stays in place and the instance retries it. Pausing warmup on Cloud stops both sending and receiving warmup mail there, and Stop all diagnostic participation additionally turns participation off. Sends already accepted by a provider cannot be recalled.

Connections disconnected before that release are covered too. After upgrading, Cloud stops warmup sending and receiving, once, for every mailbox it can tie to a disconnected connection through its Google or Microsoft sign-in or adoption record, unless a live connection holds that mailbox now. The pass repeats for at least the first 30 minutes after the upgrade, so a disconnect an older replica handled during the rollout is covered as well, and keeps retrying any mailbox it could not stop. Once a full pass after that window stops everything it found, it never runs again: restarting warmup on such a mailbox in the Cloud workspace keeps it running. Ramp history and safety holds are kept. Mailboxes with no such record, such as app-password mailboxes associated with an existing Cloud copy, are not stopped by this pass; use Stop & reset on the mailbox in the Cloud workspace.

When the count stays at zero

Warmbly Cloud sends the warmup mail itself, connecting to your mail server's SMTP from its own network rather than from your instance. A server that accepts only your instance's address, an SMTP host that resolves to a private or internal address, or a port your host blocks from outside will refuse it while your own sending keeps working. When that happens the warmup column turns red with a warning icon, and the mailbox's Warmup tab shows the server's own answer (for example a refused connection or a rejected login) until a send goes through again. Fix the SMTP host, port or allowlist on your mail server; nothing needs re-enrolling.

The count can also hold below the target when the pool has fewer partners free for the mailbox today than the ramp asks for, since a mailbox never writes to the same partner twice in a day. The Warmup tab says so with how many partners are available, and the cloud checks again every few hours.

Premium workspaces are always served first. Borrowed partners are limited to mailboxes that have been healthy pool members for at least three days in a workspace in good standing, and only those may write back, so nothing unproven and nothing unsolicited ever reaches a paying mailbox. Every draw favours the inbox that has received the least for what it sent, so a paying mailbox in a thin tier is written to first rather than last. See pools for the full rule.

Your instance shows which tier it is on in two places: the plan badge in the header reads Cloud · Free or Cloud · Premium once the link is live, and Settings > Warmbly Cloud has a Plan section with the allowance and what Premium adds: better deliverability, reputation protection, priority matching and no mailbox cap. Its Premium button opens Warmbly Cloud's billing page, asks whether you want to be billed monthly or yearly, and sends you to checkout for the workspace the instance is linked to; the instance itself bills nothing. On Premium the same section links to that billing page to manage or cancel. The Mailboxes page nudges once, only when every free pool mailbox is in use and the instance has more to warm.

The Warmup plan is the same plan a hosted workspace buys when it only warms and does not send, so it is not tied to self-hosting: a workspace on it can hold mailboxes connected on the cloud, through linked instances, or both, and the workspace's regular hosted plan, if it has one, also counts as Premium, so a workspace on Starter or above needs nothing extra. It is not listed next to Starter, Grow and Business because it is not an alternative to them; the button on your instance and the mailboxes page on the cloud are the ways in. See billing.

Enrolled mailboxes are ordinary members of the hosted pool and are held to the same rules: verification tokens on every warmup message, complaint and bounce tracking with automatic quarantine or blocking when a mailbox starts hurting partners, and spam placement that slows a mailbox down. A mailbox that gets quarantined on the cloud stops being offered to partners and re-enters on the same probation terms as any hosted mailbox.

Your instance holds the mailbox to the cloud's verdict as well, exactly as it would one from its own pool. It reads every enrolled mailbox's standing from the cloud every five minutes, on enrolling, pausing or resuming, and when loading the mailbox list in Settings > Warmbly Cloud. A recognized status from that list refreshes the local observation instead of being replaced by an older cached status. From then on:

The same standing feeds the mailbox's health on the Mailboxes page, the Warmup reputation block in its drawer (marked Warmbly Cloud, with the reason and the end of any hold), a campaign's sending limits, the Advisor and the dashboard's health summary. A change reaches your instance within five minutes and fires the same warmup.health_changed, warmup.quarantined and warmup.blocked webhooks a local transition does.

Cloud standing is observed evidence, not a permanent permission. Healthy, watch and throttled observations have a 15-minute freshness limit. Missing, unrecognized or stale observations stop new control-plane admission with cloud_evidence_unavailable until a recognized cloud observation arrives. This availability hold does not claim the provider blocked the mailbox. Existing enrollments start with unknown freshness after upgrading, then the next successful standing sync establishes it.

An unavailable status holds only two things: campaign sends from the mailbox, and the access tokens your instance draws for a mailbox signed in through Warmbly Cloud. Both wait for a current status. Nothing else reads it as a verdict. The mailbox is not rested, putting it back into campaigns is not refused, its health score is not lowered, and it counts as a warning rather than an error on the Mailboxes page and in the health summary. A rest that is already running stays in place and counts only time with a current status toward its three days. The mailbox drawer shows it as Status unavailable, Settings > Warmbly Cloud as Unavailable, and a campaign's sending plan as Waiting for Warmbly Cloud status. A real quarantine or block, whether the cloud reported it or the local reputation ledger still holds it, applies in full while the status is unavailable.

The Advisor reports an unavailable Cloud status separately from a real pool quarantine or block. A mailbox may still be warming on Cloud while its self-hosted instance lacks a current status. Open Settings > Warmbly Cloud and refresh the mailbox list. If the status remains unavailable, check Cloud connectivity and the consumer's cloud_standing_sync job, and keep the backend and consumer on the same release. Do not disconnect or re-enroll the mailbox to refresh its status. The Warming count indicates warmup is enabled, not that a provider has confirmed a send; the warmup count and send warnings show progress and failures.

An active quarantine or block remains in force even when the cloud cannot be reached. A bounded hold still ends on its own date; an unbounded block needs review. Removing a mailbox from the cloud does not lift an active hold. Restrictive cloud evidence is retained by workspace and address in the local reputation ledger, so leaving or changing pools, reconnecting, or exporting and importing the workspace does not reset it. The cloud link itself is instance-local and does not travel with the archive. Fresh positive observations from a new link do not erase an unexpired restriction from the previous link. Appeals go through the mailbox on Warmbly Cloud, where the verdict was reached.

Local and cloud warmup use the same active-mailbox, participant-role, workspace-standing and health checks. A recipient-only participant cannot originate diagnostic messages. Restricted or suspended workspaces cannot contribute candidates, and paying for Premium does not waive these rules. Spam placement slows participation; it is not by itself a reason to quarantine a mailbox.

These checks apply before new commands are admitted. Updating the control plane cannot revoke a command an older worker has already accepted; cached provider credentials and already-running work keep their existing expiry and execution behavior.

For mailboxes signed in through Warmbly Cloud the enforcement reaches sending too. Every access token the instance draws is checked on the cloud: a mailbox the cloud has blocked, one that is no longer active there, one that was removed from the workspace, or an instance whose link was revoked gets no token, and the instance stops sending and syncing from that mailbox as soon as its cached token expires.

A self-hosted instance's own seed panel holds whatever its administrator added, often nothing. A linked instance can borrow Warmbly Cloud's instead: pick Warmbly Cloud as the panel when you start an inbox placement test, or for a campaign's placement monitor.

The split is the same as for warmup, only narrower:

• Your instance renders and sends every copy. The cloud stores no template and never gets the mailbox's credentials; its seed inboxes receive the rendered copies like any recipient. A campaign step renders for a placeholder contact here, not the campaign's first lead, so no lead's details reach the cloud's seed inboxes unless you pick a contact for the test. Copies go out from your mailbox through your own workers, paced and charged to the mailbox's daily limit exactly like a test on any other panel.
• The cloud only hands out seed addresses and reports where each copy landed. It picks seeds for the test (never one on your sender's domain), your instance tells it the Message-ID of each copy it sent, and the cloud answers with the folder each seed found it in. Seed addresses are shown masked, as on any shared panel.
• Tests use the linked cloud workspace's free tests, the same monthly number a hosted workspace on the same plan gets, and a tracking comparison counts as two. Paying for more in credits is only offered on the hosted product's own panel, so past the free tests a test here waits for the next month. Tests on your instance's own panel and on your own seed inboxes are never counted.
• You can narrow a test to some providers, as on any shared panel; the cloud then picks its seeds from those providers alone.

The panel is offered only while the instance is linked. Without a link a test on it is refused with placement_panel_unavailable.

A root redirect sends visitors to a sending domain on to your website. Served from your own instance, the domain has to reach Warmbly through whatever proxy sits in front of it, which on a server behind Traefik, nginx or a hosting panel means routing each domain by hand. A linked instance can pick Warmbly Cloud under the redirect's Served from instead: Cloud answers for the domain from its own tracking service and issues its certificate, and all you add is DNS.

• Cloud proves the domain on its own terms: it lists its own ownership value for the _warmbly TXT record and its own addresses for the root, and serves nothing until it sees both.
• Only the domain, the website and the www setting go to Cloud. Visitors to the domain reach Cloud, not your server; nothing about your mailboxes, contacts or mail is involved.
• Cloud serves up to 200 redirects for one linked instance.
• Unlinking stops redirects using that connection, not redirects using another workspace's connection or a retained legacy link. Each one says so on your instance and can be moved back to it.

See serve it from Warmbly Cloud for how it looks on the sending domains page.

On your instance, Settings > Warmbly Cloud > Disconnect removes only the selected workspace link's enrollments and lets eligible local warmup take over after confirmed cleanup. Other workspace links and retained legacy links are unaffected. Instance-originated SMTP mailboxes and their credentials are deleted on the cloud. An OAuth mailbox belongs to the cloud workspace: unlinking removes that connection's access, not the workspace's mailbox or provider grant. Unlinking stops its Cloud warmup sending and receiving; its ramp settings and history remain, and you can restart it or delete its stored credentials on Warmbly Cloud. Root redirects using the disconnected link stop at the same time. Removing a legacy instance-wide link remains a separate administrator action. On Warmbly Cloud, Settings > Linked instances lists the connections linked to a workspace and can unlink any of them from the other side.

SMTP enrollment, mailbox removal and instance disconnect first record a durable local intent. While enrollment or removal is pending, the mailbox is not admitted to local warmup. The regular standing sync retries pending work after an outage or restart, using the same mailbox identity rather than creating another. Remote removal must be acknowledged, or confirmed already absent, before local enrollment is dropped. A failed local cleanup stays pending and is retried.

Each mailbox's pending work is retried independently. A failed enrollment or removal does not stop the other mailboxes' retries or Cloud status refreshes. The failed mailbox stays pending and unavailable, and the sync still reports the error. When the address is already connected in the linked Cloud workspace, for example because you used hosted Warmbly before self-hosting, Cloud attaches that copy instead of creating a second one, as long as it is an active SMTP/IMAP mailbox, your server presents exactly the SMTP and IMAP host, port, username and password Cloud holds for it, no active Cloud campaign sends from it and no other server has enrolled it. From then on it is your server's mailbox: its warmup settings follow your server, and removing it from your server removes it from Cloud. Any other existing copy answers pool_link_mailbox_conflict. Contact support with the connection ID and local mailbox IDs to check the association, without sending credentials or deleting or re-enrolling the mailbox. Cloud never attaches an existing mailbox by address alone.

Removal is an explicit opt-out. A late enrollment acknowledgment cannot reverse a pending removal. After removal finishes, a new explicit enrollment can create a fresh intent, but it does not reset reputation holds. Disconnect remains pending until remote revocation and local cleanup succeed, and no new enrollment is accepted during it.

New Gmail/Outlook sign-ins and adoption of an existing cloud mailbox use managed consent protocol 1. Both sides record a stable operation before acting. The instance records the workspace and initiating user, rechecks their current mailbox-management permission, and binds completion to that workspace, user, linked cloud instance, provider and mailbox identity. Organization owners are allowed; another member needs an accepted membership with manage_emails. Restricted or suspended workspaces cannot complete a managed operation.

Consent records survive backend restarts. Replaying a confirmed completion returns its existing mailbox rather than creating another. A lost cloud reply or failed local mirror write can be recovered by the regular standing sync. The original planned local mailbox ID and remote operation ID are reused. Adoption retries likewise reuse their original identity. Completion timestamps prove only that the recorded consent operation completed, not that authentication or inbox placement passed.

A browser sign-in has a ten-minute consent window, and the browser that chose to continue must complete the callback. A repeated callback cannot exchange the same code again. If the provider exchange may have happened but there is no committed mailbox at its planned ID, the result is unknown. Warmbly does not retry the authorization code or report success. Remove the pending connection and start a new explicit sign-in. If the planned mailbox was committed, completion can recover without exchanging again while consent is still valid. Loss of Redis before provider exchange can require opening the consent flow again; durable consent is not a replacement for the provider's short-lived browser/PKCE state.

Opt-out, instance revocation and expiry are restrictive. Pending local removal is recorded before calling the cloud. A remote deletion reserves a tombstone even if a delayed start has not arrived yet. Late callbacks and adoption replays cannot revive that operation. A genuinely new sign-in or enrollment needs a new explicit operation and does not erase reputation holds. A pending initial warmup activation is also durable: completion retries it after a restart, but a confirmed completion replay does not undo an explicit pause.

Current local consent, enrollment, workspace standing and cloud observation freshness are checked before using even a cached brokered token. The cloud rechecks current instance and operation authority before minting another token. Previously issued provider tokens and commands already accepted by an older worker are not retroactively canceled by these checks.

Version compatibility and rollout

The cloud advertises managed_consent_protocol: 1 in its authenticated instance information response. New clients require that capability and use separate correlated endpoints; they do not silently send fields an old cloud could ignore. Correlated browser states also use a different prefix, so an old callback handler cannot exchange them as legacy one-shot operations.

Upgrade and settle all cloud control-plane replicas first, then upgrade linked instances. No new configuration is required. An old cloud cannot provide the stronger managed-sign-in guarantee, and a new client refuses a new managed operation against it. Existing SMTP enrollment and existing mailbox IDs remain valid. Old one-shot endpoints remain available to old clients, with their original weaker recovery behavior. An old browser session whose local authority was never stored durably cannot be reconstructed after upgrading/restarting; start a new explicit sign-in instead. Mixed replicas can reject the new endpoints or browser state, so do not treat a partial rollout as completed recovery.

The additive cloud routes below are beneath /v1/pool-link, use the linked instance's bearer token, and require protocol: 1. These are instance-scoped routes, not organization API-key routes. Existing routes without -correlated remain available.

cloud_link_managed_protocol means the cloud does not advertise the required recovery capability. pool_link_oauth_unknown means no provider-exchange result has been confirmed; it is not permission to resend the code. Existing cloud_link_oauth_session / pool_link_oauth_session errors cover missing, expired, revoked or mismatched consent. Permission or persistence failures do not report a successful connection.

Data, secrets and moving a workspace

PostgreSQL retains managed consent history and revocation tombstones until the owning organization is deleted. There is no automatic history purge or configurable retention duration in this release. Records contain organization/user references, instance/operation/account IDs, provider, operation kind, state and timestamps; local records retain a SHA-256 session hash, not the raw browser handle. These durable operation tables contain no email bodies, authorization codes, PKCE verifiers, access tokens or refresh tokens.

The schema downgrade refuses to discard any managed consent history, including completed, expired, imported and revoked records. An older release cannot represent these restrictions. Ordinary disconnect deliberately does not erase them, so it does not make such a downgrade safe.

Redis still holds the short-lived browser session, PKCE verifier, browser binding and consent result, with a ten-minute TTL. The cloud's ordinary encrypted mailbox credential store holds provider credentials under its existing retention rules. The instance only caches brokered access tokens in memory for at most ten minutes; an already-issued worker token can remain valid until its provider expiry.

Consent restrictions/history travel in a workspace export. Import resets source instance IDs, remote IDs, session hashes, planned account handles and queued activation handles; live cloud account references on the local consent record are reset too. This prevents an imported pending operation from resuming against the source instance, while retaining its restrictive state. Workspace links and legacy instance-wide links do not travel: reconnect and explicitly authorize any new managed operation after moving. Imported history is not a fresh consent or a positive provider verdict.

• Traffic is outbound only: the instance calls WARMBLY_CLOUD_URL (default https://api.warmbly.com) over HTTPS, on port 443 or 8443, and only to a public address. Plain HTTP to localhost is accepted only when APP_ENV is dev. Nothing needs to reach the instance from the internet
• The instance token is stored sealed with CREDENTIALS_ENCRYPTION_KEY. Rotating that key invalidates the stored token; reconnect afterwards
• Brokered access tokens reach the worker through the backend's internal API (/api/v1/internal/cloud-link/token/:id), so workers keep needing only ENCRYPTED_KEYS_BACKEND_URL and ENCRYPTED_KEYS_WORKER_TOKEN. A worker that cannot reach the backend keeps sending from such mailboxes until its cached token expires, about an hour
• Connections and enrollments are bound to this installation's encryption key, even when workspace-scoped, so they are not part of a workspace export. Reconnect after moving a workspace to a new instance
• INSTANCE_NAME sets the name shown on the approval page; the hostname is used when unset. The name follows the workspace naming rules, so one that reads as a web address (a hostname, for example) shows as "Self-hosted instance"