Operations¶
This page covers the Chroma service, backups, moving to another image, and support.
Security model¶
- Loopback API. Chroma listens on
127.0.0.1:8000. - No application authentication. The instance login and the tunnel are the access control. Local users can call the API.
- Service account. The server runs as
chroma. - Identity preserved. First boot creates storage once. Do not delete
/var/lib/chromaor/etc/chromato repair a failed start.
Service¶
sudo systemctl status chroma sushi-chroma-firstboot sushi-chroma-ready
sudo journalctl -u chroma --since '10 minutes ago'
sudo systemctl restart chroma
After a restart, run the read-only manifest check from Getting started before you write new data.
Backups¶
Stop chroma so the copy is consistent. Back up /var/lib/chroma and
/etc/chroma together. Write the archive with mode 0600 and store it where
only your operators can read it.
Restore the complete set onto the same application version, with the service stopped. Preserve numeric ownership and modes. Query the saved manifest before you allow writes.
A single disk is the whole database. Take the backup before you rely on the instance.
Updates¶
A new Marketplace version is a new instance. Restore /var/lib/chroma and
/etc/chroma together onto that same application version, start the service,
and run sushi-chroma read on a saved manifest. Keep the archive until that
read succeeds.
Do not delete storage as a repair, and do not change the listener to make the new instance reachable. Use a tunnel.
Support¶
Email info@softwaresushi.com with the Marketplace version, the Region, and the error. The software rate on the listing is USD 0.03 per running instance-hour. EC2, EBS, and data transfer are separate.
The Chroma documentation
describes the upstream project. Notices for this build are under
/opt/chroma and /usr/share/doc/chroma.
Last updated October 27, 2026 · Suggest an improvement