Security
Oleafly Server security
Oleafly Server is the self-hosted collaboration server for the Oleafly desktop app. Before researchers at a national lab or a university can use it, their IT or security team usually has to review it. This page is written for that team. It covers what the server does today and what is planned for regulated deployments.
This page covers the server. For the desktop app on its own, read the privacy page.
In place today
What the server does now
Self-hosted
Your organization runs the server on its own machines or in its own cloud account, with Docker, Coolify, Render or Railway, or as a plain Linux service. Project files and the database stay there. Files can be stored on disk or in any S3-compatible store.
No outside calls
The server makes no outside network calls, except to the sign-in provider your organization sets up.
Your identity provider
People sign in with your organization's OpenID Connect identity provider. They can also use GitHub or a link sent by email, and devices whose browser can't return to the app can use a sign-in code.
Admins decide who joins
Admins control who can join with an allowed list and domain rules, and give each person a role: admin, maintainer, member or guest. Guests see only the projects they are invited to, with admin approval if you want it.
Device keys
Every device has its own key, and sessions are bound to it, so a copied token is useless without that key. Refresh tokens are single use, and the server detects reuse. Signing a device out takes effect at once, even on connections that are already open.
Signed changes
The device that makes a change signs it. The server checks that each editing identity belongs to the device that signed the change, and checks comment authors the same way. It builds project snapshots itself from the signed change log instead of trusting uploads.
Security and access logs
A security log records sign-ins, refused sign-ins, admin actions and device changes, each with the client address. Project owners can also keep an access log of who opened their project.
Container image and SBOM
Each release ships a small container image with no shell, a software bill of materials (SBOM) and build provenance.
Independent reviews
Independent reviewers checked the server's security, performance and scalability. Their findings were fixed, and the fixes have tests.
Planned
Planned for regulated deployments
Some deployments need more than the server does today. Nothing in this section is available yet. If your review depends on one of these items, tell us when you get in touch. It helps us decide what to build first.
FIPS mode
In FIPS mode, TLS and signatures will use a FIPS 140-validated cryptographic module.
Encrypted projects
Project content will be encrypted on members' devices. The server will relay sealed changes and won't be able to read text, comments or files. Keys will rotate whenever someone is removed.
Stronger admin checks
Sensitive admin actions will ask for Touch ID, Windows Hello or a fresh sign-in first. Device keys will be kept in the Secure Enclave or a TPM. Every admin will get an email when roles or settings change, and you'll be able to set session and idle policies.
Audit export
The security and access logs will stream to your SIEM as syslog or JSON, with retention settings and legal hold.
Encryption at rest
The database and stored files will be encrypted with keys from your organization's key management service.
SCIM provisioning
Members will be provisioned from your identity provider through SCIM.
Installs without internet
There will be documented steps for installing the server on a network with no internet access.
Security documentation
We will publish a threat model, a hardening guide, a shared responsibility matrix and a vulnerability disclosure process for the server, and a third party will run a penetration test.
Get in touch
Ask for a security review or a pilot
If your team is reviewing Oleafly Server or wants to run a pilot, start a thread in GitHub Discussions. Say what your review needs, including anything from the planned list.
Found a vulnerability? Don't post it in public. Report it privately on GitHub, as the security policy explains.