OctopusOctopus/Docs
Get Started
Security

Security Overview

Last updated: May 2026

1. Data flow at a glance

Octopus reviews pull requests in five stages. Each stage runs inside the customer's VPC tenancy (hosted Octopus) or the customer's own infrastructure (self-hosted Octopus).

  • Webhook — GitHub, GitLab, or Bitbucket POSTs a PR/MR event; we verify the HMAC signature before processing.
  • Clone — we clone the repository into a per-job temporary directory; never persisted beyond the job.
  • Index — file contents are chunked and embedded into Qdrant for vector search. Source files are not stored as plaintext outside the indexing window.
  • Review — relevant chunks plus the diff are sent to the configured LLM provider. Provider choice and BYOK key live on the organisation.
  • Comment — findings are posted as inline review comments on the PR/MR via the platform API.

2. Encryption

In transit

All HTTP traffic uses TLS 1.2 or higher. Webhook payloads, dashboard traffic, and LLM provider calls are all TLS-terminated either at the edge (hosted) or at the customer's reverse proxy (self-hosted).

At rest

  • PostgreSQL — full-disk encryption on the underlying volume.
  • Qdrant vector store — full-disk encryption on the underlying volume.
  • Object storage (S3 / R2) for org avatars and large review payloads — server-side encryption with provider-managed keys.
  • OAuth tokens for third-party integrations (Slack, Linear, Jira, GitLab) are stored encrypted at the row level using an AES-256 key derived from the application secret. See apps/web/lib/crypto.ts.

3. Secrets handling

BYOK API keys (Anthropic / OpenAI / Google / Cohere / Grok / OpenRouter / ACPX / OpenCode) are stored as nullable columns on the Organization row, accessible only through the AI router on the server. They are never returned over the API, never logged, and never sent to the LLM provider as anything other than an HTTP Authorization header on the request that uses them.

The platform's own API keys (when not using BYOK) live in environment variables and are accessed only by the API routes that need them. The hosted dashboard never receives them; the self-hosted dashboard accesses them through the same server-side router.

4. Access controls

  • Authentication — Better Auth with GitHub OAuth, Google OAuth, Microsoft / Entra ID OAuth, and magic-link email. Passwords are not used; we have no password store.
  • Session management — short-lived bearer tokens with refresh; sessions revocable from /settings/sessions.
  • Role-based access — per-organisation roles (owner / admin / member); the audit log records role transitions.
  • CLI tokens — issued via the device-code flow, scoped to one organisation, revocable per-token.
  • Webhook secrets — set per-organisation; HMAC verification on every inbound payload.

5. Audit logging

Mutating actions are recorded in the AuditLog table (org membership changes, settings edits, integration installs and revocations, API token creation/deletion, knowledge document changes, billing actions, …). Each entry records the actor, the targeted resource, the operation, the IP and user-agent, and a JSON metadata blob.

Org admins can view and export their audit log from /settings/audit-log. Hosted Octopus retains audit entries for 365 days by default; self-hosters can configure this per their compliance requirements.

6. Network egress

Octopus makes outbound calls to:

  • The configured LLM provider for each org (Anthropic / OpenAI / Google / etc.)
  • The git platform API (GitHub / GitLab / Bitbucket) for clone, comment, and webhook acknowledgement
  • Integration webhooks if configured (Slack / Linear / Jira)
  • Email provider (Resend) for notifications
  • OAuth providers during sign-in (GitHub / Google / Microsoft) — Microsoft Graph is contacted during Microsoft sign-in when configured

See the sub-processors page for the full vendor list.

7. Incident response

On confirming a security incident, we follow this sequence:

  • Contain — disable the affected component or revoke the affected credential within 1 hour of confirmation.
  • Investigate — preserve logs, identify scope, identify affected customers.
  • Notify — email affected customers within 72 hours of confirming impact, with the facts known at the time.
  • Remediate — ship the fix, update documentation, update the changelog.
  • Post-mortem — publish a public post-mortem within 30 days for incidents with customer impact.

8. Related