Security overview

Honest snapshot of how Directo is built today. This is not a trust center, not a pentest report, and not a SOC 2 claim. There is no SOC 2 badge in the product.

Where it runs

• Production is being set up on one Hetzner Cloud server in Falkenstein, Germany (EU), managed through Coolify: the FastAPI API, Postgres 16, Redis 7, uploaded files and the web app, behind Traefik with Let's Encrypt certificates, everything served over HTTPS. Until go-live there is no production tenant; this line switches to the present tense in the go-live commit.
• Pull-request previews of the web app are served by Vercel over HTTPS and point at a demo or test API, never at production data. The public Demo Bistro preview reaches its demo API on an operator-controlled host in the EU through a Cloudflare tunnel.
• Backups: a nightly pg_dump of the database kept 30 days on its own volume on the same server, plus Hetzner's server-level backups off the host. A restore drill is on the go-live checklist and repeats quarterly.

What is true in the product

• Passwords are hashed with argon2id. Sign-in is e-mail + password, an e-mailed one-time link, or a PIN on a tablet a manager registered. Password logins are rate-limited per IP and per e-mail; PIN attempts per IP, and a PIN locks for a while after repeated wrong entries.
• Two-factor authentication (TOTP, with one-time backup codes) can be switched on for any password account and is recommended for owners and managers; with it on, the password alone opens no session.
• Sessions are listed in the app and revocable one by one or all at once; the refresh token rotates on every use and a reused refresh token revokes the session.
• A security audit log records logins, failed logins, 2FA changes, session revocations, password changes and guest erasures, readable by owners, managers and the accountant in Admin → Settings.
• Every venue-scoped table is protected by fail-closed Postgres row-level security (FORCE), and the application connects with a role that cannot bypass it.
• Every request gets a request id (X-Request-Id), echoed in the response and in the structured logs, so an error can be traced without sharing personal data. Error reports go to Sentry only when a DSN is configured — it is not today — and with default PII collection off.
• Admin and staff routes check permission atoms. Connect stores secret refs, never raw keys in the venue row. Dependencies are audited in CI (pip-audit, pnpm audit).
• Directo is not a fiscal printer and not a card acquirer. PaymentIntent and fiscalize stay refused until a real Connect install exists.

AUTH_DEV_BYPASS

Sign-in is email + password, an emailed one-time link, or a PIN on a tablet a manager registered; sessions are revocable and every venue's rows are isolated by Postgres row-level security. AUTH_DEV_BYPASS is off by default, used only by automated tests, and the API refuses to start in production while it is on. Bypass is not authentication.

What we do not claim

• No SOC 2 Type I or Type II.
• No ISO 27001 certificate.
• No completed external penetration test published here (one is planned on a staging host).
• No “bank-grade” or “military-grade” language.

Privacy and hosting detail: Privacy and Subprocessors.