You're hosting client data. Here's exactly how it's handled.
Opentra is self-hosted and single-tenant, so the security model is refreshingly simple: your data is on your infrastructure, under your controls. This page is written to be shared with your clients and their auditors.
Single-tenant, on your infrastructure
Opentra runs on a VM or box you control. There is no shared multi-tenant database — your clients’ records never sit next to another MSP’s. No vendor holds your book of business.
Your PostgreSQL, your backups
Data lives in a PostgreSQL database you own and can query directly. Back it up with the same tooling you already trust (pg_dump, volume snapshots); we document a recommended schedule rather than holding the only copy.
TLS in transit
The app is designed to sit behind your reverse proxy / Cloudflare with TLS terminated at the edge. All portal and API traffic is HTTPS; the client IP used for rate-limiting and audit trails is taken from the trusted proxy header, never the spoofable left-most X-Forwarded-For.
Encryption at rest
At-rest encryption is a property of the disk/volume you deploy on — because you own the host, you choose the standard (LUKS, cloud-provider volume encryption, etc.). Integration secrets are stored server-side and never exposed to the browser.
SSO via Microsoft Entra ID / Google
Staff sign in through NextAuth (Auth.js) against Microsoft Entra ID (primary) or Google — no separate password store to breach. Roles are enforced at the trust boundary on every mutation and data read, not just in the UI.
MFA through your identity provider
Opentra has no password store of its own, so multi-factor authentication is enforced by your identity provider. Turn on MFA / conditional access in Microsoft Entra ID or Google Workspace and every Opentra sign-in inherits it — including the phishing-resistant methods your tenant already mandates.
Token-based customer portals
Clients approve contracts and view project status through unguessable 122-bit UUID-v4 tokens that expire — no client logins to manage, no shared passwords. Approval actions capture IP + user-agent for an audit trail.
OAuth tokens for MS Graph & Xero
Microsoft 365 and Xero connect via OAuth; tokens are held server-side and refreshed automatically. Revoke access at any time from the provider — you are the tenant admin.
Hardened by default
Inbound email HTML is rendered only inside a sandboxed iframe (no script execution) to prevent stored XSS against staff sessions. Attachments outside a strict image allowlist are always served as downloads, and outbound tracking links are HMAC-signed and verified.
You control the update cadence
Updates ship as container images you pull on your schedule — a bad release can never be pushed to your production without you. Database migrations are versioned and run on deploy.
What if Opentra disappears?
Because you self-host, nothing stops. The software keeps running on your box and your data stays in your database. Self-hosting is the continuity plan: no vendor can hold you hostage or switch you off.
You are the controller — we are not a sub-processor
Because the software runs on your infrastructure and Opentra never receives your clients’ data, you are the data controller and the data processor. Opentra is software, not a sub-processor — there is no vendor sub-processor list to review and nothing for a SaaS PSA’s data-processing addendum to cover. A legal request for client data goes to you, under your own agreements, not to us.
What we log, and for how long
Portal approval actions (contracts, quotes, change requests) capture the actor’s IP and user-agent alongside a frozen snapshot of what was approved, kept for the life of the record as a tamper-evident audit trail. Application and access logs live on your host under your own retention policy — you decide how long they are kept, because they never leave your infrastructure.
Responsible disclosure
Found a vulnerability? Email security@opentra.net — the same address is published at /.well-known/security.txt. We aim to acknowledge reports quickly, and because you run your own instance you can apply a fix on your own schedule as soon as it ships.
You own the database, so backups are yours to run — and they should be. Here's a nightly
compressed dump with 14-day retention you can drop straight into cron; point it at
wherever your host keeps snapshots. Restore is a plain gunzip | psql.
# /etc/cron.d/opentra-backup — nightly encrypted-at-rest dump, 14-day retention
0 2 * * * root pg_dump "$DATABASE_URL" | gzip > /backups/opentra-$(date +\%F).sql.gz \
&& find /backups -name 'opentra-*.sql.gz' -mtime +14 -deleteDoing a vendor assessment?
Send us the questionnaire. Because you host it yourself, most rows answer themselves — and we'll help you fill in the rest for your clients.
Talk to us about security →