Sajel · Everything, recorded.

Security & data protection

How Sajel keeps your organization's data isolated, access-controlled, and auditable.

Our approach

Sajel is built for organizations that need to trust where their data lives and who can touch it. This page describes the protections that are actually built into the product today, in plain language. We deliberately do not list controls we haven't shipped: anything still on the roadmap is called out at the bottom.

Sajel is self-hosted: your organization runs its own instance, so your data stays on infrastructure you control (on-premises or your own cloud, in your own region).

For a technical, code-level version of everything here (with file references a security reviewer can verify), see the SECURITY.md file in the product repository.

Last reviewed against the running code: July 2026.

Your data is isolated

Everything in Sajel lives inside a hierarchy: Company, then Workspace, Base, Board, and Record. Every request is checked against that whole chain on the server. A record is verified to belong to its board, the board to its base, the base to its workspace, and the workspace to you.

The practical result: a person in one workspace cannot reach another workspace's data by guessing or tampering with IDs. The server rejects it. Isolation does not rely on IDs being hard to guess.

Who can see and do what

Access is role-based, with three roles plus an explicit "no access" that overrides everything below it:

Role	What they can do
Owner	Full control of the workspace and its members
Editor	Create and edit records and views
Viewer	Read-only access

Roles can be granted to a person directly or to a group, and they inherit down the hierarchy (a role at the workspace applies to its bases and boards unless overridden).

Beyond roles, admins can set:

•Row-level rules so a person only sees the records that belong to them (for example, "members see only rows they own"). These are enforced on every read and write, not just lists.

•Field-level rules so sensitive columns (like Salary) are hidden or locked for certain roles or groups. Hidden fields are stripped on the server before the data ever reaches the browser.

Full permissions guide

Signing in

•Passwords are stored only as bcrypt hashes, never in plain text, and are never returned by the API.

•Sign-in is rate-limited, and after repeated failed attempts an account is temporarily locked, which blunts password-guessing attacks.

•Password reset links are single-use and expire quickly; asking to reset an unknown email reveals nothing about whether that account exists.

Two-factor authentication (2FA)

You can turn on app-based two-factor authentication (TOTP, the standard used by Google Authenticator, 1Password, Authy, and others) from Settings > Security. When it's on, signing in requires a code from your authenticator in addition to your password.

Backup codes

When you enable 2FA you get one-time backup codes to use if you lose your device. Keep them somewhere safe.

Disabling 2FA requires re-entering your password, so a hijacked session can't quietly turn it off.

Sessions and signing out

Signing out actually invalidates your session on the server, not just in your browser. You can also sign out everywhere at once.

Changing your password signs out your other devices automatically while keeping your current one active. Resetting a forgotten password signs out every session, in case the account was compromised.

Audit trail

Sajel records who did what and when: record changes, structural changes, and membership changes, each with before/after detail, the user, time, and IP.

Audit entries cannot be edited or deleted after they're written. This is enforced by the database itself, so even a software bug or a direct database write cannot rewrite history. Workspace admins can review the trail, filtered by user, date, and event type.

The one exception to "cannot be deleted" is the retention sweep: if your operator configures a retention window, entries older than it are purged in bulk. By default nothing is deleted: history is kept until you choose a retention policy.

Getting your data out

Your data is yours. Any board can be exported to CSV (the "Export this board as CSV" command, or via the command menu). The export respects your access: you get exactly the rows and columns you're allowed to see, nothing more.

Encryption and hosting

•In transit: connections are served over HTTPS/TLS at your deployment's gateway.

•At rest: enable encryption on your database and disk (standard for managed Postgres and most hosting). Sajel relies on that layer for at-rest encryption rather than re-implementing it in the app; passwords are additionally bcrypt-hashed.

•Outbound calls (webhooks and automations) are blocked from reaching internal or cloud-metadata addresses, which prevents a class of server-side request attacks.

•File uploads are type- and size-limited, stored under tenant-scoped keys, and only downloadable by people with access to the owning board.

Because Sajel is self-hosted, data residency is straightforward: run the instance in the country or cloud you require. There is no third-party data egress by default.

What's on the roadmap (not yet built)

We're explicit about what isn't built yet so you can assess fit honestly:

•Single sign-on (SAML / OIDC).

•Application-layer (field-level) encryption of personal data, beyond database-level at-rest encryption.

•A recoverable "trash" / grace period before permanent deletion.

•A self-service view of your active devices and login history.

•Automated retention for general (non-audit) data.

If your organization requires one of these, it's something we build to order.

Reporting a security issue

If you believe you've found a vulnerability, please report it privately rather than opening a public issue. Include what you found, how to reproduce it, and the potential impact. We aim to acknowledge within one business day.