Entrant

Visitor management for controlled sites

Proof at the front door.

Every visitor signs your agreements before they are through the door, is screened against the lists you keep, and leaves a record that cannot be quietly edited afterwards. Hosted by us, or on a machine in your own reception that sends nothing anywhere.

Hosted or on your premises No trackers on this site Contrast checked on every build

yourcompany.entrant.app/admin
The Entrant visit log: the day's arrivals with their screening result, their host, and whether an agreement was signed.
A visitor signing in on their own phone.

At the door

Four things happen before anyone is through.

The same four every time, on the kiosk at reception or on the visitor's own phone, whether the front desk is staffed or not.

  1. Sign in

    A kiosk at reception, or a QR code the visitor scans with their own phone. Someone who has been before is recognised and does not type their company twice.

  2. Screen

    Checked against your own block list and the U.S. consolidated denied-party list before the visit is even written. Your block list holds them at the desk and emails security; the screen just says someone is coming.

  3. Sign

    Your NDA and your export-control acknowledgment, in the versions you published, signed on the screen and kept as a PDF with its hash.

  4. Admit

    A badge that says plainly whether an escort is required, and a message to the host saying who is waiting and where.

The kiosk

The real thing, screen by screen.

Not a mock-up: these are screenshots of the product, taken by the build that shipped it.

Waiting at reception. One instruction, in the customer's own colours.

The kiosk waiting at reception, showing the company's name and one instruction.

The record

Written once, and sealed to the row before it.

Every event — an arrival, a signature, a screening hold released, an export taken, a support engineer looking inside — is appended to a log where each row carries the hash of the row before it. Alter a row and every hash after it stops matching, and the console says so on its own front page rather than waiting for someone to run a script. On the hosted service the account that serves your site cannot update or delete an audit row at all: the database refuses it.

  • Signed agreements as PDFs, per visit and per published version, each with its hash.
  • Exports an auditor can take away — CSV and PDF for the range they ask about, and the export itself goes on the record.
  • Retention you set, and records that outlive the subscription, because the obligation does.

How the record holds up

09:41:07visit.createa3f1…9c02
09:41:31screening.cleared7be4…d118
09:42:12agreement.signedc90a…41ef
09:42:40badge.printede6c2…58f0
11:18:03export.csv1f5d…aa71
14:05:58visit.checkout51ab…207d
Each hash covers its own row and the hash before it.
Roll call · in progress
A roll call in progress: everyone on site, each marked safe or unaccounted for.

When the alarm goes

The roll call already knows who is inside.

It is the same record, so nothing has to be told who is on site: the list is everyone the door let in and has not let out. Wardens mark from their own phones, anyone who arrives while it is open joins it tagged as having arrived during it, and what comes out at the end is a document saying who marked what, and when.

What a roll call produces

Where it runs

Our machines, or yours. The same product either way.

Hosted

Your own address at yourcompany.entrant.app, your own database schema and your own file store — separate from every other customer's, not a shared table with a filter in front of it. Upgrades, backups and monitoring are ours.

On your premises

The same product on a machine in your reception. The database and the signed PDFs sit on your disk, under your access control and your backups, and nothing leaves the building. For the sites whose policy says so.

The on-premises tier in detail →

Before it ships

Software at your front door is only as good as what it refuses to do.

So these run on every build, and a failure stops the release.

21 verification suites on every push — not unit tests of the parts: eleven of them start the real server and drive it over HTTP, against a real Postgres and the on-premises database both.
2,200 assertions inside them — the refusals, the races, the upgrades and the ways back from a bad day.
330 contrast measurements, on every colour scheme a customer can choose, in both themes, so a warning is readable in the room it is read in.
0 trackers, cookies and third-party scripts on this website. The fonts are served from here; nothing on this page phones anyone.

Before you sign anything

Six questions worth asking every vendor.

Including us. Ours are here in writing, so you can hold the answers side by side.

Our answers, September 2026. If one of them stops being true, this page is wrong and we will fix it.
The question Entrant
Can the record be edited afterwards? Not without it showing. The log is append-only and hash-chained, and on the hosted service the serving account is refused UPDATE and DELETE on it by the database itself.
Can we run it without sending visitor data anywhere? Yes. The on-premises tier is the same product on your own machine.
Is our data separate from other customers'? Yes — its own database schema and its own file store, reached by a database role that can see only that schema.
What happens when your support looks at our data? It is time-boxed, it needs a reason, and it is written into your audit log, not only ours.
What does your website collect about us? Nothing. No analytics, no cookies, no third-party scripts, no session recording.
What do you not do yet? Single sign-on, a public API, native apps, access-control integrations. Named plainly on the pricing page.

Bring it to your front desk.

We set the first sites up by hand: a walk through your lobby's actual problem, your agreements loaded, and a kiosk that works on the day it arrives.