topoteretes/cognee · Archived

cognee-server

Use when the user wants to run the cognee API server (and optional UI) on their own machine — starting it, checking it's healthy, connecting the SDK or other clients to it, and choosing the right auth posture.

First seen Aug 18, 2026

Installation

$ npx skills add topoteretes/cognee --skill cognee-server

Stronger alternatives

This repository is archived — consider an actively maintained alternative.

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from topoteretes/cognee.

npx skills add topoteretes/cognee

Browse all from topoteretes/cognee

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 30.6K
License licenses
Default branch main
Open issues 219
Status Archived

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 2,823 B
  • docs SUMMARY.md 232 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 20 installs

SKILL.md

Start the cognee server locally

From an installed cognee (no Docker)

cognee-cli -ui

launches the full local stack: FastAPI backend on http://localhost:8000 and the UI on http://localhost:3000. Needs LLMAPIKEY in the environment or .env. The interactive API reference is at http://localhost:8000/docs, health at /health.

For API-only serving via Docker instead, use the cognee-docker skill (the prebuilt cognee/cognee:main image or docker compose up from the repo).

Auth posture

ENABLEBACKENDACCESS_CONTROL decides everything:

  • true (default): multi-tenant — auth required on every API call, per

user+dataset database isolation.

  • false: single-user local mode — no auth, shared local databases. Right

choice for a personal dev server; never for anything exposed.

REQUIREAUTHENTICATION=false is ignored while access control is on; to turn auth off you must set ENABLEBACKENDACCESSCONTROL=false.

Connecting clients to the running server

  • SDK / CLI against the server (instead of embedded local mode):

``bash cognee-cli serve --url http://localhost:8000 # local instance cognee-cli serve # cognee cloud (device flow) cognee-cli serve --logout # disconnect ``

In Python: await cognee.serve(url="http://localhost:8000";).

  • HTTP: main routes live under /api/v1/ — the memory API is remember

(plus remember/entry), recall, improve, forget; sessions covers session memory; datasets, users, visualize handle the rest. The legacy add, cognify, search, memify, and delete routes still exist and are what the memory routes call underneath (see cognee/api/client.py for the registered routers, or GET /openapi.json on a running server).

Note there is no /api/v1/feedback routefeedback exists as a CLI command and in the SDK, but is not exposed over HTTP.

Graph visualization without the full UI

from cognee.api.v1.visualize import visualization_server

shutdown = visualization_server(port=8080)  # synchronous; returns a shutdown callable

Troubleshooting

  • Port 8000 already taken → stop the other service or remap (compose:

"8080:8000").

  • 401/403 on every call → you're in multi-tenant mode; either authenticate or

set ENABLEBACKENDACCESS_CONTROL=false and restart.

  • recall/search returns [] instead of erroring → permission-filtered

result; check dataset access rights for the calling user.