Making a fork a product: the work behind inbuxa

In short

Forking a project takes about a second: you press a button. Turning the fork into something a stranger can install, trust with their mail, and still upgrade a year from now takes longer, and most of that work never shows. This is an account of it: what we fixed, what we rebuilt, what we added, what we tested and what we wrote down.

We released inbuxa's initial fork, of an AGPL-3.0 mail server, in September 2026. The base it grew from is good. If it weren't, we wouldn't have started there. But a good base and a supportable product are different things, and the distance between them is made of a lot of small, unglamorous decisions.

Fixing what we found

Running a mail server in production shows you things a test bench doesn't. Since the fork we've merged 77 fixes to code we inherited. In 61 of them we had to change the original lines, not just add new code beside them. Some examples:

• Sign-in accepts only S256 PKCE challenges, and a masked "****" placeholder can never be saved over a real secret.
• Webhooks stopped sending every event, including message content, to every endpoint.
• DNSSEC answers wrongly judged bogus are rechecked, and TLSA lookups are checked for the same false verdict.
• A group's members can no longer re-share the group's mailboxes, calendars, address books or files.
• Mail sent from an address that isn't the sender's own is audited, and so is an administrator's access to someone else's account.
• Cluster role changes apply without a restart. Task locks became renewed leases. SQL queries and pools got timeouts, and readiness now follows the data store.
• DMARC reports send "none" rather than "pass" as the disposition, so a large receiver stops rejecting them.
• Searches on PostgreSQL and MySQL find addresses by local part, domain or name, and find words inside links and file names.

None of these would make a headline. Every one of them would have been a support ticket.

Another 128 changes extend or rework features we inherited. Five were plain performance work: batched archive reads, a per-node blob cache, pipelined PostgreSQL writes, received-date sorting on the message cache, and DNS blocklist lookups made in parallel.

Built from a blank page

Some capabilities didn't come with the open-source base at all. They exist only in a separately licensed edition. So we wrote a specification for each one from public sources, dated it, and built it from nothing, without reference to that edition's code. Nine features came about this way:

• Multi-tenancy, with tenant quotas and limits on how far sharing reaches.
• Masked email, compatible with the API that clients already speak.
• Undelete for mail, files, events, contacts, Sieve scripts and whole accounts.
• Branding and templates per domain, per tenant and for the whole server.
• AI spam classification with a local model, bounded so that it can never overrule the rules on its own.
• Monitoring: metric and trace history, live tracing, and alerts.
• SCIM 2.0 provisioning.
• Scale-out storage: sharded blob, in-memory and lookup stores, plus PostgreSQL and MySQL read replicas.
• Per-domain directories, so each domain signs in against its own directory.

Together they took 81 commits and about 31,700 lines, each with its own acceptance suite tied to the requirement IDs in its spec.

Things that never existed

Then there's the work with no original at all. The server has seventeen features that appear nowhere on the base project's published feature list, in any edition:

• Data loss prevention with 49 identifier detectors, enforced over SMTP and in the webmail composer.
• Mail flow rules without Sieve: disclaimers, subject prefixes, copies and redirects.
• Journaling, on the same rules engine.
• Legal holds, and a background export of everything a hold keeps.
• An audit log that can't be quietly edited, which also records sending as someone else.
• Locked accounts, and shared mailboxes you can send as from any mail app.
• A sharing policy, so the server and each tenant decide who may share and with whom.
• A personal-data catalog, worked out from the server's own settings.
• A switch for each legacy protocol, server-wide or per organization.
• Explain: a local model reads a failed delivery, a spam verdict or a log line back to you in plain words.
• Scheduled reports and a weekly digest, a deliverability check, a directory test, private top-level domains, and a download of the exact running source in every interface.

The console adds 43 features of its own on top of that: guided setup for sending, certificates and directories, limits written as sentences, a security to-do list, undo instead of "Are you sure?", and a Sieve playground that runs the server's own interpreter. Every one of these ships under the same AGPL-3.0 license as the rest of the server. Nothing is held back for a paid tier.

Tests

A fork you can't test is a fork you can't change. When we started, the suite we inherited was our safety net, and it still is: 1,725 of its tests run unchanged, 107 more differ only by a rename, and 48 were updated because the behavior they checked was changed on purpose. Everything else, 3,449 tests, is ours.

On the server, 274 of the 438 new tests cover the rebuilt features and the new ones that followed them. Each suite is tied to the requirement IDs in the written spec it was built from. The suites are public, like the code.

Tools nobody asks for

Some of the most important work in a fork is tooling no user will ever see:

• An import pipeline that brings in a new base release as a clean, reviewed snapshot, with a written report of everything it changed.
• Notice, name and privacy checks in CI. Every modified file carries its license notice, no stray product names reach user-visible strings, and every new data object is listed in the privacy catalog.
• A cutover rehearsal and compatibility harness that runs the server against a copy of real data before anything goes live.
• An installer that sets up a single host or a cluster, joins nodes, issues certificates, and handles upgrades and uninstalls.
• A migration tool for moving accounts in and out, and a CLI that manages the server from a plan file.

The parts you can see

A mail server needs a face. inbuxa has two, both hosted apart from the mail host. The admin console started from the base project's web interface and has been rewritten phase by phase; it's now about 89% our own code, and the rest is on a written plan. The webmail is entirely ours: about 108,000 lines with 1,843 tests. Both offer a download of their exact running source, one click from the sign-in page.

In raw volume, the server carries about 123,000 lines of our own (not counting vendored libraries) across 427 commits. The console has 81,000, the webmail 108,000, the installer 17,000 and the CLI 4,000. Across the suite we've cut 43 server releases, 25 console releases and 32 webmail releases.

Writing it down

Software nobody can operate isn't a product. The documentation has 433 pages: 384 of reference, plus guides for installing, running and migrating. Behind them are twelve feature specifications, each written and dated before the code it describes. That's how a clean-room rebuild can be shown to be one.

Running it ourselves

We run inbuxa for our own mail on a three-node cluster, deploy every release to it, and fix what breaks. That's where most of the 77 fixes came from. It's a small installation, with a handful of adopters counting our own, and we're honest about that. But every number on this page came from carrying real mail.

A fork is a starting point, not an accomplishment. The accomplishment is everything that happens after.

None of this takes anything away from the project we started from. It gave us a good base, under a license that lets anyone build on it, and we've tried to treat that well. All of our work is public under the same license, and anyone who finds a fix useful is welcome to it.

How we counted

Figures were taken on October 26, 2026 from each repository's main branch. "Tests" means individual test functions and cases. "Fixes" and "changes" are merged pull requests and early commits that touched inherited code, not counting base-release imports, rebranding, documentation, CI or dependency updates. Commits that built the nine rebuilt features are counted under those features, not as changes. "Features with no original" were checked against the base project's public feature comparison as of this writing.