When we introduced VHSP, it was an architecture: per-tenant containers, defense in depth by default, centralized detection without a shared runtime. The idea was sound, but it was still a diagram more than a system. Since then, it’s become one — and every piece below has been built, deployed to a real host, and verified against real traffic before we counted it as done.
The isolation model, fully realized
Every tenant now gets a complete, dedicated stack: web, database, mail, SFTP, a self-service admin panel, and — new since the original post — its own web application firewall. Six containers per tenant, none of them shared with anyone else on the platform. No multi-tenant daemon anywhere in the request path.
Real request-level defense, not just isolation
Isolation limits the blast radius of a compromise. It doesn’t stop the compromise itself. So we added two more layers, both self-hosted and account-free by design — no vendor dashboard that can change its own terms, pricing, or availability out from under us:
- fail2ban watches every login surface — SSH, the admin panels, each tenant’s own SFTP port — and bans abusive sources automatically, with both platform-wide and per-tenant allowlists for the false positives that always show up in practice.
- A Coraza + OWASP Core Rule Set firewall sits in front of every tenant’s site, inspecting requests for SQL injection, XSS, and the rest of the standard attack catalog — the same detection engine and ruleset serious commercial WAFs are built on, running as a container we own rather than a service we rent.
Both shipped in a conservative, detect-first posture before anything moves to actively blocking traffic — false positives on a WAF have no auto-recovery the way a temporary IP ban does, so we treat that switch as a deliberate decision, not a default.
Hardening we didn’t originally plan to write about
The most honest thing we can say about the last stretch of work is that a meaningful chunk of it came from actively looking for what we’d gotten wrong, not just building what we’d planned to build. Two independent security reviews, run against our own codebase rather than taking our own documentation’s word for it, turned up real issues — a session-signing key that ended up world-readable, an authorization gap on a higher-stakes action than we’d initially scoped it as, a sudo grant broader than it needed to be. Every one of them got fixed, verified, and written up, because a platform whose whole pitch is isolation has to be honest about the parts of itself that weren’t isolated enough yet.
Alongside that: hardware-key and authenticator-app two-factor authentication on both the operator and tenant admin panels, tamper-evident audit logging, encrypted secrets and backups at rest, and a Docker access model where a compromised admin process can’t simply reach for the host’s root-equivalent socket.
Where things stand now
VHSP is still maturing — this remains infrastructure we’re proving out before it carries production traffic that isn’t our own. But the gap between “the isolation model, described” and “the isolation model, running” is closed. What’s live today has been created, attacked with real test payloads, and torn down again on real infrastructure, not asserted from a diagram.
More to come as the platform matures.
Leave a Reply