DEV Community: Stefan Sabolowitsch

inbuxa: a Stalwart fork where every "enterprise" feature is in the free install

Stefan Sabolowitsch — Sat, 14 Nov 2026 09:28:13 +0000

If you self-host mail for more than yourself, you know the moment: the server is great, then you need multi-tenancy, SCIM provisioning from Entra ID, or undelete for the colleague who emptied the wrong folder. And that's where the license key starts.

inbuxa takes a different route. It's a fork of the Stalwart mail server, and every one of those features ships in the one AGPL-3.0 edition. There's no license key, no per-seat fee, no paid tier, and nothing phones home.

Disclosure: I'm not part of Coffey Labs, but I've contributed several pull requests to inbuxa and to the Bulwark webmail client. I run Windows and Linux infrastructure for a living, and this is the mail server I wish I'd had years ago.

TL;DR

One Rust binary for JMAP, IMAP, POP3, SMTP, CalDAV, CardDAV, WebDAV, Sieve/ManageSieve
Admin console and webmail are separate programs that sign in with OAuth over JMAP. The mail host serves no web UI at all.
Included: multi-tenancy, masked addresses, undelete, SCIM 2.0, per-domain directories (LDAP/SQL/OIDC), branding, monitoring with live tracing, scale-out storage
Also included, beyond Stalwart's public feature list: DLP, journaling, legal holds, a tamper-evident audit log, locked accounts, shared mailboxes
License: AGPL-3.0, one edition
Try it: demo.inbuxa.org · Docs: docs.inbuxa.org

Why fork a good mail server?

Stalwart is excellent software, and inbuxa's author, John Coffey, says so openly: he ran it in production. In his launch post he gives three reasons for forking anyway:

Security. No web interface on the mail host. /admin and /account return 404, and even the first boot runs entirely over JMAP.
Topology. Server, console and webmail really are separate, so each can sit on a different machine or network. You can't get that by patching a monolith.
Feature gating. The features you need to host mail for other people (multi-tenancy, directory integration, provisioning, audit, monitoring, scale-out storage) shouldn't sit behind a paywall.

The fork went public on 20 September 2026. inbuxa's own mail moved over in a 78-second cutover window with no rollback.

The suite

Component	What it does
inbuxa Server	JMAP, IMAP, SMTP, POP3 and DAV, plus storage, delivery, spam filtering and the admin API, in one Rust binary or container image
inbuxa Admin	Tenants, domains, accounts, queue, certificates, metrics, live delivery tracing, guided jobs such as DNS publishing. Its screens are generated from the server's own description of its settings.
inbuxa Webmail	Mail, calendar, contacts and files on desktop and mobile, with helpdesk account management. Built on ihasmail.
inbuxa installer	Sets up all three, completes first boot and writes your DNS records
inbuxa-migrate	Moves accounts from IMAP, JMAP, DAV, Maildir, Google Takeout, Exchange or Stalwart

The deployment model deserves a closer look. Only port 25 has to be reachable from everywhere. The console and webmail can sit behind an allowlist or on a private network, from one box up to a three-way split for multi-tenant setups. If your admin UI has ever shown up in a Shodan search, you'll see why that matters.

What's in the box

All of this works in a standard install, with no license check:

Multi-tenancy: per-tenant domains, accounts, admins and resource limits, with tenants isolated from each other
Masked addresses you can cut off one by one
Undelete for mail, files, events, contacts and filters, with a configurable retention period
SCIM 2.0 provisioning from Entra ID, Okta, Keycloak and others
Per-domain sign-in: each domain can have its own LDAP, SQL or OpenID Connect directory
Branding: logos and email templates at server, tenant or domain level
Observability: traced and retained deliveries, searchable metrics history, alerts
Email authentication: per-domain DKIM, SPF/DKIM/DMARC checks, automatic Let's Encrypt certificates, generated DNS records
Scaling: read replicas and distributed message storage

Compliance features you won't find on Stalwart's feature list

This is where inbuxa goes past being "Stalwart Enterprise for free." It adds features that schools, SMBs and regulated organizations ask for:

Data loss prevention with 49 identifier detectors (card numbers, ID numbers, keys, custom terms), which can warn, hold for review or block
Journaling, with optional archiving to an outside system
Legal holds, exportable as a verifiable ZIP
Audit log of admin changes, checked for tampering
Locked accounts that keep receiving mail while a colleague takes over
Legacy protocols you can switch off per tenant or server-wide, plus a security to-do list in the console
A GDPR-oriented data inventory in the docs

More than a rebranded fork

Forking takes an afternoon. A fork that strangers can install, trust with their mail and still upgrade a year later takes a lot more. Coffey Labs published the numbers as of 26 October 2026:

77 fixes to inherited code (PKCE handling, DNSSEC/TLSA rechecks, audit logging for cross-account access, cluster role changes without restarts, better search on PostgreSQL and MySQL, and more)
128 reworked inherited features, five of them performance improvements
5,329 tests: 3,449 new, 1,880 inherited, 1,725 of which run unchanged
433 documentation pages, covering install, operations and migration
About 123k lines of new server code, 81k in the console, 108k in the webmail
43 server releases so far

Coffey Labs runs its own mail on a three-node inbuxa cluster and deploys every release there first.

Clean-room, and documented

This is the part I trust most. The nine features that only exist in Stalwart's separately licensed edition were rebuilt clean-room from written specs that were committed before the implementation started. You can read them in the repo under docs/spec/features/, alongside strip reports in docs/fork/strip-reports/. Upstream copyright notices are kept, and changed files say so in their headers.

The server and console are AGPL-3.0-only, the same as upstream. The webmail is AGPL-3.0-or-later. inbuxa is not affiliated with or endorsed by Stalwart Labs LLC, which owns the Stalwart trademark.

AI: one feature, off by default

You won't find an AI buzzword on every screen. There's one AI feature: the spam filter can use a language model as one signal, and a Sieve function can query a model. It's off by default and designed for a local, auditable model. It only sees the subject and text, doesn't log that content, and skips models that are slow or failing. If you point it at a remote endpoint, mail content leaves your network, and the docs say so plainly.

Bring your own webmail: Bulwark

Prefer Bulwark, the popular JMAP webmail built for Stalwart? It works with inbuxa too, and as of early November it supports inbuxa's extensions natively. I wrote two pull requests for it, and both were merged into main on 7 November 2026:

#1522: account security management. inbuxa advertises its account security controls under its own JMAP capability, urn:inbuxa:jmap:registry, while Stalwart uses urn:stalwart:jmap. Bulwark used to know only the Stalwart one. Now it picks the namespace from the capabilities the account advertises, never from the server's name or branding. So the Security settings, including API keys and mobile QR pairing, now work against inbuxa.
#1534: masked addresses. This adds a new section under Settings → Security where you can list, create, describe, enable, disable and delete masked addresses. Deleting one requires an address-specific confirmation. The same UI works on both servers.

That second one shows the whole point of inbuxa nicely. On Stalwart, masked addresses are an Enterprise feature, so Bulwark hides the section on Community-edition servers, which is what most Stalwart installs run. On inbuxa the same feature is just there.

Because everything goes over JMAP and OAuth, there's nothing to configure: no separate credentials and no extra backend.

Try it

Local trial (the whole suite on one machine, on loopback):

inbuxa survey                     # check the host first
inbuxa install --local --domain example.test --install-deps --yes

Container image:

docker pull registry.coffeylabs.org/inbuxa/inbuxa-server:2026.11.11

From source:

cargo build --release -p inbuxa

A server with no configuration starts in bootstrap mode. The setup wizard in inbuxa Admin then takes care of the admin account, first domain, DKIM keys, ACME certificates and first mailbox, all over JMAP. The quick start puts a single-machine install for a household or small office at about half an hour.

If you'd rather look around first, the demo has 16 domains and 241 accounts with made-up traffic.

Coming from Stalwart?

inbuxa inherits Stalwart's data format, so moving a Stalwart 0.16 server is an export and import, not a conversion. Accounts, passwords, sessions, certificates, tenants and mail all come across. The migration guide lists which install steps you can skip, which is most of them. Keep the old install around for rollback, because mail store upgrades are one-way.

There are also guides for Postfix + Dovecot, iRedMail, Zimbra, Exchange Server and Open-Xchange.

The honest part

It's young. The fork is two months old, and Coffey Labs describes adoption as "a handful of adopters." Test it before you put it in production, as you would any mail server.
It's a small company. Coffey Labs LLC builds it. There's no foundation and no formal governance model yet. The author has publicly committed to not abandoning the project.
AI-assisted development. The project says openly that parts of the code and site were written with AI help, and that a person reviews every contribution.
It's not for everyone. The inbuxa site itself recommends Mailcow, Mailu, Mail-in-a-Box or mox if you only host mail for yourself or a few domains. If your organization depends on Office co-editing or Exchange-only features, a hosted suite may still suit you better.

But if you host mail for a school, a company, a club or several tenants, and you're tired of hitting license walls, inbuxa is worth an afternoon.

Stop testing your flow collector with random NetFlow tuples

Stefan Sabolowitsch — Fri, 10 Jul 2026 10:31:11 +0000

If you have ever built or operated a flow collector, you know the problem: the
usual test generators emit random tuples. Random source IP, random destination,
random ports, random counters. That is fine for a parser smoke test — and
useless for everything after the parser. Dashboards look like noise, enrichment
has nothing meaningful to enrich, and "does my Top-Talkers panel actually make
sense?" is a question random data cannot answer.

I ran into this while building my own collector stack (flow collector →
VictoriaLogs → Grafana) and converting ElastiFlow dashboards to LogsQL. I
needed traffic that behaves like an enterprise network — repeatably, at a
controlled rate, without pointing test tooling at production. So I built one.

flowsimulator-go
is an open-source enterprise flow simulation platform written in Go. MIT
licensed, single static binary, one dependency.

The core idea: simulate sessions, not tuples

Instead of rolling dice per record, flowsimulator-go models an enterprise
network in YAML — sites, VLANs, address pools, endpoint personas
(windows_client, domain_controller, firewall, …), applications, and
services — and then plays ordered session chains on top of it.

The built-in windows-login template is a good example. One session produces
six flow records, in order:

DNS before Kerberos, Kerberos before LDAP, LDAP before SMB — the way a real
Windows logon looks on the wire. Web browsing resolves DNS before opening TLS.
Backups authenticate before they transfer. A behaviour profile
(interactive-tcp, bulk-transfer, asymmetric-download, …) shapes bytes,
packets, duration, and TCP flags per event.

There are ~30 built-in templates, including security patterns: port scans,
SSH/RDP brute force, SMB enumeration, beaconing, DNS tunneling, exfiltration,
and lateral movement. Crucially, these run as low-weight scenarios blended
into dominant normal traffic — because a detection dashboard tested against
100% attack traffic tells you nothing.

One neutral core, four wire protocols

Architecturally, everything funnels through a protocol-neutral FlowRecord:

The scenario engine knows nothing about wire formats; the encoders (NetFlow v5,
NetFlow v9, IPFIX, sFlow v5) know nothing about scenarios. Each exporter keeps
its own encoder state — sequence numbers, NetFlow v9/IPFIX template
refresh/cache, sFlow sample pools — so a mixed-protocol simulation behaves like
a fleet of independent devices. Templates are derived from a central,
source-backed IANA/IPFIX information element registry; custom enterprise IEs
can be added via registry files.

Runs are deterministic: same seed + same config = same dataset. That makes
regression testing across collector versions actually meaningful.

Quickstart

git clone https://forgejo.sabolowitsch.org/StefanSA/flowsimulator-go.git
cd flowsimulator-go
go run ./cmd/flowsimulator-go run -c configs/examples/minimal-netflow5.yaml --duration 5s

That sends five seconds of NetFlow v5 to 127.0.0.1:2055. Minimal configs
exist for all four protocols, enterprise examples model HQ/campus/datacenter/
hybrid-cloud topologies, and a continuous lab config runs all four protocols
until SIGTERM — useful as a permanent telemetry source for an observability
lab or collector burn-in. A JSON status endpoint reports records, packets,
bytes, per-protocol counters, and current rate while it runs.

What it deliberately does NOT do

A few honest boundaries, because I think tooling should state them up front:

No invented vendor fields. Cisco/Palo Alto/Fortinet enterprise IEs only enter the registry with a documented source. No made-up field numbers.
No payloads, no PCAP replay, no fuzzing. It serializes flow records, nothing else. The security scenarios are synthetic flow patterns for testing detection pipelines — they do not perform attacks.
IPv4 only for now. IPv6, IPFIX Options Templates, and richer NAT/MPLS/VXLAN/SD-WAN records are on the roadmap.

Try it

Repo: https://forgejo.sabolowitsch.org/StefanSA/flowsimulator-go
Docs: session template library, scenario model, protocol coverage plan, and integration test strategy are all in docs/
License: MIT

If you build or operate flow collectors — or you just want realistic NetFlow/
IPFIX/sFlow data for a Grafana lab — I would genuinely like to hear what breaks
and what is missing. Issues and feedback welcome.

Vaultwarden-Plus v1.36.3: Organization Account Recovery — without breaking zero-knowledge

Stefan Sabolowitsch — Fri, 03 Jul 2026 09:17:16 +0000

Every operator who runs Vaultwarden for a team eventually hits the same wall: a member forgets their master password. In a zero-knowledge system that's supposed to be a dead end by design — the server can't just "reset" what it never had access to.

Bitwarden solves this upstream with Organization Account Recovery: enrolled members hand the org an encrypted recovery blob, and an admin can trigger a recovery that forces a password reset — all without the server ever seeing a plaintext password or vault key. That capability has been on the operator wishlist for Vaultwarden for a long time.

As of v1.36.3, it's integrated into Vaultwarden-Plus.

What actually shipped

Admin-triggered recovery for enrolled organization members, driven through the official Web Vault Admin Console.
Forced password-reset flow for the affected member on next login (update-temp-password).
Support for both legacy and V2 password payloads, plus 2FA-only recovery requests.
A Web Vault adapter that handles the older /reset-password path and the current /recover-account calls, so official-client compatibility stays intact.

The part I care about most: the security model didn't move

Account recovery is exactly the kind of feature that's easy to ship badly — by quietly weakening the threat model. So the hard constraint was: zero-knowledge stays zero-knowledge.

The server still never stores plaintext master passwords, plaintext vault keys, plaintext org private keys, passkey PRF secrets, trusted-device material, or decrypted vault contents. Recovery only works when org policy, enrollment, authorization, and a valid recovery payload all line up — and credential mutation stays fail-closed if a request is malformed or incomplete. Recovery material, tokens and mail links are never logged.

In other words: an admin can get a locked-out colleague back into their vault, but "admin" never becomes "can read everyone's passwords."

Operator notes

No database or config migration required — drop-in for existing deployments.
You'll need SMTP / sendmail / SES configured for recovery notification mail.
The bundled Web Vault is intentionally pinned to 2026.4.1 (validated against this recovery flow); upgrades beyond it wait until an upstream artifact is available and separately validated.
Validated end-to-end on an isolated stack (SQLite + Maildev): policy → enrollment → admin recovery → forced reset → completion.

Try it

services:
  vaultwarden:
    image: forgejo.sabolowitsch.org/stefansa/vaultwarden-plus:1.36.3
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vw.domain.tld"
    volumes:
      - ./vw-data/:/data/
    ports:
      - 127.0.0.1:8000:80   # TLS terminates at your reverse proxy

Release & full notes: https://forgejo.sabolowitsch.org/StefanSA/vaultwarden-plus/releases/tag/v1.36.3

If you run Vaultwarden for an organization, I'd love to hear how you currently handle lost-master-password situations — and whether this matches what you'd need. 🔐

Vaultwarden-Plus: A Password Manager Built for Operators

Stefan Sabolowitsch — Wed, 24 Jun 2026 11:29:39 +0000

If you search dev.to for Vaultwarden, you'll find dozens of excellent guides: how to deploy it with Docker, how to put it behind a reverse proxy, how to back it up, how to do it for $3 a month. They all answer the same question — how do I stand this up?

This article answers a different one: what happens after it's running, for years, for other people?

That's the question behind Vaultwarden-Plus.

First, the obvious disclaimer

Vaultwarden has been my password manager of choice for years. It's lightweight, fast, reliable, and one of the best examples of what a community-driven open source project can achieve. Thousands of people use it every day to self-host their passwords while staying fully compatible with the official Bitwarden clients.

So why a fork?

The honest answer surprised even me: I wasn't looking for more features. I was looking for a project that prioritizes long-term operation.

Vaultwarden-Plus is not a replacement for upstream, and it's not an attempt to compete. Upstream is excellent and keeps moving the whole ecosystem forward. Plus just asks a narrower question:

What would a Vaultwarden distribution look like if every single decision were made from the perspective of the person who has to operate it?

From self-hosting to operating

Running a password manager for yourself is one thing. Running it for your family, your friends, or an organization changes the perspective completely.

Every update matters. Every config change matters. Every security improvement matters. And — most underrated of all — every unexpected behavior matters, because you're the one who gets the message at 23:00 that "the login is weird."

Over time I'd accumulated a growing pile of local patches: security hardening, CI changes, operational notes. Eventually it stopped being a personal patch set and started being a project. Vaultwarden-Plus is that project, made public.

The rules I actually maintain it by

1. The official client comes first

One rule is close to absolute:

If the official Bitwarden clients don't work, the feature is probably wrong.

Compatibility beats experimental functionality every time. You keep using the apps you already trust — browser extension, desktop, mobile, CLI — with no modified clients and no special workflows. A "cool feature" that only works in a patched client isn't a feature for an operator; it's a future support ticket.

2. Validation before implementation

Implementing everything is easy. Maintaining everything is not. So every proposed change runs the same gauntlet before a single line is written:

Is there a real operational problem behind it?
Does an upstream solution already exist?
Does it improve security?
How much maintenance cost does it add?
Can it be reviewed independently?
Can it be removed later without breaking unrelated things?

Sometimes the answer is a new feature. Sometimes the best engineering decision is to do nothing — and write down why.

3. Small changes scale better

Big rewrites look impressive in a changelog and are miserable to review and maintain three years later. Plus deliberately prefers focused, well-scoped additions. The features that exist today exist because an operator hit a real wall:

Mail dispatch hardening — non-critical account notifications are dispatched outside latency-sensitive request paths, while critical OTP and security mails stay fail-closed. A slow SMTP server should never block a login; a security mail should never silently get dropped.
DKIM signing for outgoing notification mail — because "your users' password-reset mail lands in spam" is an operational problem, not a UI one.
AWS SES mail transport — SES as a first-class alternative to plain SMTP for people who already run their mail through it.
Send email verification — require recipients to verify their address before they can open a Send.
OpenDAL / S3 enhancements — better S3-compatible object storage for attachments and data.
Passkey login (experimental) — passwordless sign-in via passkeys.
2026.5 client-compatibility updates — keeping pace with recent official Bitwarden client releases, so the "official client first" rule stays true in practice.

None of these turn the UI upside down. All of them make the service a little more predictable in production — which is exactly the property you care about when other people's passwords live on your box.

4. Documentation is part of the product

One lesson from years of running infrastructure: undocumented decisions eventually become forgotten decisions. Plus keeps a small set of canonical documents that evolve with the code — current project state, implemented functionality, upstream assessments, product goals, maintenance strategy. The docs are treated as part of the software, not an afterthought.

5. Upstream is a partner, not a competitor

The biggest risk for any long-lived fork is pointless divergence. So every upstream proposal gets continuously categorized into one of four buckets:

Implement · Watch · Defer · Reject

The goal is not to collect the most custom features. It's to stay small, understandable, and maintainable while adopting the improvements that give operators clear value.

What this means for you

Vaultwarden-Plus will probably never have the longest feature list. That's intentional. The focus stays on security, operational reliability, maintainability, reproducible releases, and compatibility with the official clients.

If you already run Vaultwarden, the switch is meant to be undramatic: same clients, same data model, same mental model — just decisions tuned for the person holding the pager. One small but telling example of that mindset: Plus does not recommend Rocket's built-in TLS for production. It expects TLS termination at an external reverse proxy (Traefik, Nginx, HAProxy, …) and the container to speak plain HTTP behind it — fewer moving parts in the crypto path, fewer surprises during an upgrade.

Try it

Stable container images are published to the project's own registry, so a Compose file is all you need:

services:
  vaultwarden:
    image: forgejo.sabolowitsch.org/stefansa/vaultwarden-plus:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vw.domain.tld"
    volumes:
      - ./vw-data/:/data/
    ports:
      - 127.0.0.1:8000:80   # TLS terminates at your reverse proxy

The project lives here:

👉 Source, releases, issues & container registry: forgejo.sabolowitsch.org/StefanSA/vaultwarden-plus

One ground rule: report Plus-specific behaviour to the Plus tracker, not to upstream. If a bug reproduces on a stock Vaultwarden install, it belongs upstream. Keeping that boundary clean is part of being a good downstream citizen.

If you maintain self-hosted services or open source projects of your own, I'd genuinely like to hear how you approach long-term maintenance — the patches that never made it upstream, the "we decided to do nothing" calls, the docs you wish you'd written sooner. That's the conversation I'm hoping this starts.

Technical deep-dives on the individual hardening changes will follow. If that philosophy resonates, follow along. 🔐

DEV Community: Stefan Sabolowitsch

inbuxa: a Stalwart fork where every "enterprise" feature is in the free install

TL;DR

Why fork a good mail server?

The suite

What's in the box

Compliance features you won't find on Stalwart's feature list

More than a rebranded fork

Clean-room, and documented

AI: one feature, off by default

Bring your own webmail: Bulwark

Try it

Coming from Stalwart?

The honest part

Links

Stop testing your flow collector with random NetFlow tuples

The core idea: simulate sessions, not tuples

One neutral core, four wire protocols

Quickstart

What it deliberately does NOT do

Try it

Vaultwarden-Plus v1.36.3: Organization Account Recovery — without breaking zero-knowledge

What actually shipped

The part I care about most: the security model didn't move

Operator notes

Try it

Vaultwarden-Plus: A Password Manager Built for Operators

First, the obvious disclaimer

From self-hosting to operating

The rules I actually maintain it by

1. The official client comes first

2. Validation before implementation

3. Small changes scale better

4. Documentation is part of the product

5. Upstream is a partner, not a competitor

What this means for you

Try it