self-hosted error monitor Open the panel

Accounts

one company per database, and how to switch open the screen

What it is for

Separating companies inside the same meulog. Each account is its own database, a separate file on disk.

Why a file and not a column

The decision

The usual alternative is a conta_id column on every table and a filter on every query. Forgetting that filter on one query is enough for one customer errors to show up for another. With one file per account, that leak is not a possible bug: the query cannot reach data that is not in the open file.

The price is that backup, migration and purging run per account. meulog handles that: every scheduled job goes through a conductor that enqueues it inside each active account.

How you switch accounts

Through the picker at the foot of the menu, which only shows up when there is more than one. A person sees the accounts they have access to — not all of them, because listing all would tell one customer administrator the names of the others.

Two ways, and meulog picks by the address you are on:

  • A single address. The default, and the one that asks nothing of DNS: the chosen account lives in your session and the picker switches right there. This is the path for anyone who does not want one DNS record per customer.
  • One subdomain per account (acme.meulog.yourcompany.com), or the customer own domain. It needs the DNS record and a certificate, and in exchange it gives you two tabs open on different accounts at once — which a single session cannot.
The address beats the choice

When the address names an account, the address wins: switching databases while the address bar still says acme would be worse than not switching. Everywhere else the stored choice applies.

Switching accounts opens no door

The session lives in the account database. Choosing an account only decides which database to open; with no session inside it, the sign-in screen shows up all the same. What authorizes you is the access an administrator granted to your address.

The second factor is not asked again on a switch: it authenticated the person, and the role authorizes the account. For the same reason, the authenticator you already enrolled starts working in the other account registration too — two codes in the app for the same meulog would help nobody.

Who sees what

The answer is the person's role, in People › Roles: it lists the accounts where it applies, and an empty list means every account. Taking an account out of a role cuts the access right away, and deletes nothing — the history of what the person did stays readable.

One role per person. Whoever needs different permissions in another account gets another role — and then not both at once, which is the price of not having one permission row per account to keep in sync.

With no account database

meulog works without this screen. On a single-company install it runs as single-tenant and nothing here is needed. Separation is optional, and turning it on later does not require changing what already exists.