Frequently Asked
Questions

Yes. Your API key is stored exclusively in server process RAM — it is never written to disk, logged to any file, inserted into a database, or transmitted to any third party beyond the LLM provider you selected.

When the server restarts, all in-memory configuration is cleared and you will be prompted to re-enter your key. The source code is open and auditable — you can verify this yourself in backend/agent.py and backend/main.py.

Use the Integration Hub (click "Integrate" in the nav) to get ready-to-paste snippets for your stack. Kairos accepts logs via:

• HTTP API — POST /ingest with JSON payload from any service
• Python logging handler — drop-in replacement for your existing handler
• Logstash — HTTP output plugin pointing to Kairos
• Fluent Bit — HTTP output pointing to /ingest

Each source produces the same result: a real-time RCA on the Cockpit dashboard within seconds of ingestion.

Choose based on your priorities:

• Ollama (local) — completely private, free, no API key. Response time ~20-40s depending on your hardware. Best for sensitive environments.
• Groq — free tier with generous limits, ~1-2s responses using open-weight models. Best balance of speed and cost for most teams.
• OpenAI GPT-4o — highest accuracy on complex multi-service incidents. Best overall quality if cost is not a concern.
• Anthropic Claude — best multi-step reasoning and instruction-following. Excellent for nuanced RCAs with long log contexts.

Kairos is a single-tenant tool — it is designed for a team or an owner running their own deployment. There is one active LLM configuration at a time, shared across all users connected to that instance.

Concurrent log ingestion is supported; the backend queues analysis jobs. However, simultaneous LLM config changes from different users will overwrite each other. The recommended pattern is one Kairos instance per team, with one person managing the LLM settings.

On restart, all in-memory state is cleared:

• LLM configuration — cleared. Re-enter your provider and API key via Settings.
• Active incident state — cleared. Any in-progress RCA is lost.
• Redis cache — persists across restarts (separate process). Recent RCAs and vector embeddings survive.
• ChromaDB vector store — persists (stored on disk). Historical log embeddings are retained.

For production deployments, set your LLM config via environment variables (LLM_PROVIDER, GROQ_API_KEY, etc.) so the server auto-configures on startup without manual intervention.

Three deployment paths are supported:

• Railway — one-click deploy via railway.json. Set env vars in the Railway dashboard. Cheapest managed option.
• Docker Compose — run docker-compose up -d on any Linux VM. All services (FastAPI, Next.js, Redis, ChromaDB) start together.
• Manual — run the FastAPI backend and Next.js frontend separately. Useful for custom infra or Kubernetes.

Environment variables are the primary configuration method for production. See .env.railway.template for a complete list of supported variables including LLM provider, API keys, and service URLs.