(Trust)
Security at Verne Software
Verne Software runs on servers of OVHcloud in a French data centre. That makes the platform EU-hosted. The company itself is registered in Serbia, outside the EU and the EEA, so our own access to the data is a transfer to a third country; /gdpr and /dpa say how that is covered.
This page lists what is in place on 5 November 2026. Every measure here is also in Annex II of the Data Processing Agreement, which is the version that binds us. If a measure is not on the list, do not assume it exists.
Where it runs
- Servers: OVHcloud, one data centre in France.
- Backups: OVHcloud Object Storage, Paris region, a different site from the servers.
- Outgoing email (sign-in codes, recovery links, deletion warnings): Scaleway Transactional Email, Paris.
- Every company that touches customer data is on /subprocessors, with the location and the safeguard for each.
What is in place
| Topic | What we do |
|---|---|
| Encryption in transit | The websites and the API are served over TLS with Let's Encrypt certificates, managed by the reverse proxy. Plain HTTP is redirected to HTTPS, and browsers are told to use HTTPS only (HSTS, one year). |
| Network exposure | Web and API traffic reaches the platform through a single reverse proxy. Apart from it, only the ports of our own mail server are open to the internet. Databases, the cache and internal services sit on internal container networks, and their ports are not published. |
| Gateway | Every API request passes one edge gateway. It checks the API key and the rate limit before the request reaches any service. A key carries a set of scopes (Relay, Gate, Clockwork, Passepartout); a key without the scope is refused with 403. |
| Attack filtering | Requests are rate-limited at the edge and filtered by CrowdSec, which blocks addresses associated with attacks. If CrowdSec itself cannot be reached, traffic passes: we chose not to block our own customers during a restart. |
| Customer isolation | Each end-user identity is bound to the customer that owns it. A customer's key sees only its own users. The same email address at two customers is two different people, each with their own password, sessions and mail. |
| API keys | Generated from 32 random bytes and stored only as SHA-256 hashes. We cannot read a key back. |
| Passwords | Stored by Ory Kratos as bcrypt hashes, cost factor 12. A hash a customer imports from another system is kept in the form in which it was imported. |
| Telegram bot tokens | Encrypted with AES-256-GCM. |
| Second factor | End users and dashboard accounts can turn on an authenticator app (TOTP) and recovery codes. It is optional. |
| Logs | The identity service is set not to write sensitive values to its logs. Reverse-proxy access logs, which include IP addresses, are rotated daily and kept for no longer than 14 days. |
| Access to servers | Servers are administered by our operator over SSH with key authentication. Deployments run from a CI pipeline with its own key. The key used for automated monitoring can run only a fixed list of commands. |
| Admin panel | Served on a separate host (jules.vernesoft.com). It requires an administrator identity, kept apart from customer accounts. |
| Staff actions | What our staff do on a customer's account from the admin panel is written to that customer's audit log, with the actor type staff. |
| Change control | The automated test suite must pass before images are built and released. Deployment is done by the pipeline, not by hand. |
Audit log
Significant actions are recorded in a log that cannot be changed through the service: the database refuses any update, and refuses any delete other than the scheduled removal of entries past the retention window and the deletion of a customer's account. An action in the dashboard or with an API key is written in the same database transaction as the action, so neither is saved without the other.
What is in it: API keys created and revoked, project settings, members and roles, organizations, their roles and members, sign-in provider and security settings, webhook endpoints, automatic-deletion rules, the sender domain for end users' emails, end users' sign-ins and password changes, exports of end users made at the account owner's request, and the log's own retention setting. Each entry holds identifiers, the time, the IP address and the user agent. It holds no email address, name or password.
Two limits, stated because they matter to an auditor. Failed sign-ins are not recorded, because the identity service does not report them. Sign-ins through Telegram are not recorded either.
Retention: 7 days on Free, 30 on Pro, 90 on Advanced; on a contract plan the period agreed, or 90 days if the contract says nothing. The account owner can shorten the window, not lengthen it. Read it in the dashboard or through the API: Audit log in the docs.
Backups
Three databases hold customer personal data: accounts and configuration, end-user identities and credentials, and webhook configuration. Each is dumped once a day and encrypted on the server with a public key before the copy leaves it. The private key is held only by our operator and is not on the server. The encrypted copies go to OVHcloud Object Storage in the Paris region, where OVHcloud also encrypts them at rest.
Each copy is locked against deletion and overwriting for 30 days and is then removed by an expiry rule, no later than 35 days after it was made. The server's own access key cannot delete or overwrite a copy, so an attacker who takes the server cannot erase the backups with it.
Not backed up: email content, support mailboxes, usage analytics and operational telemetry.
Backup freshness is checked automatically; an alarm goes off if the last successful copy is more than 26 hours old. A restore of a production backup was tested on 15 October 2026: row counts in all 70 tables matched the live databases.
Monitoring and status
- An automated external health check runs every 3 hours.
- A watchdog on the server runs every 3 minutes.
- /status shows 90 days of daily uptime for six components (API, dashboard, Relay, Gate, Clockwork, Passepartout) and the history of incidents.
Incidents
If a personal data breach affects a customer's data, we notify that customer, at the data protection contact named in the DPA, without undue delay after we become aware of it. The notice says what happened, which categories of data subjects and roughly how many records are concerned, the likely consequences, and what we have done or propose to do. We send more as we learn it. We give no number of hours: the DPA says "without undue delay". For comparison, a controller has 72 hours from becoming aware of a breach to notify its supervisory authority (Article 33 GDPR).
For customers without a DPA, the privacy policy says the same: customers are told without undue delay.
Report a vulnerability
Write to security@vernesoft.com; the same address is in /.well-known/security.txt. Say what you found, where, and how to reproduce it. Please test only against your own account, and stop as soon as you can see another customer's data.
What this page does not cover
- We hold no security certification.
- Traffic between containers on the same server is not encrypted with TLS.
- Webhooks and scheduled HTTP requests go to the address the customer sets. They are encrypted only if that address starts with
https://. - Sign-in providers a customer turns on (Telegram, Google, GitHub) run under their own terms.
Last checked: 5 November 2026. Questions: support@vernesoft.com.