mash. / trust & security
What this page is, and isn’t.
This is the infrastructure and practice underneath every tool on the projects page: how the server is hosted, secured and accessed. It is not a data-processing statement for any one of them.
Once a tool has real users, look for its own privacy notice and, where it handles anything sensitive enough to warrant one, its own trust centre. This personal site has no accounts and no forms, and the anonymous, cookieless visit analytics it does collect are covered on its own privacy page. Every claim below is checked against how things are configured, not taken from a provider’s marketing. Last reviewed 12 September 2026.
Infrastructure
One server, several tools, each its own subdomain.
A trust centre that repeats a hosting provider’s own marketing copy isn’t describing your controls. It’s describing theirs.
Hosting
- A Vultr VPS, running the tools listed on projects as separate subdomains
- Cloudflare in front for DNS, CDN, DDoS mitigation and TLS termination
- No shared hosting, no unmanaged shared tenancy with anyone else’s traffic
Transport & headers
- HTTPS end to end, HSTS enabled (one year, including subdomains)
- Every site carries a real Content-Security-Policy, not a default-allow one
X-Frame-Options,X-Content-Type-Options,Referrer-PolicyandPermissions-Policyset on every response
Access control
- SSH to the server is key-only — password authentication is disabled at the server, not just discouraged
- Per-application access (tenancy scoping, per-object permissions, mandatory MFA for admin roles) is a build standard, not a per-project afterthought — see Architecture
Backups
- Automatic backups are enabled through Vultr’s own backup service for the underlying server
- Restore has been tested and confirmed working, including restoring to a specific point in time (10 September 2026) — not just to the most recent snapshot, which is the harder and more useful case to have actually checked
Certifications & subprocessors
What the infrastructure holds. Not what I hold.
None of these is mine. They belong to the providers whose infrastructure this runs on, not to any tool built on top of it. Naming them accurately, with what they cover, is more useful than a vague “secure infrastructure” claim.
This instance runs in Vultr’s Manchester, UK data centre. Nobody’s actually opened the underlying report PDFs. They’re clickwrapped behind the account’s own terms of use, so what’s recorded here is what the compliance dashboard states is available, not a report read line by line.
| Provider | Standard or report | Date or scope |
|---|---|---|
| Cloudflare | ISO 27001:2022 | Certified since 2019, currently against the 2022 revision, per Cloudflare’s own published list |
| Cloudflare | ISO 27018:2019 and ISO 27701:2019 | From the same published list |
| Vultr, Manchester data centre | SOC 2, SOC 1, PCI-DSS and ISO 27001 | Listed for this location on the account’s own Trust & Compliance page, checked on 10 September 2026 |
| Vultr, Manchester data centre | Not held: HITRUST, NIST 800-53, SOC 3, HIPAA/ |
The same page lists these as unavailable for this location |
| Vultr, company level | SOC 2 Type 2 (AICPA, Trust Service Criteria with the HIPAA Security Rule added) | Last audited 31 December 2025 |
| Vultr, company level | ISO/IEC 27001:2022, ISO/IEC 20000- |
All last audited 25 February 2026 |
| Vultr, company level | DORA Compliance Customer Trust Statement | Assessed by BDO on 18 July 2025 |
| Who | What for | Sees |
|---|---|---|
| Vultr | Virtual server hosting | Everything on the server — the usual position of any infrastructure provider |
| Cloudflare | DNS, CDN, DDoS mitigation, TLS termination | Traffic metadata for every request; decrypted content only at the edge before re-encrypting to origin |
Development & testing
The standard every tool is built to, not repeated here.
Code review, automated testing, dependency and static analysis, and the non-negotiables every tool is held to — tenancy scoping, audit trails on privileged actions, mandatory MFA for admins, WCAG 2.2 AA — are described once, on the Architecture page, rather than repeated here and left to drift out of step with it.
Reporting a problem
Found something? I’d rather know.
Email hello@mashreeves.com with what you found and how to reproduce it. I aim to acknowledge within five working days and will tell you what I can do and by when. A good-faith report, made without accessing more than needed to demonstrate the issue and without disrupting the service for anyone else, won’t be met with a legal threat — that’s a genuine commitment, not boilerplate. This is also published machine-readably at /.well-known/security.txt.
There is no formal, tested incident-response runbook yet — stated plainly rather than implied by omission. A real incident would be handled directly by email in the meantime, and this page will say so honestly if that ever proves not to be enough.
Accessibility is covered on its own accessibility statement, not repeated here. Back to everything I’m building, or the full site.