Security and self-hosting

Security you can read, run and verify

Everything here describes the main branch and links to the design it implements. Where something is designed but not built, we say so. Procera supports the controls that security programmes look for; it isn't certified against any standard.

Workspace isolation in the database

A workspace is a tenant. Every workspace table carries a workspace_id and has forced row-level security in PostgreSQL. Each transaction sets the workspace for that transaction only, and the server refuses to start if any workspace table lacks its policy. A cross-workspace test sweep (E2E-R1-ISO) checks that another workspace's records come back as not found.

Workspace admins see and control everything in their workspace, and their reads of content are recorded. System administrators manage workspaces from a separate console and don't read workspace content.

Tracker

Forced RLS and the sweep: BPMS-025, done. System console: BPMS-065, in progress.

People and access: every member with roles, two-step verification status, last activity and department, with quick filters for admins and members without two-step verification

Envelope encryption with key rotation

Each workspace has its own versioned key-encryption key (KEK), sealed by a root key. Sensitive values and file chunks are encrypted with AES-256-GCM under data keys that the workspace KEK wraps. Rotating the KEK needs a reason and step-up confirmation, is audited, and rewraps data keys in the background without re-encrypting the data. Deleting a workspace destroys its keys (crypto-shredding).

Built: local sealed root key, per-workspace KEKs, rotation, rewrap and shredding, the Encryption admin page (BPMS-030, in progress).
Not built yet: root keys in an external key service (OpenBao, cloud KMS) and automatic yearly rotation.

A file chunk is encrypted with a data key; the data key is wrapped by the workspace KEK.

Tamper-evident audit

Every mutation and every restricted read appends an event to a per-workspace hash chain (canonical JSON, SHA-256) in the same transaction as the change. The table is append-only, enforced by grants and a trigger. The audit explorer verifies the chain and shows it; exports need step-up and are themselves audited (BPMS-026 and BPMS-064, done).

Signed checkpoints, RFC 3161 timestamps, WORM export and a standalone verifier are planned for R5 (BPMS-162).

How verification works (an illustration, with shortened hashes)

#10417c1e09ab
document.publishedOlivia Ownerprev 52f0c3d1
#1042a90f44e2
acknowledgement.recordedBen Bakerprev 7c1e09ab
#10433b2d71c8
acknowledgement.recordedCara Chenprev a90f44e2
#1044e07a5f16
evidence.exportedOlivia Ownerprev 3b2d71c8

Chain verified: 4 records

Sign-in, MFA and passkeys

Passwords hashed with Argon2id, known-breached passwords rejected, login throttling and per-IP rate limits.
Sessions with short-lived access tokens and rotating refresh tokens with reuse detection; sign out everywhere; deactivation revokes sessions at once.
Two-step verification with authenticator apps (TOTP) and recovery codes, required by role if you choose.
Passkeys and security keys (WebAuthn) as a second factor and for step-up, with phishing-origin and replay protection.
Step-up confirmation before sensitive actions such as approvals, exports and key rotation.

BPMS-021 and BPMS-022, done. Single sign-on (OIDC, SAML broker) and SCIM provisioning are planned for R4.

Files and malware scanning

Types are detected from content; executables, scripts, HTML and SVG are refused.
Uploads are scanned by ClamAV (clamd, as a separate process) and quarantined on detection. Without clamd, a built-in check catches only the EICAR test file and the server warns.
Download and preview links are signed, short-lived (5 and 2 minutes), bound to the person and workspace, and re-authorised on every request.
Previews are limited to clean images and PDFs, served with a sandboxing content security policy.

BPMS-060 to 062, in progress.

What you need to self-host

Procera is standalone: the first releases need no identity provider, chat platform or HR system. Integrations arrive later, behind optional ports.

PostgreSQL 16+: The only system of record. Row-level security does the isolation work, so other databases aren't supported.
SMTP server: For invitations, acknowledgements, reminders and digests. Bounces are handled; the in-app inbox is always there too.
Object storage: Any S3-compatible store is the design target (SeaweedFS or RustFS as defaults). Today files are stored on local disk; the S3 backend is the next step in BPMS-060.
Valkey or Redis (optional): A cache only, never authoritative: rate limits, session and settings caches. Without it, Procera falls back to in-process caches.
ClamAV (recommended): clamd over TCP for malware scanning of uploads.

How to run it today

There is no packaged release yet. You can build and run Procera from source (a Rust server and a React web app) using the repository's Dockerfile and the E2E compose file as a reference stack. Helm charts, an air-gapped bundle and in-place upgrade tests are planned for 1.0 (BPMS-184).

Pre-release software. Don't put production data in it before R1. Report vulnerabilities privately as described in SECURITY.md.