Configure cognee through UI

[Vasilije1990]

📋 Summary

Add a configuration UI that allows users to set up Cognee's LLM, databases, and processing settings through a web interface instead of requiring code changes.

🎯 Acceptance Criteria

1. Configuration UI Page

Page should contain sections for each of the following:

• LLM Settings: Provider, model, endpoint, api key, api version.

• Vector Database: Provider selection (ChromaDB, PGVector, Qdrant) + connection settings (host, port, api key).

• Graph Database: Provider selection (Neo4j, Kuzu, FalkorDB) + connection settings (host, port, username, password).

• Processing: Chunk size, chunking strategy.

• System: Data and system directory paths (Changing this is a destructive operation, meaning that system and data files should be deleted from the old paths and recreated at new paths)

2. Backend API

We already have api/v1/settings GET and POST API routes that serve for getting and saving configurations.

• Adapt existing API routes and expand DTO objects to support all required configuration fields.
• Apply settings to active Cognee instance.

3. UI Features

• Validate settings on the backend and return meaningful error messages.

• Test connections to databases and llm

• Import/export configuration as JSON

• Reset to defaults button

[VinaySatrasala]

---

❓ Clarification Needed on Config UI Implementation

Hi @Vasilije1990 , I’m excited to pick this up — had a few clarifying questions before proceeding:

---

1. 🔁 Apply Settings to Active Instance

“Apply settings to active Cognee instance”

• Does this mean applying updates immediately to the running process (in-memory reconfiguration)?
• Or should they also be persisted (e.g., to a config file or database) for use on restart?

---

2. 📁 System Settings

“System: Data/system directory paths”

• Are these paths editable through the UI?
• Or are they intended to be set only once during installation/startup?

---

3. ✅ Validate Before Saving

“Validate configuration settings before saving”

• Is this referring only to basic field validation (required fields, format)?
• Or does it include live checks like pinging DBs, validating API keys, etc.?

Once I get a green light on these, I’ll be happy to scaffold the UI/API PR accordingly. Thanks! 🙌

---

[borisarzentar]

❓ Clarification Needed on Config UI Implementation

Hi @Vasilije1990 , I’m excited to pick this up — had a few clarifying questions before proceeding:

1. 🔁 Apply Settings to Active Instance

“Apply settings to active Cognee instance”

• Does this mean applying updates immediately to the running process (in-memory reconfiguration)?
• Or should they also be persisted (e.g., to a config file or database) for use on restart?

2. 📁 System Settings

“System: Data/system directory paths”

• Are these paths editable through the UI?
• Or are they intended to be set only once during installation/startup?

3. ✅ Validate Before Saving

“Validate configuration settings before saving”

• Is this referring only to basic field validation (required fields, format)?
• Or does it include live checks like pinging DBs, validating API keys, etc.?

Once I get a green light on these, I’ll be happy to scaffold the UI/API PR accordingly. Thanks! 🙌

Hi @VinaySatrasala, thanks for showing the interest!
To answer your questions:

1. Yes, that means in-memory reconfiguration. We don't want to persist it for now, because those contain sensitive information. Exporting and importing can help in case someone needs to restart cognee.
2. This is editable through the UI. Most of the people will probably set it once and forget. I've put more info in the description, this is a destructive operation, if you change these settings you risk of losing the data.
3. I wouldn't spend too much time on validation, except checking if the fields exist. We can have separate buttons that will trigger the connection testing, but we also need those endpoints then.

[VinaySatrasala]

Hi @Vasilije1990 👋, sorry to bother again — I had one more doubt regarding the configuration setup:

You mentioned that we already have api/v1/settings GET and POST endpoints, and we should extend the DTO to support all configuration fields. Just to clarify:

Would you prefer one consolidated API endpoint that handles the full configuration object (LLM, vector DB, graph DB, processing, and system settings all together)?
Or is it acceptable (or even preferred) to expose separate endpoints for each configuration section (e.g., /settings/llm, /settings/vector-db, etc.) for modularity and separation of concerns?

Happy to proceed either way — just wanted to align with your expectation before implementing. Thanks!

[borisarzentar]

Hi @Vasilije1990 👋, sorry to bother again — I had one more doubt regarding the configuration setup:

You mentioned that we already have api/v1/settings GET and POST endpoints, and we should extend the DTO to support all configuration fields. Just to clarify:

Would you prefer one consolidated API endpoint that handles the full configuration object (LLM, vector DB, graph DB, processing, and system settings all together)? Or is it acceptable (or even preferred) to expose separate endpoints for each configuration section (e.g., /settings/llm, /settings/vector-db, etc.) for modularity and separation of concerns?

Happy to proceed either way — just wanted to align with your expectation before implementing. Thanks!

@VinaySatrasala Separate API endpoints is also fine, you can go that way if you want.

[VinaySatrasala]

Thank you @borisarzentar

[Raj2604]

Hey I like to work on this iisue could you please assign it to me if it's not already done.

[VinaySatrasala]

@Raj2604 Hello Raj, Currently i am working on this issue.