Configuration¶
This page shows the Chroma files and the settings first boot locks in. The launcher rejects a changed listener instead of opening another address.
Where things live¶
| Path | What it is |
|---|---|
/etc/chroma/config.yaml |
Generated server configuration. |
/var/lib/chroma |
Persistent collections. |
127.0.0.1:8000 |
JSON API. No browser UI. |
~/chroma-results/ |
Manifests and demo output. |
/opt/sushi/docs/demo.sh |
Sample collection walkthrough. |
/opt/chroma |
Source inputs shipped with the package. |
/usr/share/doc/chroma |
Delivered notices. |
/opt/sushi/evidence |
Installed inventory. |
Services involved at startup are chroma, sushi-chroma-firstboot, and
sushi-chroma-ready.
Settings that stay as shipped¶
The generated configuration:
- listens on loopback only
- disables reset
- leaves CORS origins empty
- bounds requests at 1 MiB
- disables telemetry export
First boot creates storage once and keeps the instance identity. The launcher rejects a changed listener configuration. Leave the listen address as it is so the service still starts.
Send embeddings in each API request. Enabling a default embedding function changes the download and runtime requirements. This package does not download an embedding model for you.
Credentials¶
There is no application token and no password file. The published guide says
the upstream server in this build does not implement application
authentication, and that legacy CHROMA_SERVER_AUTHN variables do not
protect it.
Control access with the instance login and the tunnel. Every local user on the instance can call the API. Keep forwarded ports off networks you do not trust.
Clients¶
Use a Session Manager port forward or an SSH tunnel to port 8000. Your client
talks to that local forward and supplies the vectors. The health of a stored
demo collection is sushi-chroma read against its manifest, which is
read-only.
Last updated October 27, 2026 · Suggest an improvement