Why OpsFabric is single-tenant (and why it matters for security)

OpsFabric is a patch management and infrastructure platform. It knows which packages are installed on every server you manage, which CVEs affect them, which CIS rules they fail, which firewall ports are open, which user accounts exist, and which cron jobs are running.

That information, aggregated across a client's entire fleet, is one of the most sensitive datasets in their organization. It is a complete map of every vulnerability they haven't fixed yet, every misconfiguration they haven't addressed, every attack surface they haven't closed.

Now imagine that data sitting in a shared database alongside 200 other companies' vulnerability data, separated by a WHERE tenant_id = ? clause.

We decided early on that OpsFabric would be single-tenant. Every client gets their own physically isolated infrastructure. Not row-level filtering. Not logical separation within a shared database. Physically separate infrastructure.

The data we hold is different

Most SaaS platforms store business data: invoices, documents, messages, project boards. A data leak is bad, but it's not an instruction manual for compromising a company's infrastructure.

OpsFabric stores operational security data. If an attacker gains access to a client's OpsFabric data, they have:

• Every unpatched CVE across the fleet, with severity scores and affected hosts
• Every open port and firewall rule on every server
• Every user account and their privilege levels
• Every failed CIS compliance rule, which tells you exactly which hardening steps weren't taken
• SCAP scan results showing the precise security posture of every machine

This is not data you want sitting in a table next to someone else's data, regardless of how good your row-level security is.

The one missing WHERE clause

In a multi-tenant database, every query that touches client data must include a tenant filter. Every SELECT, every JOIN, every aggregate function, every API endpoint, every report generator, every background job, every data export.

It only takes one query missing that filter. One new endpoint written by a developer who didn't know about the tenant isolation layer. One ORM query that bypasses the middleware. One migration that drops and recreates a view without the filter. One analytics query that joins across tables without the tenant column.

This isn't theoretical. Multi-tenant data leaks happen regularly in production SaaS platforms, including at companies with sophisticated engineering teams and extensive test suites. The architecture itself creates a class of bugs that cannot exist in single-tenant systems.

In OpsFabric's architecture, client A's data is in a dedicated database that client B's application cannot reach. The isolation between clients is physical, not logical. Within a client's own instance, there is tenant-scoped separation for sub-tenants, teams, and projects, but that multi-tenancy exists entirely inside a single organization's trust boundary, under their control.

Can't vs. won't

Let's be honest about this. For SaaS clients, we provision the instance, generate the credentials, configure the database, and manage backups. We have operational access. We could look at client data if we chose to. Any SaaS vendor who tells you otherwise is either lying or doesn't understand their own infrastructure.

What we do control is the attack surface. Our central management layer is designed to work with aggregate health metrics: host counts, instance status, resource utilization, license compliance. The operational tooling doesn't surface client CVEs, hostnames, or SCAP results. There is no dashboard on our side that displays a client's vulnerability data. But the access path exists because we operate the infrastructure.

For organizations where "won't" isn't good enough, OpsFabric offers self-hosted deployment on the Enterprise tier. You run it on your infrastructure, with your credentials, on your network. We deliver container images and release bundles. We never see your data because it never leaves your environment. Air-gapped deployments are supported. No call-home required.

That's where "can't" becomes real. Not through a policy, but through physical separation. The data path doesn't exist because the infrastructure is yours.

The question security teams should ask their vendors isn't just "do you look at our data?" It's "can you, and what are my options if that's not acceptable?" With OpsFabric, the answer scales from managed SaaS on physically isolated infrastructure to fully self-hosted with zero vendor access.

Blast radius isolation

In a shared infrastructure model, an incident on one instance affects every client. A database corruption, a runaway query, a security breach, a failed migration, a resource exhaustion event: all clients are in the blast radius.

With single-tenant architecture, if one client's instance goes down, every other client's instance keeps running. A bug in a migration only affects the instance where it ran. A security incident is contained to a single client's data. There is no lateral movement path between client environments because there is no shared infrastructure to move through.

Incident response is also simpler. When you're investigating a problem, you're looking at one client's dedicated environment. There's no risk of accidentally exposing another client's data during the investigation. There's no concern about a remediation action on one client's environment causing a side effect on another's.

Compliance without the paperwork

If you've been through a SOC 2 or ISO 27001 audit for a multi-tenant SaaS platform, you know the drill: 20 pages of documentation explaining how tenant isolation works, how row-level security is enforced, how access controls prevent cross-tenant data access, how backups are segregated, how encryption keys are managed per tenant.

With single-tenant, most of these questions have one-sentence answers. Where is the client's data? On their dedicated infrastructure. Who can access it? Their instance's credentials. How is it isolated from other clients? Dedicated infrastructure. What happens if another client's data is compromised? Nothing. Their data is in a completely separate environment.

Data residency requirements are equally straightforward. A client in the EU who needs their data to stay in the EU gets an instance deployed in the EU. A client who needs data to stay on-premises gets a self-hosted deployment. There is no shared infrastructure to carve exceptions into.

Multi-tenancy within the instance

Single-tenant between clients doesn't mean no multi-tenancy at all. Within their own instance, an OpsFabric client can create multiple tenants to separate internal teams, departments, business units, or managed clients (for MSPs).

An MSP using OpsFabric gets its own isolated infrastructure with as many internal tenants as it needs. Each tenant has isolated dashboards, compliance reports, RBAC, and policy management. The MSP sees an aggregate view across all their clients.

The difference is that this multi-tenancy exists within a single organization's trust boundary. The MSP trusts themselves to manage their own client separation. What they don't have to trust is that their vulnerability data is properly isolated from an unrelated company on a shared database somewhere.

The tradeoff

Single-tenant architecture costs more to operate than multi-tenant. There are more instances to manage, more databases to back up, more deployments to coordinate. We don't pretend otherwise.

But the alternative is storing the most sensitive operational data your clients have in a shared database and hoping that every query, every endpoint, and every background job correctly filters by tenant, forever, across every release.

For a project management tool, that tradeoff might make sense. For a platform that knows every unpatched CVE in your fleet, we don't think it does.

Your vulnerability data is a shopping list for attackers. We'd rather not put it on a shared shelf.