Privacy in practice

Where the data lives, for how long, and how to get rid of it.

The legally binding version is in the privacy policy. This page explains what it means day to day.

Where the data lives #

On a server in Germany. Completely – database, uploads, backups, logs. No object storage in Ireland, no analytics service in the US.

One single exception, and it can be switched off: for the registry check of container images, the image name goes to the public registry concerned — that is library/nginx and 1.25, nothing else. No customer reference, no device identifier, no content. Private registries are not asked at all. Switch it off under Settings › Security; see What data.

What flows between accounts #

Nothing from your device data feeds into another customer's view. No figure, no mean, no group statistic.

That was different until August 2026: there was a comparison with similar systems that fed a device's score into a group evaluation, anonymised and guarded by four thresholds so that nobody could work individual values back out of a mean. When the score went, the comparison went with it — and the consent for it was deleted rather than left standing for an abolished procedure.

The behaviour profile (Device › Behaviour) likewise works exclusively with the history of that one device. It compares your server with itself as of yesterday, not with other customers' servers. There is no shared knowledge base your measurements feed into.

One point of contact remains, and it is voluntary: the measurement network. If you switch it on, your device carries out measurements for other accounts — the measurement traffic then originates from your connection, and whoever operates the target address sees your IP address in their own logs. The requester does not see it in the interface, and you do not see who requested it. The measurement network is off by default; the details are under Sonar and further down this page.

The process watch runs by default #

Since agent 1.16 the agent listens to the kernel continuously — it asks to be told when a program starts, forks or exits. That is the only thing it does between two reports, which is why it is stated here.

What it reads: the program's name, its process number and the name of the process that started it. It also checks the command line against a handful of fixed patterns — mining programs, reverse connections.

What never leaves the server: the command line itself. Passwords regularly appear in it, and the agent cannot tell when. What is transmitted is the result of the check, not its subject — that is 20114:php-fpm>sh, nothing more. A single place in the agent enforces this and reports when it had to.

It reads only. It kills no process, blocks nothing and changes nothing on the system.

It can be switched off on the device page in the dashboard and locally with NODE64_PROZESSWACHE=false.

What is stored #

• The inventory data of your devices (see What data is collected).
• The findings derived from it, with their history.
• Account and user data: email address, name, role, sign-ins.
• The audit log of your account.
• Server logs including IP address – seven days, then they are deleted.

What is not stored #

No passwords (there are none), no private keys, no file contents, no log contents from your systems, no payload data. Device credentials exist as hashes only – a database dump alone is of no use to anyone.

Retention #

History by plan: 7, 90 or 365 days. Open findings stay until fixed or deleted. Deleted devices take their data with them.

In the time-series database too. Measurements over time – utilisation, disk usage, latencies – have been stored additionally in a dedicated database (VictoriaMetrics) since August 2026, because it needs less space and draws histories faster. It runs solely on the same server and is not reachable from outside. The same period applies to it: a daily run removes anything older than your plan promises. A retention period that covers only some of the storage locations would not be one.

Your rights, practically #

Access and export: under Settings → Account you get everything as an archive – account, devices, findings, log. No ticket, no waiting.

Deletion: in the same place. The account and everything attached to it is removed.

Objection to individual processing: disconnecting a device is enough – without an agent no data flows.

Who has access #

The operators of NODE64. Access to customer data happens only where operations require it, and access in the operator area is logged. The operator interface deliberately shows totals instead of customer lists – the number of devices overall, not who runs which.

Sonar and personal data #

Measurement targets and results contain IP addresses, which are personal data. They are subject to the same retention period and are not shared. Participation in the measurement network is voluntary; the traffic originates from your connection, which is stated unambiguously when you switch it on.

The contact form – no captcha, and why #

The form on the contact page works without a captcha. That is a deliberate decision, not negligence: the common services load code from US servers, set identifiers and analyse visitor behaviour – you take on a data protection question you did not have before, for a limited benefit.

Instead, five measures apply, all of which work without third-party code and without processing data about you:

• CSRF token. Submitting from a foreign page is rejected.
• Honeypot. A field only an automated system fills in – for you it is invisible and cannot be tabbed to.
• Time trap. Anyone who fills in the form in under three seconds has not read it.
• Rate limit per address. Five messages per hour. After that, it stops.
• Silent drop. If the system detects an automated sender, it gets the same confirmation page a human would – just without the message being sent. Someone who never learns they were caught does not adapt either.

Should it ever become necessary, we would use something self-hosted that gives the machine a small computation to solve rather than giving you a picture puzzle – no third-party service, no identifier, no analysis of your behaviour.

What goes to the shared knowledge base #

NODE64 learns from what many installations see: which events are everyday and which occur almost nowhere. For that an anonymised extract of your observations goes to the shared knowledge base – over its own path, separate from the regular upload.

It is not the device identifier that identifies, but the combination. A system with exactly 878 packages, exactly 224 services and exactly this kernel version is recognisable without a name. Leaving out the identifier is therefore the smallest part of the work. Before transmission it is:

What never travels: no device name, no hostname, no address, no path, no full version, no account identifier, no sender IP. The table has no column for any of it.

The installation pseudonym. A contribution carries a 16-character identifier formed from your account number and a secret salt. It answers exactly one question: do two contributions come from the same installation? Without that answer, twenty observations from a single installation would be indistinguishable from twenty out of twenty – and that is exactly where someone poisoning the knowledge base would start.

A pattern only forms from 20 observations across 5 installations, and none may contribute more than a quarter. A single sender cannot confirm a pattern, no matter how often it sends.

All plans contribute, and you can switch it off. Then nothing is formed and nothing is written – not "sent and discarded".

And what comes back replaces nothing. The shared context says how ordinary an event is elsewhere. Whether it is a problem on your server is decided by this device's baseline – a server without a connection detects exactly as much as one with.