Chroma Vector Database

Chroma 1.5.9 runs one persistent vector database on 127.0.0.1:8000 as the chroma service account. The endpoint is a JSON API; there is no bundled browser UI. Start with a t3.medium, 4 GiB RAM and 32 GiB storage. Software is USD 0.03 per running instance-hour; EC2, EBS and transfer cost extra.

After launch, connect through Session Manager or SSH as ubuntu and run:

sudo -iu ubuntu bash /opt/sushi/docs/demo.sh

The demo creates one collection and writes three explicit two-dimensional vectors, documents and metadata. A separate HTTP reader checks the stored vectors/count and queries [0.95, 0.05]; the expected nearest ID is alpha with squared L2 distance 0.005. Results live under ~/chroma-results/. No embedding model is downloaded or called.

Keep the printed manifest and repeat its read-only checks after a service restart or full reboot:

sushi-chroma read ~/chroma-results/RESULT-DIRECTORY/manifest.json

Applications can reach the API through an authenticated SSH or Session Manager forward to this instance's 127.0.0.1:8000. No inbound database rule is needed. The selected upstream server does not implement application authentication; access is controlled by the tunnel and instance login. Local instance users can reach the API. Do not forward it onto an untrusted network or claim that legacy CHROMA_SERVER_AUTHN variables protect it. Always supply your embeddings in API requests; enabling a default embedding function changes the download/runtime requirements.

The generated configuration is /etc/chroma/config.yaml; data is in /var/lib/chroma. Reset is disabled, CORS origins are empty, requests are bounded to 1 MiB, telemetry export is disabled and the service network is restricted to loopback. First boot creates storage once and preserves the instance identity. The launcher rejects a changed listener configuration instead of opening a network endpoint unexpectedly.

sudo systemctl status chroma sushi-chroma-firstboot sushi-chroma-ready
sudo journalctl -u chroma --since '10 minutes ago'
sudo systemctl restart chroma

If startup fails, preserve data and the reported error. Do not delete storage as a repair. Back up /var/lib/chroma and /etc/chroma together with the service stopped, using a mode-0600 archive in protected storage. Restore the complete set to the same application version with the service stopped, preserving numeric ownership and modes, then independently query the saved manifest before allowing writes. Source inputs and delivered notices are under /opt/chroma and /usr/share/doc/chroma; installed inventory is under /opt/sushi/evidence.