Multi-User
Solid Accounting supports real multi-user access — multiple people working in the same .solid file, from their own computers, with no cloud round-trip and no shared-drive surprises. This page explains how it works and the trade-offs of the two operating modes.
What "real multi-user" means here
The cheap way to get multi-user is to put your file on a shared drive (Dropbox, OneDrive, a network share) and have everyone open the same file. That works for a single user at a time and breaks the moment two people post entries simultaneously — sync conflicts, partial writes, file corruption.
Solid Accounting's approach: one machine becomes the authority for the file and runs an embedded HTTP API. Other clients on the same network connect to it. Every write goes through the authority — there's exactly one writer, never a merge conflict, never a partial write. Reads are served live from the authority, not from a stale cached copy.
The authority can be either:
| Mode | Run on | Used for |
|---|---|---|
| Host Mode | A regular Solid Accounting install (your laptop, a desktop) | A small team, occasional concurrent use, the host doesn't always need to be on |
| Dedicated Server | A NAS, an office workstation, a small VM | Always-on access; multiple time zones; nobody wants their laptop to be the bottleneck |
Both speak the same protocol — clients can't tell the difference. You can start with Host Mode and migrate to a Dedicated Server later without changing how anyone connects.
Auto-discovery via mDNS
When the authority comes online, it broadcasts _solidaccounting._tcp.local on the local network using mDNS (multicast DNS, the same mechanism AirPlay and Bonjour use to find printers and speakers). Other Solid Accounting clients on the same LAN see the broadcast and the file appears in their Open File list automatically — no IP addresses to remember, no VPN to configure, no port-forwarding.
The broadcast carries:
- The company name (human-readable, what you see in the picker)
- The hostname of the machine running the authority
- The port the API is listening on
Clients filter discovered servers by company name; if you've worked in that file before, it's pre-selected.
mDNS only works on the local network — it doesn't traverse routers. If you need access from another office, see Beyond the LAN below.
Host Mode
Host Mode is the simplest setup. One person enables Host Mode on their already-installed Solid Accounting, others connect from their own machines.
Enabling Host Mode
- Open the
.solidfile you want to share. - Settings → Multi-User → Enable Host Mode. The app starts the embedded API server, opens a port on localhost, and begins the mDNS broadcast.
- The status bar shows a Hosting indicator. Anyone on your LAN can now discover and connect to this file.
Disabling
Settings → Multi-User → Disable Host Mode (or just close the app). Connected clients are notified, their sessions end gracefully, and the mDNS broadcast stops. Any pending work clients hadn't saved is preserved on the host's copy of the file.
When Host Mode is the wrong choice
- The host laptop sleeps frequently — clients lose access whenever it does
- People work across time zones and the host isn't around when they need access
- More than ~5 concurrent users — the host machine starts feeling the load
Any of those, move to a Dedicated Server.
Dedicated Server
The Dedicated Server is a headless build of Solid Accounting — same code, no GUI. It runs as a long-running process on whatever machine you point it at: a NAS, an office workstation that's always on, a VM. It's the same .solid file as a desktop file; you can copy it to the server and back to a desktop without conversion.
Run it from the command line, as a system service, or in Docker. It listens on the configured port, serves the API, and runs the same mDNS broadcast as Host Mode.
The server has no UI of its own — administration is done from any connected client. Adding users, changing roles, viewing the audit log, running reports: all from the desktop or laptop you'd already be using.
When you'd want one
- More than ~5 concurrent users
- Round-the-clock access (one person doing data entry from home in the evening, another in the morning)
- You want the file location to be a single, well-defined operational surface — not "wherever Sarah's laptop is plugged in"
- You want to back up the file independently of any one person's machine
Real-time sync
Once a client is connected, changes propagate via server-sent events (SSE) — the authority pushes updates as they happen, no polling. When someone posts a new invoice, every connected client sees the AR balance update within milliseconds; the customer's aging report refreshes; the GL register shows the new line.
SSE was chosen over polling because:
- Sub-second latency on changes
- Lower network and CPU than aggressive polling
- Standard HTTP — works through any proxy or firewall that allows web traffic
Only one TCP connection per client, kept alive by the protocol. Clients automatically reconnect if the network blips; on reconnect, they request any events they missed and catch up.
Roles and permissions
Solid Accounting ships with three built-in roles. The authority enforces them on every write — clients can't bypass them by editing local copies, because there's no local copy to edit.
| Role | What they can do |
|---|---|
| Admin | Everything — manage users, change roles, lock periods, configure host/server settings, run any report, post any transaction. Typically the file owner. |
| Bookkeeper | Day-to-day data entry: invoices, bills, payments, deposits, reconciliations, journal entries. Can run reports and manage contacts. Cannot manage users or change company settings. |
| Read Only | View transactions and run reports. Cannot post anything. Useful for owners who want visibility without entering data, or external advisors who only need to look. |
The Admin role can grant any user any of the three. Changes take effect on the user's next request. For specialty needs (an outside accountant who needs to post period-close entries but not manage users) Admins can grant temporary Admin and revoke it after the close — the audit log records every grant and revoke.
Session management
Connected sessions are tracked on the authority. From any Admin client, File → Manage Sessions shows:
- Who's connected, on which machine, since when
- Which client version they're on
- The last action they performed and when
You can revoke any session — useful when someone leaves the company, when a laptop is stolen, or just to force a fresh login after a permission change. Revoked sessions disconnect immediately; the user has to re-authenticate to reconnect.
Beyond the LAN
mDNS doesn't traverse routers, so out-of-the-box discovery only works for users on the same physical network. Three options for remote access:
- VPN. Connect remote machines into the office LAN. mDNS works as if they're local. This is what most small businesses already have for file shares and printers; same setup applies.
- Manual address entry. Clients can connect to a server by IP/hostname + port directly, skipping discovery. Use this when the server has a stable address (a fixed IP on a NAS, a Tailscale name, a Cloudflare tunnel).
- Hosted multi-user. A future option — Solid running our managed coordination server for users who don't want to operate their own infrastructure. Not currently offered; on the roadmap.
For now, if you have remote workers, VPN is the answer most teams reach for, and Tailscale is a particularly clean fit because the Solid client can speak directly to the Tailscale name.
Backup and multi-user
Cloud Backup runs on the authority — the machine that holds the canonical .solid file. Other clients don't run their own backup; they don't need to (they don't hold the file, just sessions against it).
If you migrate from Host Mode to a Dedicated Server, move Cloud Backup configuration with it: re-run the wizard on the server with the same destination, password, and recovery phrase. The backup catalog continues across the move.
Threat model — the honest version
What multi-user defends against:
- Concurrent-write conflicts. One authority means one writer; impossible to have two people overwrite each other.
- Stale reads. Every read is live against the authority, never a cached copy.
- Lost work from a crashed client. Writes commit to the authority before the client is told they succeeded — a client crash mid-edit loses only the in-flight edit.
- Permission bypass via local file editing. Clients don't hold the file; there's nothing local to edit around the rules.
What it doesn't defend against:
- Compromise of the authority machine. If someone gets shell access to the host, they have the file. Standard endpoint hygiene applies.
- Network sniffing on an untrusted LAN. The API speaks HTTP locally; on any LAN you'd consider untrusted (a coffee-shop network, an unmanaged guest VLAN), use a VPN or skip the host-mode option entirely.
- Insider data exfiltration by an Admin or Accountant. Roles control what people can write, not what they can read or export. An Admin can always run a report and save the file. The audit log records who exported what and when.
Reference — things to know
- The default port for the embedded API is configurable; pick something that doesn't clash with whatever else runs on the authority machine.
- The mDNS service type is
_solidaccounting._tcp.local.— useful if you want to monitor for new authorities appearing on your network. - Host Mode and Dedicated Server speak the same protocol; clients on a given file can move between them without re-pairing as long as the file's identity (its file ID) stays the same.
- The authority's
.solidfile is the only canonical copy. Don't simultaneously host the same file from two machines — clients will pick one, and you'll have diverging timelines on the other. Migrating means moving, not duplicating.