The builder on the host's network (the last change here) didn't help: the next publish failed exactly as before. Looking on the host showed why. Both builders resolve git.coffeylabs.org publicly; the token isn't fetched by the builder at all. buildx fetches registry tokens on the client side, in the job container, and on ci-net the name git.coffeylabs.org belongs to the gitlab container itself (172.30.0.2) -- which is how the runner clones over plain HTTP, and which has nothing on 443. So every push asked https://git.coffeylabs.org/jwt/auth for a token and was refused. The login before it worked because the host's daemon does the login, and the host resolves the name publicly. For the publish job only, the name now points at its public address in the job's /etc/hosts, looked up from a public resolver, as the host sees it. /etc/hosts wins over Docker's DNS, and nothing else in the job is affected: the checkout is done, and image layers go to the registry's own DNS-only name, not this one. The builder goes back to the shared ci-builder; its network was never the problem. The lookup and the /etc/hosts write were tried in the job's own image (docker:28-cli, same digest): it picks the first public IPv4 address and getent then returns it.
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.