Chroma Cloud goes read-only on November 22. Here's the runbook for the two dates

Two dates, two different kinds of breakage

Chroma, the company behind the popular open-source vector database, announced on October 23, 2026 that it has signed an agreement to join Replit. As part of that, it is winding down Chroma Cloud, its hosted service, over 60 days.

The timeline page lists two milestones:

November 22, 2026: writes disabled. Chroma Cloud becomes read-only. Apps can no longer create, update or delete data there.

December 22, 2026: reads disabled. Chroma Cloud stops serving read requests altogether.

The open-source database isn't going anywhere. Chroma says ChromaDB remains available under the Apache 2.0 license, that it has moved code from private repos into the open one, and that Replit will keep contributing. If you self-host Chroma already, this notice doesn't change your setup.

If you use the hosted service, though, think about what each date does to your product. The first date breaks anything that learns. The second breaks anything that answers. A support chatbot that adds new help articles every night will quietly stop learning on November 22 and keep answering from stale content. It won't fail loudly. A month later, the same chatbot stops answering at all.

Step one: find everything that touches Chroma Cloud

Before choosing where to move, find out what you're moving. Chroma Cloud tends to spread. It starts in one prototype, then a second team borrows the same database for their feature, and a nightly job gets bolted on to keep it fresh.

Search your code and configuration for the Chroma Cloud client. In Chroma's Python library, apps connect to the hosted service through a dedicated Cloud client, while a self-hosted server uses the HTTP client. That distinction makes the search fairly mechanical. Also search your secrets manager and environment variables for Chroma Cloud API keys, and check scheduled jobs, notebooks and serverless functions that don't live in the main repo.

For each hit, write down three things: which collections it uses, whether it writes, reads or both, and who owns it. Anything that writes has a November 22 deadline. Anything that only reads has until December 22, but in practice it moves with its writer.

Don't skip the owner column. The hardest part of most migrations like this isn't copying data. It's discovering a feature that another team built months ago, which nobody on the current team knows about, and which fails on a Saturday. If you can't find an owner for something, that's a sign it may not be needed at all. Confirm that with the product team, then plan to turn it off rather than move it.

Step two: pick a destination

There are two broad paths, and neither is automatically right.

Self-hosted Chroma. Run open-source ChromaDB on your own infrastructure. Your code changes the least, because the API is the same; mostly you swap the client and the connection details. The trade-off is that you now operate a database: backups, upgrades, monitoring and capacity.

A different database. Move to another vector store, or to vector search inside a database you already run. This is more work now, since queries, filters and client code all change. But it can mean one fewer system to run if your team already operates that database for everything else.

Whichever you pick, keep the same embedding model for the move. Vectors from one model can't be compared with vectors from another. If you want to change models too, do it as a separate project after the migration, not during it. Changing two things at once makes it impossible to tell whether worse answers came from the new database or the new model.

Step three: copy and check

Chroma's command-line tool includes a copy command that moves collections from Chroma Cloud to a local Chroma server. You name the cloud database and either list the collections or copy all of them. If you're moving to self-hosted Chroma, that's the obvious place to start. Moving to another database means exporting through the client library and loading the records on the other side.

Then check the copy before trusting it. Our own minimum:

Counts match. The number of records in each collection is the same on both sides.

Metadata survived. Spot-check records with the longest and strangest metadata values, because those are the ones most likely to be cut or rejected.

Answers match. Take twenty real queries from your logs, run them against both databases and compare the top results. They should be the same or very close. If they aren't, find out why before switching anything.

Speed is acceptable. Run the same queries under something like real load. A self-hosted server on a small machine can be noticeably slower than the hosted service, and users notice that before they notice anything else.

Step four: switch writes before November 22

Plan the write switch for at least a week before the deadline, not on the day. That leaves room for something you missed in step one to turn up.

The usual pattern is to point every writer at the new database, run one full refresh of whatever feeds it, and then point readers at the new database too. If your app can't afford a gap, have writers send to both databases for a few days and compare. Once writes are disabled on Cloud, any job you forgot will start throwing errors. That's useful, because it's how you find it. Watch your logs closely that week.

Step five: cut reads and clean up before December 22

Chroma's own list for the second date is short: finish exporting anything you need to keep, verify that nothing still depends on Chroma Cloud endpoints, and remove or rotate Chroma Cloud credentials in your apps and infrastructure.

Take the credential step seriously. Old keys left in config files tend to outlive the service they belonged to, and a later audit finds them with no context. Delete them, and delete the client code paths that used them, so nobody copies an old example back into a new feature.

Finally, write a short note for the team: where the vectors live now, who owns that database, how it's backed up and which embedding model built them. The next migration will be easier if that note exists.

If you need help moving an AI search, chatbot or agent off Chroma Cloud before the deadline, that's what our AI applications and agents team does. Talk to us.

Related work: Spin Market.