Attendance data that stays on your own servers.

Does your attendance data actually need to stay in?

Plenty of companies run attendance in the cloud quite happily. This is a quick way to tell which group you are in — including the answer that says you do not need this page.

Everything inside one firewall.

The NCheck server runs on a machine you own — a Windows box or a Docker host in your own rack. Check-in stations, phones and the admin client all talk to that server across your own network, and nothing is sent anywhere else. Enrolment creates an encrypted template on your server; the original photograph is not kept, and the template cannot be turned back into a face. Reports, exports and the REST API all run from the same machine. If the building has no internet connection, none of this changes — which is the point.

What it does not do: on-premises does not run itself. You own the machine, the backups and the updates. That is the trade you are making in exchange for the data never leaving.

What leaves your network with cloud attendance — and what does not with on-premises.

With any cloud attendance product, three things travel: the biometric templates created at enrolment, the check-in events as they happen, and the reports built from them. Reputable vendors encrypt all of it and most let you pick a hosting region. For a lot of organisations that is genuinely enough, and we would rather say so than pretend otherwise.

It stops being enough when somebody else decides. A tender that requires data residency in-country. A regulator that asks where biometric templates are processed. A parent company with a policy about third-party processors. In those conversations "it is encrypted and hosted in the EU" is an argument you have to keep winning, and the answer changes whenever your vendor changes a sub-processor.

On-premises replaces the argument with a fact. The server is in your building, on your network, under your backup policy. There is no processor to name, no transfer to document, and no region to attest to, because nothing is transferred. For an air-gapped site the machine has no route to the internet at all. Same product, same apps, same reports — the difference is entirely about where it runs.

What it does not do: running on your own server does not make you compliant by itself. You still need consent, a stated purpose, a retention rule and an alternative for anyone who declines — general guidance, not legal advice.

Air-gapped and offline: how stations keep working.

Offline behaviour is the part people underestimate. A check-in station holds the templates it needs locally, so verification does not depend on a round trip to anything. If the link to the server drops — a cut cable, a failed switch, a remote gate on a bad day — the station carries on verifying and recording, and syncs when the connection returns. Nobody waits at the gate and no shift goes unrecorded.

An air-gapped deployment takes that further: the server itself has no internet route, by design. Updates arrive by hand, on media, on your schedule. This is normal practice on defence, utilities and high-security sites, and it is the one configuration where a cloud product simply cannot compete, because it needs a connection to exist.

The same applies to a site with no connectivity worth the name — a mine, a remote plant, a construction site before the line is in. A local server plus local stations is a complete attendance system that happens never to need a network beyond your own.

What it does not do: an air-gapped server cannot send email notifications or sync to a cloud dashboard, because it has nowhere to send them. If you want both, run on-premises with a controlled outbound route rather than a true air gap.

Installing in an afternoon with the quick-start guide.

The installation is not a project. You download the server from the downloads page, install it on a Windows machine or pull the Docker image, open the admin client, and register your first check-in device. The on-premises quick start walks through it step by step, and the 30-day trial of the server means you can do the whole thing before committing to anything.

Enrolment is the part that takes real time, and it scales with headcount rather than complexity: one photo per person, which a supervisor can do from the same tablet that will be used for check-in. Group enrolment from a single photograph helps where a crew arrives together.

After that, the ongoing work is the ordinary work of owning a server: backups, an occasional update, and the same patching discipline you apply to anything else in the rack. If that is not work you want, this is the honest signal that the cloud edition suits you better.

What it does not do: there is no migration tool that moves a cloud account onto your own server wholesale. Enrolments and settings are re-created; historical records can be exported and kept alongside.

Three places attendance data can live.

Who this is for — and who it is not.

What is biometric data residency?

Data residency is the requirement that certain data be stored and processed inside a particular country or region. For biometric data it comes up more often than for most categories, because face and fingerprint templates are treated as sensitive personal data under GDPR in the EU, under state laws such as BIPA in the United States, under the DPDP Act in India, under KVKK in Türkiye and under the PDPL regimes in the Gulf. The practical effect is that you may need to say exactly where a template is created, where it is stored and who else can reach it. Running the server yourself makes all three answers the same: here. This is general guidance, not legal advice.

What to check before you commit.

Before you ask us.

Keep reading.

Last reviewed: October 2026. Templates, not photos; deleted on request; on-premises keeps everything inside your network. Details on the security and compliance page.