I have two questions that I’ve been unable to answer by reading docs and other resources:
Which capabilities require an Enterprise license at runtime? The comparison page shows Web admin included in both editions, and message delivery history, dashboard, metric alerts and multi-tenancy with per-tenant quotas and isolation as Enterprise-only. We want to confirm how that is enforced in 0.16.x: does an unlicensed Community instance expose the admin UI with those panels absent, and is there any degradation to quarantine review and release (which we read as Community-included via “spam filtering rules”)? Our operator requirements are locating a message, explaining its accepted/rejected/quarantined state, inspecting the source, and releasing or retrying — we need to know which of those work without a license.
Pre-1.0 schema stability. The roadmap describes finalizing the database schema before 1.0. What are the schema-stability and upgrade guarantees for 0.16.x today? Is there a supported migration path to 1.0, and is durability of already-accepted mail guaranteed across it? We would be using Stalwart as a system of record for accepted messages until they are imported into our application.
Thanks in advance,
Tony
I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.
I have enough information now to answer confidently on both fronts.
Good, confirmed history/dashboard is Enterprise-only. Now let me check whether QueuedMessage inspection (queue management) and spam filter itself are gated by Enterprise, and check the WebUI admin panel exposure when unlicensed.
Good, I now have enough grounded material to answer both questions confidently.
Have enough. Let me compose the answer now.
Enterprise vs Community licensing
Enterprise gating in the current docs is applied per-feature, not to the whole WebUI. The parts you asked about:
WebAdmin itself is available in both editions; it does not disappear or get crippled without a license.
Message delivery history / Dashboard / History views: these are explicitly documented as Enterprise-only (“This feature is available exclusively in the Enterprise Edition of Stalwart and is not included in the Community Edition”) — Telemetry History.
Metric Alerts: also Enterprise-only, same wording, gated on the Alert and MetricsStore objects — Alerts.
Multi-tenancy (tenants, quotas, isolation): Enterprise-only, gated on the Tenant object — Tenants.
Outbound queue inspection (list/inspect/requeue/cancel queued messages) is documented as a general runtime management capability via the QueuedMessage object, with no Enterprise note attached — Queue Management.
Spam filtering (the Sieve-based filter that produces the accept/quarantine/reject/discard disposition) is part of the core mail transport filtering and is not flagged as Enterprise — Spam Filter.
I did not find a dedicated “quarantine mailbox” object distinct from the queue/spam-disposition mechanisms above; quarantine in the current docs is a disposition applied by the spam filter or an MTA hook (message gets tagged/routed, e.g. to a Sieve-defined location), not a separate licensed review UI. Based on what’s documented, your four operator actions map like this without a license:
Locating a message and inspecting its queue state: supported (QueuedMessage object).
Seeing why it was accepted/rejected/quarantined: supported via spam filter tags/headers and event logs, though the persisted history/dashboard view of past decisions is Enterprise-only; live inspection and event logs are not.
Inspecting source: supported (message content is referenced from the queue/mailbox object).
Releasing or retrying: requeue/cancel of queued messages is supported; if “quarantine” in your workflow means a message already delivered into a mailbox folder via a Sieve rule, ordinary IMAP/JMAP mailbox operations (not Enterprise-gated) would move it, since quarantine here is not a licensed feature by itself.
If your workflow depends specifically on the persisted “delivery history” browsing UI to explain past dispositions after the fact, that piece does require Enterprise.
Schema stability toward 1.0
Stalwart has not yet finalized its database schema. The upgrade docs state plainly that “Stalwart does not yet include an automated upgrade tool” and upgrades before 1.0 are performed manually because “newer versions introduce data migrations that can modify or restructure existing data.” The 1.0.0 release “will introduce a stable, finalized database schema and configuration system,” at which point automated upgrades become available. There is currently no dedicated guaranteed migration tool from a 0.16.x install straight to 1.0.0 beyond following the standard manual-upgrade practice (read release notes, back up, test in a throwaway instance first) — see Upgrading. Given this, if Stalwart is going to be your system of record for accepted mail pre-1.0, plan for manual, tested upgrades with backups at each minor version, since no formal durability guarantee across the 1.0 transition is documented beyond the general practice of testing upgrades before applying them to production.
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.