Trust & security

Your systems, your data, your servers.

STRAX holds your most sensitive operational assets: database credentials, API keys and the data itself. This page explains how it protects them, in plain language and without certification claims we have not earned.

Self-hosted by design

STRAX is deployed on your infrastructure, single-tenant, one installation per customer. Your hub database, your Git server and your network are all yours. There is no mandatory cloud dependency, and your business data never has to pass through ours.

This is how the product is built, and everything described on this page runs inside your perimeter.

Live Your perimeter Single-tenant · your servers · your network
Self-hosted by design The hub database, Git server, services and portals all sit inside your own network perimeter; an outside vendor cloud is crossed out, because there is no mandatory dependency. your network perimeter Hub database your data, your history Git server config history, your repo STRAX services API · workers · monitoring Portals & reports served from inside one installation per customer, nothing shared with anyone else Vendor cloud no mandatory dependency, and your data never passes through ours Everything on this page runs inside your perimeter. No mandatory cloud, and your data stays yours.
Hub, Git, services and portals, deployed on your infrastructure, single-tenant, with no mandatory cloud dependency.

Secrets vault, TLS, MFA and SSO

Every stored secret (connection strings, API keys, SMTP and OAuth credentials, webhook signing secrets, MFA seeds) is encrypted at rest with AES-256-GCM authenticated encryption.

  • One master key per installation, generated at install time and never stored in the repository, the database or any configuration file.
  • Every service verifies the key at startup with a cryptographic canary; a service with the wrong key refuses to start.
  • TLS ships in the installer with a generated certificate, or bring your own; plain HTTP redirects to HTTPS.
  • Console sign-in uses salted password hashing, a configurable password policy, lockout after repeated failures, per-role TOTP multi-factor authentication with single-use recovery codes, and single sign-on over OIDC (Microsoft Entra ID, Okta, Google Workspace or any OIDC provider). Administrators always hold an authenticator STRAX controls, so a compromised identity provider cannot mint an administrator session.
  • Short-lived access tokens, rotating refresh tokens and central revocation.
  • A four-tier role model (ReadOnly, Operator, Developer, Admin) is enforced on every endpoint; machine callers use API keys scoped to the specific routes they need.
Live The vault and the door AES-256-GCM · master key · TLS · MFA · SSO
Secrets vault, TLS, MFA and SSO Stored secrets show as encrypted rows; the per-install master key verifies its canary at startup and a wrong key refuses to start; TLS, MFA, SSO and the role model guard the door. Secrets vault connection strings encrypted ✓ API & OAuth keys encrypted ✓ SMTP · webhook secrets encrypted ✓ MFA seeds encrypted ✓ AES-256-GCM authenticated encryption, at rest, every one of them One master key generated at install, per installation never in the repo, the DB or config startup canary verified wrong key → the service refuses to start a stolen database is ciphertext without the key it never contains At the door TLS: HTTP redirects to HTTPS MFA (TOTP) + recovery codes SSO over OIDC: Entra, Okta… 4 roles, on every endpoint admins keep a STRAX authenticator, so a hacked IdP can't mint an admin Every stored secret, encrypted at rest. One master key, verified at every startup. TLS, MFA, SSO and roles at the door.
Encrypted secrets, a per-install master key with a startup canary, and TLS, MFA, SSO and roles at the door.

A tamper-evident audit trail

Every write through the API is recorded automatically — including denied attempts — with actor, action, resource, result and timing. Authentication events are captured in detail.

  • Audit rows are hash-chained with HMAC-SHA256 under a dedicated audit key: modifying or deleting a historical row breaks the chain, and the built-in verification endpoint pinpoints the exact record.
  • The audit table is append-only, enforced at the database permission level; retention works by archiving to compressed exports, so history is never deleted.
  • Configuration changes are version-controlled in Git with real user attribution, linked back to the audit row.
  • One-click CSV / NDJSON export, hashes included, feeds your SIEM or your auditor's tooling directly.
Live An audit trail that cannot be edited Append-only · hash-chained · exportable
A tamper-evident audit trail Audit rows are written and hash-chained; when one historical row is altered, verification breaks the chain at exactly that record and names it. Audit trail: every write, even denied ones #1041 · admin · credential updated · ok ← #1040 #1042 · api-key · egress config read · ok ← #1041 #1043 · operator · delete DENIED · 403 ← #1042 #1044 · admin · role granted · ok ← #1043 HMAC chain Someone edits #1042 after the fact… verification: chain BROKEN at record #1042, pinpointed, on the record Append-only, by permission no UPDATE, no DELETE; the DB refuses retention = archive, never deletion config changes land in Git, linked back For your auditor CSV / NDJSON export, hashes included ✓ Every write recorded, even the denied ones. Alter one row, and the chain names it.
Hash-chained, append-only audit rows: alter history and verification pinpoints the exact record.

Signed licensing and a curated marketplace

Licence verdicts are signed by us and verified by your installation, and an expired licence never deletes, corrupts or locks your data. The Feature Marketplace is curated:

  • Supplier submissions are reviewed by an operator before they go live, and there is no self-serve publishing.
  • Security flags are recomputed server-side from the actual package contents, never from the author's own declaration.
  • Packages carrying executable content are disclosed as such and require your explicit consent at install.
Live Every listing reviewed Scanned · reviewed · signed
Signed licensing and a curated marketplace A supplier submission is scanned server-side, reviewed and approved by someone at STRAX, then listed; licence verdicts are signed by STRAX and verified by your installation, and an expired licence never touches your data. Supplier submits "Shop sync bundle" v1.2 no self-serve publishing Scanned server-side flag found: executable steps recomputed from the package itself, never taken from the author A person reviews Approve an operator, before it goes live Listed in the catalogue ✓ flags disclosed; executable content asks your consent Licence verdicts: signed, then verified signed by STRAX (ECDSA) verified by your installation a forged or edited licence simply never verifies And when a licence expires licence: expired your data: untouched, never locked or deleted ✓ expiry limits features, never your records Every listing scanned, then approved by STRAX. Flags come from the package itself. Signed verdicts, and expiry never touches your data.
Server-side scanning, human review before listing, signed licence verdicts, and an expired licence never touches your data.

Local AI, if you want it

STRAX's AI features work with hosted providers or with fully local models via Ollama, so AI can run with no data leaving your network. Either way, the AI works inside limits that the server enforces:

  • Three assistant modes (Ask, Plan, Implement), each restricted by a server-side tool allowlist that no prompt can change.
  • Every proposed change passes the same validation gates as a human user and must be explicitly accepted; applied changes are audited.
  • AI endpoints are rate-limited, data exploration is sample-capped and time-boxed, and provider API keys are encrypted at rest.
Live Limits the server enforces Local models · enforced modes · gated changes
Local AI, if you want it The AI can run on a fully local model with zero data egress; its modes are enforced by a server-side allowlist, and every proposed change passes validation and human acceptance before it is applied and audited. Your choice of model hosted provider local: Ollama zero data leaves your network ✓ either way, provider keys sit encrypted in the vault Three modes, enforced Ask Plan Implement enforced by a server-side tool allowlist rate-limited; exploration sample-capped, time-boxed No silent changes AI proposes → same gates as a person you accept → applied → audited nothing lands without explicit acceptance The question boards ask "Can we use AI on company data without it leaving the building?" yes, locally ✓ Audit sees the AI too applied change · proposed-by: assistant the same chain and attribution Run the AI fully local, with zero egress. Modes are enforced by the server. Proposed, checked, accepted by you, audited.
Hosted or fully local via Ollama, and either way the AI works inside enforced modes, validation checks, human acceptance and audit.

Security is never licence-gated

Sign-in, role-based access, user management, MFA, TLS, the secrets vault and the licence screen are not licensable features. They are always on, at every edition, and an expired licence never downgrades your security posture.

Live Always on Security at every edition, licensed or not
Security is never licence-gated The licence card flips to expired while every security control (sign-in, roles, MFA, TLS, the secrets vault) stays switched on and green. The licence Enterprise · active expired 3 days ago features pause, and nothing is deleted, corrupted or locked away. The security posture, unchanged Sign-in & password policy Role-based access (4 tiers) MFA + recovery codes TLS Secrets vault (AES-256-GCM) User management & licence screen always on, never licence-gated ✓ The licence expires and security stays on. Always on, at every edition.
An expired licence never downgrades your security posture: sign-in, roles, MFA, TLS and the vault are always on.

POPIA and GDPR posture

STRAX is built to make compliance practical rather than to claim it for you. Because the platform is self-hosted, personal data stays on your infrastructure under your governance. We are not a cloud service holding your records.

The audit trail, role-based access control, encrypted secrets and retention-by-archive give your compliance programme the controls it needs, and the local AI option means even AI-assisted work can be done with zero data egress. We make no certification claims; if you are evaluating STRAX, ask us for the security overview and put your questionnaire to us.

Live Practical compliance Your governance · real controls · honest claims
POPIA and GDPR posture Personal data stays on your infrastructure under your governance; the audit trail, roles, encrypted secrets and retention-by-archive check off as the controls a compliance programme needs — with no certification claims. Where the personal data lives customer records · staff data · history on your infrastructure, under your governance ✓ self-hosted, so we are not a cloud service holding your records local AI option → even AI work, zero egress What your programme gets tamper-evident audit trail role-based access control encrypted secrets retention by archive, never deletion Honestly stated No certification claims that we have not earned. bring your questionnaire and we answer it directly ask us anything ✓ The controls exist, the evidence exports, and the data never left your servers. audit exports with hashes feed your DPO's tooling directly Personal data stays under your governance. Real controls, honestly stated.
Self-hosted data under your governance, the controls your compliance programme needs, and no certification claims we have not earned.

See it on your own systems.

Bring your security questionnaire. A demo takes an hour, on your data landscape rather than ours, and a person replies within one business day.

Request a demo → Explore the features