Data and privacy · version
Data & privacy
Date: . Operator: PatchFirst (operator details will be published before payments open). Data inquiries and deletion requests: [email protected].
PatchFirst registration requires no name, email address or phone number: choose an invented username without personal data. Enter payment details on the selected provider's checkout. Inquiries to the operator may disclose information in correspondence, as explained below. Neither anonymizing the technical inventory nor encryption promises absolute anonymity.
1. Before submission: on your server
The agent collects a technical inventory and anonymizes it on the owner's server. Hostnames become UUIDs; addresses become a public-address flag. Paths, private images and other identifying values become HMAC labels using the owner's secret. Port numbers are never sent: only the service type and whether it is publicly accessible. A check for addresses, paths and owner-defined identity words can stop submission if a leak is detected.
This reduces risk but cannot guarantee that an unusual combination of packages and versions is unrecognizable. Review dry-run output or JSON before submission, configure identity words and do not include secrets in the inventory.
2. During analysis: PatchFirst sees the stack
The service receives anonymized details: OS and kernel, packages and versions, recognized products and images, process, service type and exposure indicators, technical UUIDs and labels. PatchFirst can read this information during analysis. It matches the inventory against CVEs, exploitation feeds and support-lifecycle data, then calculates findings, a rating and priorities.
Queries to OSV may include package names, versions and the distribution ecosystem; other sources are mostly downloaded as feeds. The real-name dictionary and names password are unnecessary for matching and are not sent to these sources.
3. In the database: anonymized inventory and your choice of names
Anonymized inventories and reports for monitoring are stored in PostgreSQL in readable form. The service reads and searches them with SQL to recalculate findings when vulnerability information changes. They are not encrypted under a fleet key: a copy of the database exposes the anonymized technical stack, UUIDs, labels and update times.
Backups are encrypted with age using a separate recipient public key, with no private key on the server; the server cannot decrypt a backup. The operator configures disk encryption on the host, outside PatchFirst code. This protection does not hide data from the running service.
Name encryption is off by default. The agent sends neither the real hostname nor a name dictionary. You can leave names unset or choose an alias of up to 64 characters without control characters: it is stored openly in PostgreSQL and available to the service and anyone holding a database copy. Do not enter a domain, IP address, company or customer name; use an alias such as web-1. Enable encryption in Account with a separate names password. Your browser moves existing names into an encrypted dictionary; the open copies are deleted from the service in the same action. Then update agent configurations so they send names with the new key.
When name encryption is enabled, the “label → real name” dictionary is encrypted separately on the owner's side using a viewing key (AES-GCM, sealbox format). PatchFirst does not hold that key; the owner's browser or client opens names. The separate names password differs from the login password and is never sent to the service. The server cannot recover old names if it is lost.
The anonymized stack is available to the service during storage and analysis. Backup and disk encryption do not hide it from the running service. A compromised owner device or browser can expose names and keys; an unusual combination of versions may identify a server.
4. Network, account and browser
The webhook receiver URL is stored by the service in plaintext alongside the fleet and may identify your company. Use an address without a recognizable domain, such as a proxy or webhook receiver service. The webhook signing secret is stored encrypted with a key derived from the service pepper for a separate purpose. The service decrypts it to sign deliveries. The receiver gets selected events, the server UUID, an open alias if set, and brief finding details; inventory and encrypted names are excluded. The delivery log stores the time, event type and outcome without the receiver's response body.
The connection IP is used only in memory for rate limits and brute-force protection and is never saved to disk. Caddy does not keep an access log; API and error logs contain no IP addresses or User-Agent values. The service does not retain request headers or complete request URLs. The network provider handles connections under its own rules.
To protect the public free-check counter, the database stores an HMAC of the address with a secret service salt and the time of the last counted completion. This allows at most one counted check per address in 60 seconds, including after restarts. The address itself is not saved; expired HMAC records are deleted when another check is counted. The aggregate survives report deletion.
Accounts use a username and password to sign in. The database stores only an HMAC-SHA256 of the username with a secret pepper kept in a separate file, not inside the database. There is no plaintext or encrypted copy of the username. Login passwords are stored as strong salted scrypt hashes, never as plaintext. Only a verification value is stored for the recovery code; the code itself is not retained. It restores sign-in access rather than decrypting inventory or names. The service stores sessions, the accepted terms version, quotas and access periods.
Dashboard payments open the checkout of Paddle, ЮKassa or CoinsSend. PatchFirst sends a random opaque order number and payment parameters: amount and currency. PatchFirst sends no username, name, email, phone number, address, IP or card details to the provider. Payment records retain only the order number, amount, currency, status, time and irreversible hashes with a service secret derived from external buyer identifiers. These are pseudonymous data: the hashes are used only to prevent bonus abuse. A payer fingerprint is derived for card payments through Paddle and ЮKassa. CoinsSend does not provide a payer fingerprint; no such hash is stored for cryptocurrency payments. Provider webhooks may contain extra payer information: it exists only in memory for authentication and event parsing, is not stored in the database and is not logged. Raw webhooks, payment API responses and payment credentials are not stored or logged, including on errors.
Paddle and ЮKassa are independent controllers of payment data: their own terms govern processing for checkout, checks, receipts, refunds and chargebacks. Read the Paddle privacy policy and ЮMoney / ЮKassa privacy policy. Paddle acts as Merchant of Record and handles applicable sales taxes. The Russian seller receiving ЮKassa payments is an individual entrepreneur; its missing details must be provided in the terms of service before payments are enabled. If the platform requests an email address or phone number for electronic receipts under Russian Federal Law No. 54-FZ, these contacts are not passed to PatchFirst for storage.
CoinsSend is a custodial cryptocurrency service and an independent controller of payment data. From the order, PatchFirst sends CoinsSend only the opaque order number and amount in USD, without a username or payer details; fee settings and dashboard return settings contain no payer information. At checkout CoinsSend itself receives browser technical details and cryptocurrency transaction data under its privacy policy. AML checks are performed by CoinsSend under its AML policy: it may request additional information or delay a payment. Receipts on the merchant balance are held for 24 hours. Public blockchain records are not deleted with a PatchFirst account.
Your browser may retain the selected theme and panel access data. A session cookie supports login; the legacy panel stores its access key locally. A URL fragment after # is not sent to the server in the HTTP request, but anyone who obtains the complete link may obtain its secrets. Public pages use no third-party fonts, advertising trackers or external analytics.
Invitation bonus relationships store only opaque inviter and invited account identifiers, without emails or names. The ledger records server-month credits, redemption, expiry and reversals; a chosen server is identified by its technical UUID.
5. How technical data is used
The anonymized technical stack and operational records support the requested checks and monitoring, accounts, payment accounting and abuse prevention. The service and its sources process technical data only to the extent described above. Selling inventories or using them for advertising is outside the service's purposes.
An inquiry to [email protected] discloses your sender address and any information you include in the message to the operator. We use this information to respond to the inquiry. The operator deletes correspondence and attachments from working copies under their control within 30 days after resolving the inquiry, except information that must be retained by law; backups follow their cleanup cycle. An account or order identifier and a description without secrets are enough for technical questions; do not send unnecessary personal data, passwords or full payment details.
6. Retention and deletion
The operator can configure removal of monitoring objects that stop updating; the default is 180 days. Empty fleets are removed after one week. A free check runs with one command. Its report remains available through a link for 7 days, encrypted with the report key. The key is in the URL fragment after # and is not sent to the server in the HTTP request; the browser passes it to the API in a header to open the report. These are technical cleanup periods, not a promise that deleted data can be restored.
You may delete servers and request deletion of your account and associated technical data. Disable the agent so it does not submit data again. Immediate deletion of every backup is not promised; ask the operator about backup cleanup arrangements.
Orders, these hashes and the inviter–invitee relationship are retained after account deletion, without the username or account data, for payment and refund accounting.
7. Your requests and the scope of this notice
Contact [email protected] with questions about technical data or to request deletion. To protect the account, the operator may ask you to demonstrate access without requesting your name or identity documents. Applicable statutory rights remain available.
Operator details, governing law and jurisdiction: PatchFirst (operator details will be published before payments open); to be stated together with the operator details. Revisions to this notice carry a new date. Related documents: terms of service and acceptable use policy.