Security is a shared boundary

Keel protects the app. You protect the host.

Keel includes application controls for authentication, authorization, browser hardening, and backups. A self-hosted deployment is still only as private as its machine, network, HTTPS configuration, updates, and recovery plan.

Private vulnerability reportsSecurity keys supportedNo analytics scripts
Authentication

Password, optional Google, and WebAuthn

Use strong passwords, enable security-key second factor, and register a spare key. Google OAuth is optional and must use the exact deployed callback URL.

Authorization

Owner, workspace roles, and allowlists

The instance owner controls server-wide settings. Workspace roles govern content. Public deployments should set an email allowlist and disable sign-ups in environment configuration.

Browser boundary

Strict policy and private responses

Keel sends a content security policy, framing protections, no-sniff rules, limited browser permissions, and private or no-store caching for user-specific routes.

Recovery

Encrypted snapshots when configured

Set a backup passphrase, keep it outside the Keel host, store a copy off-machine, and prove that a separate install can restore it.

Before exposing Keel

Make the safe state the first state.

Do not publish an open registration page and promise to lock it down later. Configure the intended owner and allowed accounts before the first public request reaches the server.

Public server checklist
01

Require HTTPS

Use localhost for local work or a real HTTPS origin for network use. WebAuthn and secure session cookies depend on it.

02

Restrict access

Set the owner email, allowed emails, and disabled sign-ups in the environment. Treat those settings as deployment secrets and policy.

03

Trust proxies explicitly

Enable proxy trust only when a reverse proxy you control sets the forwarding headers. Incorrect trust can defeat per-address limits.

04

Patch and restore

Watch releases, update dependencies and hosts, and test recovery. A passing health endpoint is not a recovery plan.

What Keel does not claim

  • The live SQLite or PostgreSQL database is not end-to-end or application-encrypted.
  • A cloud backup provider cannot protect a weak or lost Keel backup passphrase for you.
  • Tailscale or a reverse proxy does not make an unpatched host safe.
  • Application tests and dependency audits do not prove that every future vulnerability is absent.
  • Keel is not a high-availability multi-tenant service. SQLite deployments should run one app replica.

Report a vulnerability privately

Use GitHub private vulnerability reporting. Include the affected version, deployment type, reproduction steps, impact, and a safe proof of concept. Never attach real notes, passwords, tokens, passphrases, databases, or private deployment addresses.

Do not open a public issue with exploit details. You should receive an acknowledgement within seven days. Fix and disclosure timing depend on severity and reproducibility.

Operator checklist

  1. Install the latest Keel release from the official repository.
  2. Use HTTPS or keep the service on localhost.
  3. Set the instance owner before first registration on shared infrastructure.
  4. Allowlist intended accounts and disable sign-ups before public exposure.
  5. Use full-disk or volume encryption when the host storage needs protection at rest.
  6. Create an encrypted backup, store a copy elsewhere, and test a restore.
  7. Review logs and audit events after configuration changes and updates.