Skip to main content
A self-hosted Cymph deployment is a single Docker Compose project named cymph. Everything it needs runs on one host — there are no external dependencies apart from the integrations you configure and, optionally, an AI provider.

​
Services

ui, api and db each declare a healthcheck, and Compose starts them in dependency order — db before api, api before ui, ui before nginx. Users reach the deployment through nginx, on the address and port you choose during installation. Uploads are capped at 20MB.
ui, api, embedding-api and db are reachable only on the internal Docker network — none of them is published on the host. The single published port is nginx’s, which means every request reaching the application has passed through TLS termination. See Networking.

​
Data and volumes

Four Docker volumes hold everything that survives a container restart: These are what you snapshot — see Backup & restore.

​
Secrets generated at setup

env.sh generates the deployment’s secrets on first run and writes them to .env and db/secrets.txt:
  • NEXTAUTH_SECRET / CYMPH_AUTH_SECRET — session token signing
  • CYMPH_SESSION_SECRET — session state
  • CYMPH_ENCRYPTION_KEY and CYMPH_ENCRYPTION_IV — encryption of sensitive integration data at rest
  • A Fernet key in db/secrets.txt, passed to the database container as a Compose secret
These values are generated once and are not recoverable. If you lose .env or db/secrets.txt, encrypted data in the database cannot be decrypted — back them up alongside the volumes.

​
Outbound connections

The api service makes outbound connections to the endpoints your integrations point at, and to your AI provider if you enable one. Search embeddings are computed locally by embedding-api, so no content leaves the deployment for search, and product analytics is disabled in the on-prem configuration (NEXT_PUBLIC_AMPLITUDE_ENABLED=false). See Networking for allowlisting, and AI & data usage for what an enabled AI provider receives.