Built secure by default.
Configurable to your risk level.

No. The step that makes your documents searchable — turning text into "embeddings" (vectors) — is the part competitors typically outsource to a third-party AI API, which means your file contents leave their building. ReefOffice runs that model locally: bge-m3 (a multilingual, MIT-licensed open model) in Ollama on your own VM. The vectors and text are stored in Qdrant, also on your VM. So indexing and searching your corpus never make an outbound AI call — your document contents stay on your server. On Private AI plans the answer is generated by an open-weights model (Qwen by default, or a European model like Mistral) on a ReefOffice GPU in an ISO 27001-compliant data center in Germany, under a data-processing agreement — only your question and the matching snippets are sent to it, nothing is stored there, and no third-party AI is ever involved. The only case anything leaves is if you deliberately connect your own external AI key on a no-GPU plan for written answers — and even then only your question plus the few matching snippets are sent, never the whole corpus.

The pre-built automations (document indexing, invoice follow-up, contract filing, deal-won setup, …) run in an operator-only automation runtime that ReefOffice manages — not in Activepieces, the no-code builder your team uses. The credentials they need (your Nextcloud / Dolibarr / Paperless admin accounts, the mail relay) are stored encrypted and read only by the running job through job-scoped runtime credentials; they are never written into any workflow definition a user can open. When the private AI agent triggers one of the approved automations, it calls a local allow-listed shim that injects the credentials server-side, so the agent never receives general automation-engine credentials. Your Activepieces sandbox contains zero operator credentials, and runtime access is enforced operator-only on every deployment, so a stale account cannot linger with access. This closes the class of risk where a built-in automation becomes a way to read out an admin password.

Correct, and that is by design — LUKS is the right tool for disk-at-rest threats (physical drives, decommissioning, and snapshots that do not include boot unlock material). For a running server we apply a separate layer of controls baked into every NixOS build: ptrace is restricted (scope=3) to prevent process inspection, kexec is disabled so the kernel cannot be replaced at runtime, unprivileged eBPF is blocked, kernel pointers are hidden (kptr_restrict=2), unprivileged userfaultfd is disabled, unprivileged io_uring creation is restricted, and coredumps are suppressed. Full io_uring disable remains available for special hardened deployments, but the default keeps privileged infrastructure compatibility. NixOS immutability means no package manager can silently install unexpected binaries. Daily CVE scanning (vulnix) detects vulnerable packages and reports results in the dashboard.

Yes — every server runs a daily CVE scan using vulnix, a NixOS-native tool. Because NixOS pins exact package versions as cryptographic hashes (reproducible builds), vulnix can cross-reference every installed package against the National Vulnerability Database in seconds. Results appear in your dashboard Security tab with the package name, version, and CVE IDs. NixOS typically delivers a patched package within 24–48 hours of a CVE disclosure — the next daily scan confirms the fix. This is something most self-hosted stacks cannot do without significant tooling; here it runs out of the box.

Air-gapped mode is the complete answer — we hold no SSH key, so a full compromise of our infrastructure has no SSH path to your VM. In Managed mode, the hash-chained audit trail records control-plane operations. In addition, you can enable the optional weekly digest email from your account settings: it summarises service toggles, NixOS update outcomes, and CVE counts across your servers — giving you a regular, expected, easy-to-read confirmation that nothing unexpected happened. Any anomaly in that digest is an early signal to review the full audit log.

LUKS protects the encrypted root filesystem if someone gets access to a removed root disk or a root-disk snapshot without the boot unlock material. ReefOffice uses unattended LUKS so servers can reboot automatically, which means the boot partition and initrd are a separate part of the threat model. A complete provider-level image of both boot and root storage is not the same as a removed encrypted root disk. The remaining running-VM paths, such as hypervisor-level memory or runtime access, are governed by provider controls, contracts, and audits rather than LUKS.

An attacker would need to compromise the running VM, or obtain enough boot material and disk access to unlock the encrypted root filesystem, then read /etc/reefoffice/secrets.env. The backup key is never in the ReefOffice control-plane database. If your compliance requirement is that the backup key must be unreachable under any VM-level compromise, Zero-knowledge mode removes ReefOffice backup-key custody after handoff.

On the first SSH connection after provisioning, the control plane records the VM's public host key (Trust On First Use — TOFU). Every subsequent connection verifies the key matches that record. A mismatch — indicating the VM was replaced or a MITM was inserted — causes the connection to fail immediately and is written to the audit log. This means a rogue VM cannot silently intercept management traffic even if DNS or IP routing is compromised.

Your server runs on Contabo GmbH, a German hosting company founded in 2003 with its own data centers in Munich and Nuremberg — not a reseller. Contabo serves 225,000+ customers in 190 countries on more than 450,000 servers, and independent monitoring by HOSTtest recorded 100% uptime for Q3 2025 and Q4 2024. Contabo is a registered German company (Amtsgericht München, HRB 180722).