Skip to content

Rebranding

This page helps you run ihasmail under your own name, such as Acme Mail. It starts with the one thing you must do, then a checklist for the rest.

The one thing you must do

Set SOURCE_URL to your own repository. That is the only obligation on this page. Everything else is your choice.

ihasmail uses the GNU Affero General Public License v3 (AGPL-3.0-or-later). It lets you run it, study it, change it, and deploy it under your own name, commercially if you like. Nobody needs your permission, and you do not need anybody's. In return, the same freedoms travel with the software.

A rebrand counts as a modified version, so three things follow:

  1. Your modified version is AGPL too. A rebranded ihasmail is a derivative work. It carries the same license, and the copyright and license notices stay where they are.
  2. Your users are owed your source, not upstream's. Not the code you forked from — yours, with your changes in it.
  3. Running it as a service counts. This is the one people miss. If people use your modified version over a network, they must be offered its source.

Which is what SOURCE_URL is for

ihasmail's answer is an environment variable. Point SOURCE_URL at your repository and the offer is made. The sign-in page and Settings › About both show it, so the people using your instance are told where to find the code they are actually running.

If you leave it at its default, a rebranded instance points its users at upstream. That is the wrong code — and since it is the only offer being made, it is a license problem, not just an oversight.

Why running it as a service counts: section 13

Section 13 is what separates the AGPL from the ordinary GPL. Under the GPL, if you hand nobody a copy of the program, you owe nobody the source. Webmail is nearly always run for people rather than handed to them, so that would leave a gap. Section 13 closes it: people who interact with your modified version over a network must be offered its source.

The license covers the code, not the name or artwork

Trademarks are a separate question from copyright. That is a practical reason to replace the logo and the name, not only the settings. A rebrand that leaves the original branding in place is a different kind of problem from a license one.

This is a plain-language summary of what the license asks, not legal advice. The text that governs is in LICENSE.

Checklist

Work through this list. The sections below explain each item.

  • SOURCE_URL points at your repository
  • APP_NAME set — this now covers the sign-in heading and the top bar too
  • Sign-in tagline and footer link
  • <title> in web/index.html
  • manifest.webmanifest — name, short_name, description, theme_color
  • Logo, both app icons, the maskable icon, apple-touch, both favicons
  • Accent colors in the three theme blocks
  • <meta name="theme-color">
  • Nothing in Leave these alone touched
  • Image rebuilt, and the sign-in page checked in a private window

Settings, or your own build

Only two things are settings. Everything else means keeping your own copy of the code — a fork — and building your own image.

Kind What How to change it
Setting APP_NAME, SOURCE_URL Environment variables. Change them and restart — no code involved
Fork The sign-in tagline, the artwork, the colors, the manifest, and the rest Built into web/dist when the image is built. Edit your copy and rebuild

Change the name with APP_NAME

No rebuild is needed. Set APP_NAME and restart. It changes all of these:

Where What it looks like
The sign-in heading Acme Mail
The brand beside the logo in the top bar Acme Mail
The browser tab, after sign-in Acme Mail — with an unread count in front of it
/api/health {"ok":true,"name":"Acme Mail","version":"…"}
App passwords ihasmail creates for a browser Acme Mail (Firefox)
The startup log line [ihasmail] Acme Mail listening on …

The log line keeps the [ihasmail] prefix on purpose. In a log, it names the software, not your instance.

Things APP_NAME does not change

These are built into the image. Each needs an edit in your own copy and a rebuilt image.

What Where
The sign-in tagline web/src/views/Login.tsx
Sign-in footer — the version line and the ihasmail.org link web/src/views/Login.tsx
The tab title before sign-in <title> in web/index.html
The installed-app name web/public/manifest.webmanifest
The sign-in page and the top bar used to be on this list

Until 2026.9.2+pr243 neither read APP_NAME. So a rebranded instance still said ihasmail on the first page a new user meets, and again in the top bar afterwards. Both now take the name from the server — the sign-in page from /api/config, which it was already fetching, and the top bar from the session. There is nothing to patch.

The tab title before sign-in is still built in. index.html is served as a plain file, so it has no chance to ask the server for the name.

Replace the artwork

File Used for
web/public/img/logo.png the sign-in card and the top bar
web/public/img/icon-192.png · icon-512.png the installed app
web/public/img/icon-maskable.png Android's masked icon — keep the safe area
web/public/img/apple-touch-icon.png iOS home screen
web/public/img/favicon-64.png · web/public/favicon.ico the browser tab
  • Make the logo taller than it is wide. The sign-in card shows it at 120×143.
  • Leave the name out of the logo. ihasmail's own logo has no name in it; the name beside it is text. A logo with the name drawn into it has to be redrawn for every size and every rebrand.

Change the colors

The main colors are in web/src/styles/app.css, in four places:

:root                            { --accent: #0f766e; … }  /* light */
:root[data-theme="dark"]         { --accent: #2dd4bf; … }  /* dark */
:root[data-palette="ihasmail"]   { --accent: #46cac3; … }  /* the house palette */
:root[data-accent="blue"]        { --accent: #2563eb; … }  /* user accents */
  • The third, the house palette, matters most. A new account starts on it, so it is the one most people will see.
  • Leave the fourth alone unless you want to offer a different set. These are accents a user can pick over the top of any theme. Overriding your brand is what they are for.

Two more colors live outside that file and are easy to miss:

  • theme_color in web/public/manifest.webmanifest — the installed app's window color
  • <meta name="theme-color"> in web/index.html — the mobile browser's bar color

These two currently disagree in upstream ihasmail (#0f766e and #0d2430). Set both on purpose rather than copying one.

Leave these alone

These contain the name, but none of them is something your users see as branding. Renaming them costs something and gains nothing.

Name Renaming it costs
VERSION and VERIFY_KEY in web/public/sw.js invalidates every cached shell and every stored push verification at once
ihasmail:lastUser, ihasmail-theme in localStorage every user's remembered address and theme, silently
application/x-ihasmail-emails · -folder drag and drop, until every producer and consumer agrees again
the "ihasmail" theme value in settings.json strands the stored preference of everyone already on it, since the value is what is saved, not the label

The last one needs thought. The theme's colors are yours to change — that is the [data-palette="ihasmail"] block above. But its stored value is data that already exists in your users' accounts.

Rebuild the image

Build it like any other ihasmail image, passing the version in:

docker build --build-arg IHASMAIL_VERSION="$(node scripts/version.mjs)" -t acme-mail:local .

The version has to be passed in because .dockerignore keeps .git out of the build. If you carry your own patches, your own version scheme probably makes more sense than upstream's commit date and pull request number. The argument is just text.

When it is built, open the sign-in page in a private window to check it.

Related: Configuring for APP_NAME and SOURCE_URL in context, and Installing for the build.