Where your data lives

Your file is measured, then not kept

There is nothing to sign up for. You bring a file, it is read and measured on the server, and the answer comes back — nothing of the file is written down there. Your work stays in your own browser.

What the server keeps

Not your file. It passes through in the request to be measured, and nothing writes it down. That is checkable.

Your file — a loan tape, an aging report or a trial balanceNot kept on the server

Reading and measuring happen on the server, so the file does travel there in the request — and is kept nowhere once the answer comes back. What you imported is held in your own browser's storage, and in no database of ours.

Your allowances, statements, and any rates you changedNot kept on the server

The same: in your browser. A backup file you download is the only copy that leaves the machine.

The starting assumptionsOn the server

The loss rates and other assumptions every new allowance starts from, set by the administrator so a correction reaches everybody. What you change for your own work is saved in your browser, not here.

The administrator's accountOn the server

One account, so the administrator can read enquiries and set the starting assumptions. There is no sign-up, and nothing you do needs an account.

Anonymous page and tool eventsOn the server

Which page, which tool, which site sent the visit (a host name, never a URL), and a random id that lives in one browser tab — so the site can tell whether it is used. No cookie, no address, and nothing from anybody's file.

Enquiries sent through the contact formOn the server

A message addressed to the operator of the installation. Absent on a deployment with no public site in front of it.

Feature requests, and the addresses that voted for themOn the server

A public board on the product site, so what somebody asks for and who else wants it outlive one inbox. The address is held to keep the count to one per person and to answer them; it is never published. Absent on a deployment with no public site.

To check it, open your browser’s network tab and bring in a file. The calculation takes the file in the request and returns the result; nothing is written, and there is no endpoint that would write it.

Keeping your work

Because your work is in your browser, it is on the machine you used and nowhere else — another browser, another device or a private window will not show it.

Browsers can also delete it without warning. Safari, and every browser on iPhone and iPad, clears a site’s storage after seven days of use without a visit, and other browsers may clear it when a device runs short of space. So download a backup from Your work, under “Backups & browser storage”, and keep it with the working papers. It restores in the same place.

Running your own copy

An organisation that wants the same tool inside its own environment can run a copy of Bilnax. One installation has one operator, and nothing it holds is shared with another. It is a Next.js application and a Postgres database, and it runs on any platform that serves Node.

There is no installer, no support contract and no uptime commitment, because none of those exist yet. Standing one up today is a conversation with one of two named people. Most people never need to: everything works on this site, on your own file, with no account and no agreement.

What an installation needs
Required
Node 24 or later

The runtime. Earlier versions are refused by `package.json`, and the platform's default is usually older than this.

DATABASE_URL

A Postgres connection string, pointed at the TRANSACTION POOLER rather than the direct port. A serverless deployment opens a pool per instance and exhausts the connection limit on the direct port, which presents as intermittent failure rather than a clear error. The application warns when it can tell.

SETUP_TOKEN

A long random value, used once to create the first administrator and then never again. Without it the first account cannot be created — which is deliberate, because the alternative is that the first person to find the sign-in page gets it.

NEXT_PUBLIC_SITE_URL

The address this installation is served from. Canonical links, the sitemap and the structured data all key off it.

Optional
DATABASE_CA_CERT

The certificate authority for a self-hosted Postgres. Supabase's own root is bundled, so this is only needed elsewhere. Certificate verification is never switched off — a connection carrying the starting assumptions and the enquiries has to be able to say who is on the other end of it.

CONTACT_WEBHOOK_URL and CONTACT_EMAIL

Where an enquiry from the contact form is announced, and the address it falls back to. Enquiries are recorded either way; without these nobody is notified and somebody has to go and look.

FEATURE_VOTE_PEPPER

A long random value mixed into the hash a feature-request vote is stored under, so the vote table cannot be matched against a list of addresses by whoever holds it. SET IT BEFORE THE FIRST VOTE OR NOT AT ALL: existing rows keep the key they were written with, so changing it later hands everybody one more vote on anything they had already voted for. It is not a privacy measure on its own — the address is held in clear on the request itself, because a reply has to go somewhere.