A page for whoever reviews this, not whoever is selling it.
This is the technical half of a security review: where data lives, who can reach it, how it's encrypted, and what's logged. It says plainly what we don't provide, too. Compliance is a programme your organization runs; this is the infrastructure half of it.
One region. Nothing leaves it.
EU production runs in Germany by default, on Hetzner. US production runs in the United States by default, on DigitalOcean. Other regions are available on request. The sandbox runs in Germany, on netcup. Data stays in the region it was created in.
| Environment | Provider | Location |
|---|---|---|
| EU production (default) | Hetzner | Germany |
| US production (default) | DigitalOcean | United States |
| Sandbox and development | netcup | Germany |
| Other regions | On request | Agreed before deployment |
Whichever provider is chosen, the platform runs in a single region, and application data, backups, and logs stay inside it; nothing is replicated or processed outside it as a matter of course.
Backups are encrypted and retained on a rolling schedule. Restoring from one is a deliberate, logged action, not an automatic failover to a copy you can't account for.
Who can reach production, and how we know.
Our engineering team is small and distributed. Production access is individually credentialed, not shared, and scoped to what a given engineer's work requires rather than granted wholesale.
Every administrative action against production, a role change, a manual data touch, a deploy, is attributable to the person who made it and logged as such. We hold our own infrastructure to the same access-control and audit-trail standard the platform enforces for your tenants.
We say the team is distributed because a reviewer will find that out either way, and stating it here is more useful than a reviewer discovering it later and wondering what else wasn't said.
At rest, in transit, and still searchable.
Encrypting a column and still being able to query it are usually in tension; the blind index is what resolves that without falling back to storing the value in the clear.
Append-only in the schema, not just in policy.
The audit log rejects UPDATE and DELETE
at the database level. That isn't application logic that could be
skipped by a new code path; it's a constraint the schema itself
enforces, so a compromised application account still can't rewrite
history.
It records role changes, data erasures, and refused attempts to reach another tenant's data, each entry attributable to a user, an application, or an administrative action, in a form a human can read without a translation layer.
Enforced three times, not once.
Authorization in the service, row-level security in the database, and schema constraints that make the wrong tenant assignment unrepresentable. The full breakdown, with the numbers behind it, is on the platform page.
None of the three layers alone is the security boundary. A bug that defeats one is still caught by the next. See how the boundary holds →
Where to send it, and what to expect.
Report a suspected vulnerability or an active incident to [email protected]. We reply within one business day, sooner for anything that looks active or urgent.
A machine-readable version of this contact path is published at
/.well-known/security.txt.
Who else touches data, and for what.
| Provider | Used for | Purpose | Location |
|---|---|---|---|
| Hetzner | Platform | Production hosting: compute, database, backups. Default for EU deployments. | Germany (EU) |
| DigitalOcean | Platform | Production hosting: compute, database, backups. Default for US deployments. | United States |
| netcup | Platform | Sandbox and development environments. | Germany (EU) |
| EmailJS | This website | Delivers messages submitted through this site's contact and sandbox forms. Sees the name, email and message you enter; nothing else. Not used by the platform. | United States (AWS). EmailJS Pte. Ltd., Singapore; EU transfers under Standard Contractual Clauses. |
| Google Calendar | This website | The demo scheduling widget. Google, not Latch Vector, holds the calendar data for a booked slot. | Google Ireland Ltd for EEA users; Google processes Calendar data globally and does not limit it to one region. |
| Plausible Analytics | This website | Cookie-free traffic analytics for this marketing site. Does not run inside the platform product. | EU. Visitor data does not leave the EU; entity incorporated in Estonia. |
The three website services above never touch platform data. If you are assessing what processes your users' data, only the hosting rows apply, and on the Regulated plan that is a deployment in the region you choose.
A DPA (AVV) covering these sub-processors is signed on every plan, before any customer data is processed. We tell you before a new sub-processor starts handling customer data.
What each control supports, and under which article.
The left column is a technical control that exists in the product today. The right two are the obligations it helps you meet. It supports your compliance programme; it does not certify anything, and running the programme is still your organization's job.
| Our control | Supports (GDPR) | Supports (HIPAA Security Rule) |
|---|---|---|
| Tenant isolation: row-level security in the database, plus schema constraints and authorization in the service | Art. 32(1)(b) — confidentiality and integrity of processing systems; Art. 5(1)(f) — integrity and confidentiality | §164.312(a)(1) — access control; §164.308(a)(4) — information access management |
| Append-only audit trail, enforced by the schema | Art. 30 — records of processing; Art. 5(2) — accountability | §164.312(b) — audit controls; §164.308(a)(1)(ii)(D) — information system activity review |
| AES-256-GCM encryption at rest with rotatable keys, and a keyed blind index instead of plaintext search | Art. 32(1)(a) — encryption of personal data | §164.312(a)(2)(iv) and §164.312(e)(2)(ii) — encryption and decryption |
| TLS on every connection, no plaintext fallback | Art. 32(1)(a) — security of processing in transit | §164.312(e)(1) — transmission security |
| Multi-factor authentication, account lockout, and per-device session revocation | Art. 32(1)(b) — appropriate technical measures | §164.312(d) — person or entity authentication; §164.308(a)(5)(ii)(D) — password management |
| Refresh-token rotation with reuse detection, and role changes that invalidate current tokens | Art. 32(1)(b) — ongoing confidentiality; Art. 25 — data protection by design | §164.312(a)(2)(iii) — automatic logoff; §164.308(a)(3)(ii)(C) — termination procedures |
| Data-subject erasure that scrubs personal data, keeps stable internal ids, and notifies your applications | Art. 17 — right to erasure; Art. 19 — notification of recipients | §164.310(d)(2)(i) — disposal (media re-use and disposal) |
| Scoped, individually credentialed and logged production access on our side | Art. 32(4) — access limited to those who need it; Art. 28 — processor obligations | §164.308(a)(3) — workforce security; §164.308(a)(4) — access authorization |
| Encrypted backups on a rolling schedule, restores as a deliberate logged action | Art. 32(1)(c) — ability to restore availability and access | §164.308(a)(7) — contingency plan; §164.310(d)(2)(iv) — data backup and storage |
Read "supports", not "satisfies". A control in the left column is infrastructure you can point an auditor at. The obligation in the right columns stays yours, and most of them also need policy, training and records that no vendor can supply.
What we can put in front of your reviewer.
The parts that stay yours.
What buying this doesn't give you: a Business Associate Agreement with your hosting provider, a documented risk assessment and a designated security officer, an incident-response plan, a third-party penetration test, and deciding who gets administrative access in the first place. Compliance is a programme, not a feature: this page is the technical half an auditor can be shown, not the paperwork half.
Send them directly.
Within one business day