The server now applies a registry write to the running settings itself and
says how it went in the set response: a top-level "x:settingsReload" of
{"applied": true} or {"applied": false, "description": "Saved, but the
running settings were not reloaded. <object>: <error>"}, absent when the
write needs no reload. Sending ReloadSettings after it is a second reload
per burst of saves, and a refused one only repeats what the server said.
The JMAP client now hands the listener each written type with the server's
report, when there is one. A write that carries it queues nothing: applied
removes that reload from what's pending (the server's reload came after
every earlier write of that kind), and a refusal queues it as known
unapplied, as a failed reload from the admin would, without sending it.
A write without the report is an older server's, and queues the admin's
reload as before. When the burst settles there is still one result: the
admin's reload decides it when it had to send one; otherwise a "Saved and
applied" toast, or the banner with the server's reason and the object it
named, and "Apply now" sending ReloadSettings. A later write the server
applies clears an earlier refusal.
"Saved and applied" stays for settings objects; a directory or the default
authentication, which the server also reloads, keeps its form's own toast.
The type table follows the server's list of what each write needs. Alert,
DnsServer, Enterprise and SpamLlm are read when used, and MetricsStore and
TracingStore are stores, so they need no reload; the admin sent one for
each. Allowed IPs are part of the full settings, but the server answers an
AllowedIp write with the blocked-IP reload, which doesn't rebuild them, so
for those the admin still sends ReloadSettings whatever the report says.
New string, in src/i18n/en.json (the only catalogue) under settingsApply:
notReloaded, shown when a refusal comes without a description.
INBUXA Admin
The administration interface for the INBUXA mail server: every server setting, first-boot setup, and recovery, in the browser.
It is schema-driven. After signing in it fetches the server's schema and builds every form, list and menu from it, so it covers every setting the server has without hardcoding any of them.
Design
- One edition. Every feature the server has is available here, with
nothing held back. See the INBUXA server's
docs/spec/. - Runs anywhere, not on the mail server. INBUXA Admin is its own
deployment, never installed onto the mail server. It's pointed at the server
either at build time (
VITE_API_BASE_URL) or at deploy time:<meta name="api-base-url" content="https://mail.example.com">inindex.html. Hosted like that, it signs in as the OAuth clientinbuxa-admin, which the server registers when it's started withINBUXA_ADMIN_URLset to INBUXA Admin's address (for development,http://localhost:5173). - INBUXA's look: the logo and ihasmail's palette.
- Two-factor setup names INBUXA as the issuer, and no longer makes authenticator apps fetch a logo from a third-party site.
Developing
npm ci
npm run dev # http://localhost:5173, against VITE_API_BASE_URL in .env.development
npm run typecheck && npx eslint src/ && npx vitest run
npm run build
Keeping up with upstream
The upstream codebase's history contains no code under a proprietary license,
so this is an ordinary git fork. upstream is a fetch-only remote:
git fetch upstream --tags
git merge v1.0.12 # the next release tag
Versions
INBUXA Admin has its own dated version (inbuxa-version.json), shown with the
upstream release it's based on: INBUXA Admin 2026.9.18 (base 1.0.11).
package.json keeps upstream's version, so upstream's bumps merge cleanly.
Source code
Every build carries its own source. The interface links to it (the user menu
and the sign-in page), and the build writes it next to the app as
source.tar.gz: the exact tree the running version was built from.
License and credits
Free software under the GNU Affero General Public License, version 3.
INBUXA Admin is forked from the upstream AGPL-3.0 web administration codebase originally developed by Stalwart Labs. Their copyright notices are kept on every file inherited from it, and INBUXA's own notice is added to the files it changes. Those files are offered upstream under the AGPL-3.0-only or a proprietary license. INBUXA uses them under the AGPL-3.0 only. INBUXA isn't affiliated with or endorsed by Stalwart Labs.