Manual · The book

One server, a client on every desk — pairing, locks, backups, updates.

The shape

Building with Neuridion PRO produces the pair: a Server application for the machine that holds the data, and a Client for every desk. To your forms, scripts and reports nothing changes — the same application, with the database on another Mac. Table events run on the server, where a rule cannot be dodged.

Finding and pairing

Clients find their server over the local network by themselves — same project, same build, no addresses typed. The first contact is a pairing: both screens show the same six digits, the person at the server presses Allow, done. From then on every wire is end-to-end encrypted with pinned keys — stronger than the web's certificate arrangement, with nothing to buy and nothing to renew. Devices are managed at the server: see them, remove one, and a removed device is out at once — its connections are cut there and then, not at its next handshake. The desk that was removed is told. It first sees an ordinary broken wire, so the overlay goes up; the next attempt learns the truth, and instead of knocking for ever it says so and offers the one way back — pair again, six digits, somebody at the server pressing Allow.

Locks

Looking never blocks; the first change to a record takes its lock, saving lets it go, and a colleague is told at once — “Being edited by Anna” at the field. The full story — how it works automatically and how to do it by hand from a script — has its own chapter, Record locking.

The status window

The server's one window answers “is the system well” in a second: request and answer-time curves, the ten slowest queries by name, every connected desk live (with its last minute of actions), devices, locks — and Backups, the same machinery as everywhere, plus the ceremony: restoring on a running server tells every client, disconnects them cleanly, takes the safety copy, swaps, and comes back announcing — clients reconnect by themselves, every window re-reads its truth, and a window whose record no longer exists closes rather than lie.

Losing the connection

A dropped wire is not an error dialog: the client shows a small overlay — this Mac, the wire, the server — reconnects with backoff, and the call that met the outage simply completes when the line is back. What you typed stays put. To a script, a server restart is a save that took four seconds.

New desks and new versions

The server carries its own client: a new desk fetches the matching build straight from it, and when you ship a new version, an outdated client offers “Update from this server” — one press downloads the matching client over the paired wire, verifies its signature, swaps itself and relaunches. Once the swap has held, the version it replaced goes to the Trash — recoverable if the new one refuses to start, without a second application standing beside the first for ever.

Over the internet

The official road is a VPN (Tailscale, WireGuard): the server looks local, the pairing model stays intact, nothing new to configure in Neuridion. A relay service of ours is deliberately ruled out — it would be the first thing a built application could not live without.

One thing does change over a VPN: Bonjour does not cross it, so the desk at home cannot simply find the server — it has to be told where to look. The server's window carries that answer in its header, paste-ready: 192.168.1.20:60948, with a copy button beside it. With a VPN up there are two answers and the button becomes a menu, each address named the way System Settings names it — Wi-Fi, Ethernet, VPN — so the question is which desk, not which interface. Paste it into the client's address field and the ordinary pairing follows. And with a VPN there is nothing to change on the router: no forwarded port, no dynamic-DNS name.

Under load — measured

A penetration test on 23 August 2026: a MacBook Air (Apple M2) as the server, a MacBook Pro flooding it with real paired clients over Wi-Fi, each client hammering in a tight loop with no think-time at all — lists, counts, a sum, a grouped aggregate, and writes. This is far harsher than any office; it is meant to find the edge, not to describe a normal day. What it took:

Read the middle of the table, not the end. The facts to keep:

• Plan around about 50 clients at once. There the server answers well inside a tenth of a second and throughput climbs to a plateau near 700 requests a second. How far it really goes depends on what you build and how hard each client works the server — a form that reads one record is not a report that scans a table. The hundreds beyond are headroom, not a promise.
• Zero errors, and zero refused connections. Through 400 clients hammering with no pause — far past any office — not one request failed and not one connection was turned away. The path that admits a new client runs on its own, so a busy database never refuses a login; only at around 800 such clients do requests finally begin to time out — the edge, deliberately found.
• It slows down, it does not fall over — and it heals itself. Past the plateau more clients add waiting, not work: the price of the one serial write lane that keeps every rule and every table event in a single honest order. When a client vanishes its connection is noticed and reclaimed on its own, so an overloaded server settles back by itself once the rush passes, without a restart. The server's own time per request stays in the low single-digit milliseconds; over a LAN the network is the limit long before the machine is.

For scale: a real office is dozens of people making a request every few seconds — a handful of requests per second in total. Plan for a busy hundred; the plateau above is well beyond that, on a laptop. You will run out of desks long before you run out of server.