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.
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. Individual secrets are protected — passwords are hashed with Argon2 and are never stored or recoverable, and two-factor secrets and backup codes are held hashed — 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.
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:
- A published data-processing agreement. We do not currently offer a standard DPA for signature. If your organisation needs one before it can adopt Laver, write to support@developyn.com and we will talk to you about it.
- 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 published uptime history or status page. We do not yet publish availability figures, and we have not committed to an uptime percentage.
- A contractual support or incident response time. We answer support and security email, but we have not published a 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.