Chroma Cloud sets shutdown dates under Replit agreement
Chroma Cloud will stop writes on November 22, 2026, and reads on December 22. Chroma announced the service closure alongside a definitive agreement to join Replit. Open source ChromaDB continues.
An application may still retrieve old records after it loses the ability to ingest new information. Plan write cutover separately from final export.
What the agreement changes
In its October 23 announcement, Chroma says its database and Foundation work will continue at Replit, with enterprise context as the shared focus. It also says more code from private repositories has moved into the Apache 2.0 project and that Replit will continue contributing. The announcement describes a signed agreement, not a separately confirmed closing. It does not disclose a purchase price.
Two dates to put in the migration plan
The official service notice says November 22 ends creation, updates and deletion of Cloud data. Existing records remain readable for the next 30 days. December 22 ends those reads too. Customers should finish exports, validate their replacement and remove or rotate old Cloud credentials before the final cutoff.
No cutoff hour or timezone is stated, so finish ahead of those dates. The closure concerns the existing Cloud service, not locally operated Chroma installations.
Start with an inventory rather than a new database
Chroma’s collection documentation provides the building blocks for an inventory. Collections carry names, metadata, configuration and embedding function information. Listing returns up to 100 collections by default, with pagination available beyond that. A count reports the records in each collection.
Record those details before copying anything. A useful migration checklist should connect each collection to the application that reads it, the process that writes it and the person responsible for validating the replacement. Comparing collection and record counts is a useful first check, but it does not establish that search results or application behavior stayed correct.
There is a documented Cloud to local copy route
The Chroma CLI copy guide supports copying from Cloud to a local Chroma server. It can select named collections or all collections in a source database. The destination can be an existing local server or a data path, and the active profile determines which Cloud databases are available.
That is a concrete starting point for testing an exit, not a promise that every production application can migrate unchanged. Run a small representative copy first and check the destination before moving the full workload. Keep source and destination roles explicit so a rehearsal cannot accidentally point back at the service being retired.
Preserve retrieval behavior as well as records
Chroma’s retrieval reference distinguishes fetching records from similarity search. Get supports pagination and returns documents and metadata by default. Embeddings need to be requested through the include option, while record IDs are always returned. Query embeddings must match the dimension of the stored collection.
For a custom export, verify which fields actually arrived rather than treating a successful response as a complete backup. For the replacement application, replay representative searches, metadata filters and empty result cases. Keeping documents alone does not prove that the same embedding setup and retrieval behavior have been preserved. ByteForward’s guide to embedding, reranking and document parsing explains why those retrieval stages need separate checks.
Running the replacement is a separate responsibility
The deployment documentation describes running Chroma in a separate server process, including in a container or on cloud infrastructure, with applications connecting through its client. That preserves a route to use the open source database, but moving data and operating a reliable replacement are different jobs.
Before cutover, assign ownership for capacity, backups, access controls and recovery checks. Keep the first production change small enough to validate and retain a documented rollback plan while the original service still serves the operations you need. The immediate task is continuity for existing applications, not adopting a promised future Replit product.
Illustrative server racks at NERSC in 2011. Photo by Derrick Coetzee under CC0. This is not a Chroma or Replit facility.
