External providers

Overlord is designed to run on your own infrastructure. This page summarizes the third-party services involved in each deployment mode and what data reaches them.

Authentication — better_auth

OpenOverlord handles authentication with the open-source better_auth library running on the same server as the rest of the backend. No user credentials, session tokens, or identity data are sent to a third-party auth service.

Three credential types are in use:

  • Browser sessions — short-lived session tokens issued to the web app, stored server-side
  • USER_TOKENs — long-lived bearer tokens (prefixed out_) created in Settings → Tokens; stored as SHA-256 hashes with no plaintext retained
  • Loopback trust — local CLI and runner requests from the same host are granted operator authority without a token (local/desktop deployments only)

Database

Local deployments store all mission data, objectives, sessions, and file-change records in a SQLite file on disk. Nothing leaves the machine.

Hosted deployments use Railway (PostgreSQL). The same data lives in a Railway-managed Postgres instance.

Storage — Railway (hosted)

Hosted deployments use Railway's managed storage for binary assets attached to missions. Local deployments read and write stored objects from the local filesystem only.

AI Summarization — Google Gemini

When Overlord generates feed summaries from mission activity, the automations service calls the Google Gemini API with structured context derived from the mission. That context can include mission fields, objectives, delivery summaries, change rationales, file-change metadata, and other text that agents or humans have written into the mission record.

Web (marketing site) — Vercel

The Overlord marketing site and documentation at ovld.ai are hosted on Vercel. This is a static Next.js build with no backend, no authentication, and no user data.

  • Vercel security — how Vercel secures its platform and customer workloads