Neuron can back a single shared knowledge graph that a small team (designed for up to ~6 people) writes into concurrently. Everyone points their Neuron at the same Turso Cloud database; saves are incremental and concurrency-safe, so people editing in parallel don't lose or overwrite each other's work.
Nothing about day-to-day use changes: a solo user and a team member run the same code. The only difference is the connection string.
Using the Turso CLI:
turso db create neuron-team
turso db show neuron-team --url # the shared DB URL — same for everyoneGive everyone the same DB URL, but have each person create their own auth token so tokens can be revoked individually:
turso db tokens create neuron-team # one per personThen each member, inside Neuron's venv:
pip install "neuron[cloud]" # adds libsql-client
python scripts/connect_turso.py # paste the shared URL + your own tokenconnect_turso.py runs a real read + write probe before saving anything, and saves the working
credentials to .env (the token is never printed). The server auto-loads .env at
startup, so from then on Neuron uses the shared DB automatically. Verify end-to-end:
python scripts/smoke_cloud.py # expects RESULT: PASSThe store is keyed by a context column, so multiple contexts coexist in the same tables
without colliding. You have two natural styles:
- One shared context (e.g. everything in
default) → a single unified picture of what the whole team knows. Simplest, and gives everyone the full view. - Separate contexts (e.g.
backend,frontend) → each area keeps its own graph, still in the same shared DB, with cross-context inheritance fromdefault.
Note: the
neuron_autopipeline can switch context automatically when it detects a different domain. That's fine — thecontextcolumn keeps those contexts from colliding on the shared DB — but it means "one context only" is a convention, not something the system enforces. Agree on the convention as a team.
- No lost updates on the same node. Salience is applied as an atomic relative delta
(
salience = MAX(0, salience + Δ)), so if two people both bumpspring(say +2 and +3), the DB ends at +5 — not last-write-wins. - No silent downgrades. Link weight only ever moves up (
tangential < medium < strong) under concurrent writes. - No one wipes anyone. A normal per-turn save writes only its own delta and never issues a blanket delete, so a member's save can't remove rows another member just wrote.
- Reconciliation is deliberate. The only save that deletes "rows no longer present in
memory" is a structural
neuron_merge(merging duplicate nodes). Treat merges — andneuron_reset— as intentional, coordinated operations, not routine ones, on a shared DB.
- The Turso token is the boundary. Neuron itself has no user-level auth: anyone with a
valid token can read and write the whole shared memory. Issue per-member tokens, and
revoke a token (
turso db tokens invalidate …/ rotate) when someone leaves. - Keep
.envprivate. It holds the token and is gitignored — never commit it. - Back up the shared DB periodically (
turso db shell … .dump, or Turso's backup features) before largemerge/resetoperations. - Scale. This is designed for a small trusted team (≤ ~6). Going bigger / public would want a service layer in front of the DB (conflict resolution, rate limiting, partitioning) — a deliberate future step, not built yet.
connect_turso.pyfails withWSServerHandshakeError: 400→ the tool auto-retries overhttps://and saves that; just re-run. If every scheme fails, the token is likely wrong, read-only, or issued for a different DB.- Server isn't using the cloud → confirm both
TURSO_DATABASE_URLandTURSO_AUTH_TOKENare present (a real env var wins over.env;NEURON_NO_DOTENV=1disables the auto-load), then runpython scripts/check_cloud_config.py(offline) orsmoke_cloud.py(online).