Multi-tenant by design: how Weldforge keeps your data isolated
Row-level security, per-tenant encryption keys, and ephemeral runtime isolation — the architecture decisions behind a platform you can trust with your systems.
When you let a vendor run integrations against your CRM, your finance system, and your database, isolation is not a feature — it is the whole product. Here is how Weldforge is built so one tenant can never see another’s data.
Data isolation: row-level + Postgres RLS
Every row carries a tenant ID, and PostgreSQL Row-Level Security enforces it at the database layer. The application connects as a role that cannot bypass RLS, so even an application bug cannot leak across tenants. We run canary tests in CI: insert as tenant A, assert it is invisible to tenant B, on every build.
Secrets isolation: per-tenant encryption
Each tenant’s credentials are encrypted with a dedicated data encryption key, itself envelope-encrypted under a KMS customer master key. One tenant’s secrets are never protected by the same key as another’s.
Runtime isolation: ephemeral microVMs
Integrations execute in ephemeral microVMs (Firecracker / Fargate) with per-tenant IAM and an egress allowlist derived from the spec. There are no standing, shared tenant containers waiting to be exploited.
Observability and staff access
Logs, metrics, and traces are tenant-tagged and segregated. Staff cannot read tenant data casually — access is break-glass, masked by default, and dual-logged. We are building toward SOC 2 Type I (targeted month 6) with continuous monitoring from day one, and a HIPAA-ready posture on the Foundry tier.
Read the full posture on our security page — it is the architecture we would want from a vendor we trusted with our own systems.