mush. / trust & security

What this page is, and isn’t.

This describes the infrastructure and practices underneath every tool on the projects page — how the server they run on is hosted, secured and accessed. It is not a data-processing statement for any one of them. This personal site collects no data and has no accounts, so it has nothing of its own to disclose there. Once a specific tool has real users, look for that tool’s own privacy notice and, where it handles anything sensitive enough to warrant one, its own fuller trust centre — this page is the shared foundation underneath all of them, not a substitute for either. Every claim below is checked against how things are actually configured, not assumed from a provider’s marketing. Last reviewed 9 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-Policy and Permissions-Policy set 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 not yet been tested. Recorded here rather than implied — an untested backup is a hope, not a control, until it has been

Certifications & subprocessors

What the infrastructure holds. Not what I hold.

Neither certification below 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 actually cover, is more useful than a vague “secure infrastructure” claim.

  • Cloudflare — ISO 27001:2022 (certified since 2019, currently against the 2022 revision), ISO 27018:2019 and ISO 27701:2019, per Cloudflare’s own published certifications.
  • Vultr — states SOC 2 Type II, ISO 27001/27017/27018 and PCI DSS (as a merchant) on its own trust centre. Unlike the Cloudflare line above, this session couldn’t independently pull Vultr’s primary compliance page to verify the wording directly — treat this as Vultr’s own claim until confirmed straight from an active account.
Third parties with access to traffic or infrastructure
WhoWhat forSees
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 genuinely rather know.

Email [email protected] 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.