01
Who runs Laver
Laver is built and operated by Developyn Ltd, registered in England and Wales at Cradley Enterprise Centre, Maypole Fields, Cradley, Halesowen, B63 2QB.
For your account details, Developyn Ltd is the data controller. For the work your organisation puts into its workspaces — tickets, comments, wiki pages, attachments — your organisation is the controller and we act on its instructions. The Privacy Policy sets out that split, what we collect and how long we keep it.
The contract that governs that processing is published in full as our Data Processing Agreement. It covers each of the eight things UK GDPR Article 28(3) requires, names every subprocessor, and repeats the limitations in section 07 below rather than quietly leaving them out. You can read it and accept it online without contacting us; if your procurement process needs a countersigned copy, ask and we will send one.
02
Where your data lives
Laver runs on a single DigitalOcean droplet in London, United Kingdom (DigitalOcean's lon1 region). The application, the PostgreSQL
database and every file you upload are all on that one machine — the
database is a container beside the application rather than a hosted
database service, and attachments are written to its disk rather than
to object storage.
So the practical answer to "where is our data?" is: at rest, in London. The two exceptions are the things we deliberately hand to someone else — payments and email — which are named in the next section.
This describes where Laver runs today. It is not a contractual data-residency guarantee, and you should not treat it as one; if you need one in writing, see what we do not claim.
03
Subprocessors
Three third parties process data on our behalf. This is the whole list.
| Subprocessor | What it does | Where |
|---|---|---|
| DigitalOcean | Hosts the application, the database and uploaded files | London, UK |
| Stripe | Payments and subscription billing. Card details go to Stripe, never to our servers | Global |
| Mailgun | Transactional email — verification, password resets, notifications, billing notices | EU infrastructure |
Two absences are worth stating, because products of this kind usually have them. Laver runs no third-party analytics, advertising or session replay script — the only scripts the site will execute are its own, enforced by a content security policy, and visit counting is done on our own server. And no third-party error-tracking service is enabled in production, so application errors and their context stay on our host.
We will update this list before adding a subprocessor, not after. The legal basis on which each one processes data is covered in the Privacy Policy.
04
Encryption and account security
In transit. Everything is served over HTTPS,
with certificates issued and renewed automatically. Both
laver.app and the API answer with HTTP Strict Transport Security
set to one year, including subdomains and with preload — so a
browser that has seen Laver once will refuse to talk to it
unencrypted. Responses also carry a content security policy, X-Content-Type-Options: nosniff and a strict-origin-when-cross-origin referrer policy.
At rest. We want to be exact here rather than reassuring. The database and your uploaded files sit on the droplet's disk, and Laver does not add its own layer of encryption on top of them. Credentials are protected individually — passwords are hashed with Argon2 and backup codes with SHA-256, so neither is recoverable; authenticator seeds and any value you save under Secrets are encrypted with AES-256-GCM under a key held outside the database, each one bound to the row it belongs to so a ciphertext lifted into another row will not decrypt. But we do not claim application-level encryption of your work content at rest, and you should not assume it.
Accounts. Two-factor authentication is available using an authenticator app with single-use backup codes. Changing your password revokes every existing session, because that is the one moment we know the old credential may be in someone else's hands. Sessions have an absolute maximum age they cannot be renewed past, so an active session cannot live forever. Authentication endpoints are rate limited per client, and every request is checked against the workspace it claims to belong to.
05
Backups and recovery
A scheduled job runs once a day and takes two things: a full dump of the database, and an archive of every uploaded file. Both are kept for 14 days and then deleted automatically. A database dump on its own is not a restore now that attachments live on disk, which is why the job takes both.
The limitation you need to know: those backups are written to the same machine they are taken from. There is no off-site or geographically separate copy today, so they protect against database corruption, a bad migration or a mistaken deletion — but not against the loss of the host itself. We have also not published a tested recovery-time or recovery-point objective. Both are listed below as gaps rather than dressed up.
Availability
Laver measures its own availability every thirty seconds and publishes the result, including every interruption it has recorded, on the status page. That page also sets out how we communicate during an incident, and — because it is served by the same host it reports on — what it cannot tell you. It is a measured record, not a committed uptime figure; there is still no SLA, which is listed below.
06
Reporting a vulnerability
If you have found a security problem in Laver, please email support@developyn.com and put security in the subject line. Tell us what you found and how to reproduce it. If you would rather not send details over email, say so and we will arrange another route.
We ask that you give us a reasonable chance to fix an issue before publishing it, and that you do not access, change or delete other people's data while investigating — testing against your own workspace is always fine. We will not pursue anyone who reports a genuine issue in good faith and follows that.
In return, we will confirm we have received your report and tell you what we intend to do about it. We do not currently publish a guaranteed response time, and we would rather say that than print a number we have not measured. There is no paid bug bounty at this stage.
07
What we do not claim
Trust pages tend to imply more than they say. This section exists so that the rest of this page can be read literally. As of the review date above, all of the following are things Laver does not have:
- Any security certification. Laver is not SOC 2 audited, not ISO 27001 certified, and has not been through a third-party penetration test whose results we can share.
- Off-site backups. As described above, backups live on the same host as the data.
- Encryption of your content at rest beyond what the hosting platform provides, as described above.
- A committed uptime figure. We now publish a measured availability history at laver.app/status, but we have not committed to an uptime percentage, there is no service credit if we miss one, and the measurement runs on the same host as Laver — so it cannot see a failure that takes the whole host out. The status page says so itself.
- A contractual support or incident response time. The status page sets out what we commit to telling you during an incident, and how quickly. That is a published promise about communication, not a contractual response or resolution time, and we have not published a support target we are measured against.
If one of these matters to your organisation, ask us — support@developyn.com — rather than assuming. We would rather have that conversation than have you infer something from a page that stayed quiet.