Deploy and Host Cognee on Railway

Cognee is an open source memory engine for AI agents. It turns documents, chats and application data into a knowledge graph plus vector embeddings, then lets agents remember, recall and forget through a REST API, the Python SDK or an MCP client. This template deploys the official Cognee API with PostgreSQL and pgvector, protected by a small gateway so the instance cannot be claimed by strangers.

About Hosting Cognee

Hosting Cognee means running the FastAPI server next to three kinds of storage: a relational database for users, API keys and datasets, a vector store for embeddings, and a graph store for entities and relationships. This template follows the production layout from the Cognee deployment docs: PostgreSQL holds the relational tables and pgvector embeddings (one database per dataset), while the embedded Ladybug (Kuzu) graph and your original documents live on a persistent volume attached to the Cognee service. Multi user mode is on, so every endpoint needs a login token or an API key and each user's datasets stay isolated. Cognee cannot switch off its open signup endpoint, so the API has no public domain: a Caddy gateway is the public entrypoint and answers signup requests with 403.

Common Use Cases

Long term agent memory: store conversations, notes and documents, then recall them by meaning and by relationship
Knowledge graph RAG: cognify extracts entities and relations; GRAPH_COMPLETION search answers from the graph
Shared team memory: one Cognee backend used by several agents, apps and MCP clients through API keys
Coding assistants: point Claude Code or Cursor at this instance through a locally run cognee MCP server
Per user isolation: every user gets separate datasets and databases

Dependencies for Cognee Hosting

PostgreSQL with pgvector (included, pgvector/pgvector:pg17)
OpenAI API key (required; used for extraction, answers and text-embedding-3-large embeddings)
Caddy gateway (included, caddy:2.11-alpine)
Other LLM providers (optional; Anthropic, Gemini, OpenRouter or Ollama for the LLM while embeddings stay on OpenAI)

Deployment Dependencies

Implementation Details

The Cognee service runs the pinned cognee/cognee:1.6.2 image. Its start command waits for Postgres, then runs the image entrypoint, which applies migrations and starts gunicorn on a dual stack socket so the gateway can reach it over private networking. The admin account is created on first boot from generated credentials, token secrets are generated, API keys are stored hashed, server side file paths and raw Cypher queries are disabled, following upstream's recommended production settings.

OPENAI_API_KEY=
LLM_API_KEY=${{OPENAI_API_KEY}}
EMBEDDING_API_KEY=${{OPENAI_API_KEY}}
DEFAULT_USER_EMAIL=default_user@example.com
DEFAULT_USER_PASSWORD=${{secret(32)}}
FASTAPI_USERS_JWT_SECRET=${{secret(64)}}
DB_PROVIDER=postgres
VECTOR_DB_PROVIDER=pgvector
ENABLE_BACKEND_ACCESS_CONTROL=true
ALLOW_SIGNUP=false

After deploy, copy DEFAULT_USER_PASSWORD from the Cognee service variables and log in at POST /api/v1/auth/login on the gateway URL (username default_user@example.com). Create an API key with POST /api/v1/auth/api-keys and send it as the X-Api-Key header. Add data with POST /api/v1/add, build the graph with POST /api/v1/cognify and query it with POST /api/v1/search. Interactive API docs are at /docs on the gateway URL. To let teammates create accounts, set ALLOW_SIGNUP=true on the gateway for a moment, then set it back.

Why Deploy Cognee on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Cognee on Railway, you get the memory API, pgvector database and authenticated gateway wired together with generated secrets, health checks, persistent volumes, managed SSL and private networking to the rest of your project.