Should you self-host Chroma or use Chroma Cloud?
Choose Chroma Cloud when you want the vector store running without owning a cluster, and choose self-hosted Chroma when your data, network or compliance rules require the store to run in your own accounts or air-gapped networks. Chroma is licensed under Apache 2.0, and Chroma's open source overview says Chroma Cloud runs the same open-source distributed system, so the choice is about who operates the infrastructure and where the data sits, not about a different product. The Chroma open source overview is the natural next read for how the two relate.
Chroma Cloud fits teams that want a serverless operating model with no node sizing, storage tuning or upgrade windows to plan. It is also a reasonable starting point for a prototype that may later move in-house, since the API is the same. Self-hosting fits when data must stay inside your cloud accounts, data centers or air-gapped network, when a regulator or internal policy requires that a named team controls the storage layer, or when an existing platform team already runs stateful services and can absorb another one. Confirm with your compliance lead whether a hosted service's data location and access model satisfies your obligations before you commit.
Before choosing self-hosting, check which mode you need. Chroma has two deployment modes, distributed Chroma and single-node local Chroma, which rely on different storage subsystems, and local Chroma may temporarily lack features available in the distributed system. If your workload depends on a feature that exists only in the distributed system, a self-hosted single-node deployment may not match what Chroma Cloud provides. Ask the Chroma team or review the release notes for the version you plan to run to confirm which features are present in each mode before you design around them.
How Chroma Cloud and self-hosted Chroma compare on each factor
This table compares Chroma Cloud with self-hosted Chroma across license, deployment modes, feature availability, data location, operating work, telemetry, release cadence and cost. Read each row as a question to answer for your own environment, and treat the cost cells as the list of items to request in a quote.
| Factor | Chroma Cloud | Self-hosted Chroma |
|---|---|---|
| License | Managed service on the same open-source distributed system, so the hosted offering rests on Chroma's open-source code base | Chroma is licensed under Apache 2.0 and its maintainers state the database is and will always remain open source |
| Deployment modes | Hosted serverless service for vector, hybrid and full-text search | Single-node local Chroma or distributed Chroma, which rely on different storage subsystems |
| Feature availability | Runs the distributed system, so confirm which features your query pattern needs in the hosted tier | Local Chroma may temporarily lack features available in the distributed system, so test your required features in the mode you plan to run |
| Data location | Data is held by the vendor in its hosted environment, so confirm region, residency and deletion terms in writing | Data stays in the storage and network you provision, which matters when residency or air-gap rules apply |
| Operating responsibility | Vendor operates the service, so your team focuses on collections, queries and access configuration | Your team owns installation, upgrades, backups, scaling and monitoring of the chosen mode |
| Product telemetry | Confirm with the vendor what usage and operational data the hosted service records | As of version 1.5.4, Chroma no longer collects product telemetry according to the project's open source overview |
| Release cadence | Hosted service updates are handled by the vendor, so confirm the change notice and maintenance windows | Chroma 1.5.9 was published on May 5, 2026, and tagged PyPI and npm packages ship on Mondays with hotfixes at any time |
| Cost components | Usage-based or plan-based fees set by the vendor, with $5 of free credits for Cloud signups per the project README; confirm current pricing and SLA terms directly with the vendor | No vendor fee for the open-source code, but you pay for compute, storage, backups, monitoring and the engineering time to run it |
Where your data lives and who can reach it
Chroma Cloud and self-hosted Chroma put the same kinds of data in very different places, so the questions about location, reach, keys and evidence change with the deployment. Work through these cards before you commit, and get written answers for the managed service rather than assuming them.
Where the vectors and documents sit
With self-hosted Chroma, embeddings, documents and metadata stay on disks or volumes you choose, in your cloud account or data center. With Chroma Cloud, the same data is stored by the vendor's hosted service. Ask which region holds your data, whether backups leave that region, and whether any copy is kept for service operation. Use an illustrative test: if a query log contains a customer identifier, confirm where that log is written.
Network paths and who can connect
A self-hosted Chroma server listens only where you expose it, so you decide whether it sits on a private subnet, behind a gateway or on localhost. Chroma Cloud requires your application to reach an external endpoint, which means outbound traffic from your network and API credentials that must be stored and rotated. Map every client that will query the database and confirm how each one authenticates.
Encryption and key ownership
Self-hosted deployments let you choose disk encryption, volume keys and the key management service, and you hold those keys. For Chroma Cloud, ask whether data is encrypted at rest and in transit, which keys are used, who manages them, and whether customer-managed keys are offered. Do not assume any of these answers from the open-source license, which covers the code, not the hosted service.
Audit evidence and logs
Access logs, configuration history and change records are your evidence when you self-host, and you must collect them from your own systems. With Chroma Cloud, ask the vendor which audit logs exist, how long they are kept, whether you can export them, and which independent reports cover the service. DeployOpen prepares controls and evidence for compliance assessments but does not issue audit reports or certifications. Independent auditors and certification bodies issue those.
Shared responsibility boundaries
Self-hosting makes you responsible for patching, backups, availability and access control across the whole stack. Chroma Cloud moves infrastructure operation to the vendor, but your team still owns the data you send, the credentials you issue and the application logic that queries it. Write down which party handles each control before go-live, because gaps between the two sides are where data exposure usually occurs.
Vendor documentation to request
Before you rely on Chroma Cloud for regulated data, request the vendor's security documentation and data processing terms in writing, including subprocessors, data retention, deletion on termination and breach notification. Compare those terms with your own policies and with the controls your assessor will test. If the answers are missing or unclear, treat that as an open risk, not as a yes.
Which Chroma features differ between local and distributed modes
Chroma runs in two deployment modes, and they rely on different storage subsystems. Distributed Chroma and single-node local Chroma are not interchangeable at the storage layer, and Chroma's open source overview states that local Chroma may temporarily lack features that the distributed system has. That means the feature set you prototype against on a laptop is not guaranteed to be the feature set you get on a self-hosted single node. Before you commit to single-node self-hosting, map every capability your workload depends on (filtering, search types, collection handling, client access patterns) against the current feature matrix in the Chroma open source overview, and confirm any remaining gaps directly with the maintainers rather than assuming parity from older tutorials.
The core API is deliberately small: four functions, with Chroma handling tokenization, embedding and indexing automatically, and metadata and document-content filters applied at query time. Those filters are the part most likely to matter in production, because a filter that behaves differently between your test instance and your deployed instance will surface as wrong retrieval results, not as an error. Build a test set that exercises your exact metadata filters and document-content filters on the mode you plan to run, then repeat the same test on the mode you plan to use in production. Record which client calls you rely on, since the in-memory client used for prototyping and the client-server mode started with chroma run --path are different operating shapes with different operational needs.
Client-server mode, started with chroma run --path, is the usual step between a notebook and a service, and it is where self-hosting effort begins. You own the process, the path on disk, backups of that path, upgrades and access control around it. Chroma Cloud removes those duties but moves the data and the service boundary to Chroma's side, which you must evaluate against your data-location rules. Ask the maintainers which features are absent or limited in local mode for the version you intend to run, and plan a re-test whenever you upgrade, because the feature gap is described as temporary and the project ships releases frequently.
What your team runs in each hosting model
Chroma Cloud is a hosted, serverless vector, hybrid and full-text search service built on the same open-source distributed system as self-hosted Chroma. The vendor runs the service, so your team's operating work centers on how applications authenticate, how collections are organized and how usage is watched. Infrastructure tasks such as provisioning nodes, storage layout and server patching sit with the provider, and you should read its terms to see what it covers.
- API keys and access: Your team creates and rotates the credentials that applications use to reach the service, and decides which applications and people hold them.
- Collections and schema: Your team designs how collections, metadata and document content are organized, and keeps that design consistent across applications.
- Usage tracking: Your team watches query and storage consumption, since serverless billing follows usage and unexpected growth shows up there first.
- Data residency and retention: Your team must confirm where data is stored, how it is deleted and what the provider's agreements say about processing.
- Availability and support: Your team relies on the provider's published service terms and support channels, so confirm its availability commitments in writing.
Before committing, ask the vendor for its data location options, deletion process, encryption details and current pricing for your expected volume.
Self-hosted Chroma puts installation and operation in your hands, whether you run single-node local Chroma or distributed Chroma in your own infrastructure. Installation starts with pip install chromadb or npm install chromadb, and a client-server deployment is started with chroma run --path. From there, your team owns the storage, upgrades, backups, monitoring, scaling and on-call response for every environment it runs.
- Installation and upgrades: Your team pins versions, tests each release, and plans upgrades against the release cadence and any feature differences between local and distributed modes.
- Storage and backups: Your team chooses the storage layout, sizes volumes, and defines backup and restore procedures that have been tested.
- Monitoring and on-call: Your team sets up health checks, logging and alerts, and staffs people to respond when the service degrades.
- Scaling: Your team plans capacity for data volume and query load, and moves to distributed mode when a single node no longer fits.
- Data location: Your systems hold the data, so residency, access control and encryption are design decisions you document.
If you choose this model, confirm with the Chroma project which features are available in your chosen mode before you commit.
The effort of either model depends on a small set of factors that change with your situation. Data volume determines how much storage, indexing and backup work there is, and how quickly query load grows. Availability requirements determine whether a single node is acceptable or whether you need redundancy, failover and staffed on-call coverage. Each additional environment, such as development, staging and production, multiplies configuration, upgrades and access reviews.
- Data volume: Larger collections increase storage sizing, backup duration and the cost of restores.
- Availability target: Higher uptime expectations push self-hosted teams toward distributed deployment and more monitoring.
- Number of environments: Each environment needs its own configuration, secrets and upgrade testing.
- Upgrade cadence: Frequent releases mean more testing cycles for self-hosted teams, while managed upgrades shift that work to the provider.
- Compliance evidence: Regulated teams need logs, access records and documented procedures, and those requirements add work in either model.
Ask each option's provider or implementer to estimate effort for your volume, environments and availability target in a written scope.
How to move data between self-hosted Chroma and Chroma Cloud
This sequence moves a Chroma collection set between a self-hosted store and Chroma Cloud while keeping embeddings, metadata and document content comparable, and it ends with a verified cutover and a retired old store. The exact export and import path must be confirmed against current Chroma documentation before any work starts, and DeployOpen scopes the migration in writing first.
Inventory collections, metadata and document content
List every collection on the self-hosted store, with its name, record count, metadata keys, whether documents are stored alongside vectors, and which application or service queries it. Record the client code paths that read and write each collection, since these define what must change at cutover. The owning team signs off on this inventory, and it is done when every collection has a named owner and a documented query pattern. Note any collection whose metadata filters are used by production queries, because those filters are the first thing to validate later.
Confirm the embedding function and model
Identify the embedding function and model that produced the stored vectors, including the model version and any preprocessing or chunking applied before embedding. Confirm that Chroma Cloud will receive the same vectors, or that the same model will be used for any new embeddings, so that similarity scores stay comparable across the two stores. Ask the Chroma team to confirm how the embedding function is recorded per collection and how it is configured on the cloud side. The step is done when the team can state, for each collection, which model produced its vectors and how new records will be embedded.
Export and re-ingest or replicate the data
Export records from the self-hosted store, including IDs, embeddings, metadata and documents, and load them into the target collections on Chroma Cloud. Confirm the export path against current Chroma documentation before scripting it, since the method for bulk export and import can change between releases. Where the vectors cannot be carried over, re-embed the source documents with the confirmed model and record which method was used per collection. The output is a row-count and ID match report for each collection, which shows that nothing was dropped during transfer.
Validate query results with metadata filters
Run a fixed set of representative queries against both stores, including queries that combine vector similarity with metadata and document-content filters. Compare the top results, filter behavior and result counts, and investigate any difference before accepting the target. Include edge cases such as empty filters, missing metadata keys and records with long documents. The step is done when the test set passes on agreed thresholds that the owning team approves in writing, and the results are archived as evidence.
Cut over the client configuration
Change the client configuration in each application from the self-hosted endpoint to the Chroma Cloud connection, with credentials stored in the team's secrets manager rather than in code. Deploy the change to a staging environment first, then to production in a controlled window agreed with the service owners. Keep the old endpoint available in configuration so a rollback is a configuration change, not a rebuild. The step is complete when production traffic reads and writes against the cloud collections and error rates match the pre-cutover baseline.
Decommission the old store after verification
Once the cutover has run stably and the owners accept the results, take a final backup of the self-hosted data, then stop the service and remove its storage, network rules and monitoring entries. Confirm the retention requirements for the backup with your compliance and legal owners before deleting anything, and record where the backup is kept and who can restore it. The step is done when the old endpoint is closed, the backup is verified as restorable, and the decommission record lists the removed components.
Questions buyers ask before choosing a hosting model
What does self-hosting Chroma actually cost, and what drives it?
Self-hosting Chroma carries no license fee, because Chroma is Apache 2.0 licensed, but the total cost comes from three places: the infrastructure you run it on, the staff time to operate it, and the upgrade and backup work that recurs after go-live. Infrastructure cost follows data volume, query load and your choice of single-node or distributed mode, since the two modes rely on different storage subsystems. Staff time is paid to your own engineers or to an outside partner, and it recurs for patching, monitoring and version tracking. Chroma Cloud shifts much of that work to the vendor, but no price is supplied here, so ask Chroma for its current pricing and model your expected data and query volume against it. When you request a quote from any partner, ask for separate line items: one-time build, recurring support, upgrade cycles and backup testing.
Can our team run self-hosted Chroma without outside help?
Only if your team already operates stateful services and can own patching, backups and monitoring. Chroma's README shows the entry path: a local client installed with pip or npm, and a client-server mode started with chroma run --path, so a proof of concept is within reach of most engineers. Production is a different task. Distributed Chroma depends on a different storage subsystem than local Chroma, and you must track releases such as 1.5.9, published on May 5, 2026, with tagged packages released on Mondays and hotfixes at any time. Before you decide, ask who handles on-call, who tests upgrades and who performs and verifies a restore. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted platforms inside your infrastructure, and ongoing support is available as a retainer, so outside help can cover some or all of that work.
How long does moving between Chroma Cloud and self-hosting take?
No duration is supplied for this move, so treat any estimate as something to get in writing. The time depends on how much data you move, whether you are changing deployment mode, and which features your application uses, because local Chroma may temporarily lack features that the distributed system offers. Confirm the export and import path with Chroma before you plan, since the method determines most of the work. A safe sequence is to stand up the target, load a copy of the data, compare query results on a representative sample, and then cut over traffic. Ask any partner for a written fixed-scope plan that lists deliverables and timelines before work starts. DeployOpen agrees scope, deliverables and timelines in writing before any work begins, so the schedule in a proposal follows from the scope you define.
Does Chroma Cloud keep our data in a region we choose?
The supplied documentation does not state a data residency commitment for Chroma Cloud, so confirm it with Chroma in writing before you sign. Ask which regions are offered, where backups, logs and metadata are held, whether a region can be fixed in the contract, and who can access data from outside that region. If a specific region is a hard requirement, self-hosting in your own cloud account, data center or air-gapped network keeps the location under your direct control, and the question becomes whether your own controls meet the requirement. DeployOpen works inside the client's own infrastructure, but it does not issue audit reports, attestations or certifications. Residency evidence therefore comes from your controls and from the independent auditor you engage.
Does the $5 Chroma Cloud signup credit cover production use?
No. The Chroma README says Chroma Cloud signups receive $5 of free credits, which is a signup credit that covers evaluation, and it does not cover recurring production use. Production cost depends on how much data you store, how many queries you run and which search features you use, and the vendor sets those rates. Before you budget, ask Chroma for current pricing, then run a representative workload in a trial account and record what it consumes. Use those measurements to build the monthly figure for your finance team. If you choose self-hosting instead, the Apache 2.0 license removes license spend, and your costs move to infrastructure and staff time.
Does self-hosted Chroma send telemetry to the vendor?
No. The Chroma open source overview says that as of version 1.5.4, Chroma no longer collects product telemetry. Run version 1.5.4 or later, pin the exact version in your deployment files, and verify the behavior yourself. Check which version your image or package resolves to, and review outbound network rules so your environment enforces the policy regardless of the software's settings. Telemetry is only one data path. Your application may also send content to embedding and model providers, and those calls are separate from the database. For a sensitive environment, ask your security team to confirm outbound traffic with a test in staging before go-live. Keep the evidence with your change records.
What does a fixed-scope DeployOpen engagement include for Chroma?
A fixed-scope DeployOpen engagement covers the self-hosted work you agree in writing: planning, implementation, integration, hardening, backup setup, upgrades, documentation and support for the platform inside your own infrastructure. Scope, deliverables and timelines are set in writing before work starts, so the agreement defines what changes and what you receive. For Chroma, an illustrative scope could include choosing single-node or distributed mode, deploying into your cloud account or data center, configuring backups and documenting the upgrade steps. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope. It prepares systems and evidence for compliance assessments but does not issue audit reports, attestations or certifications.
Which features might be missing when running Chroma locally?
Local Chroma can lack features that the distributed system offers, and the Chroma open source overview says this gap may be temporary. Check the features your application needs against the current overview before choosing a mode, including the search types, metadata and document filters, and the scale you expect. Local and distributed modes also rely on different storage subsystems, so backup, restore and monitoring steps differ between them. A practical test is to write a short checklist of required query patterns, run each one in both modes, and record every gap. If a gap affects your design, you may need the distributed system, which adds operating components. Ask Chroma which features are currently missing in local mode, because that list may change between releases.
How DeployOpen scopes, delivers and supports self-hosted Chroma
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so a self-hosted Chroma deployment is scoped around your cloud accounts, data center or air-gapped network. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Written scope names which Chroma mode fits the workload, single-node local or distributed.
- Scope lists the storage subsystem, hosting location and data residency boundaries for your collections.
- Scope records which local-mode features your application needs, so gaps versus distributed Chroma are known up front.
How we build
- Deployment covers installation, client-server configuration and network access controls for your Chroma service.
- Build includes backup and restore procedures for the vector store and the metadata it depends on.
- Testing covers query filters, embedding pipeline behavior and recovery steps before the service goes live.
How we hand over
- Handover documents the deployment architecture, configuration, upgrade path and data location for auditors and operators.
- Runbooks describe routine operations, scaling steps and incident response for your own engineers.
- Evidence packs record the controls and settings your compliance team needs to review, without claiming any certification.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers for self-hosted Chroma.
- Upgrade planning tracks Chroma release changes so you can test new versions before rolling them out.
- Confirm response expectations, service windows and escalation paths in the written agreement before work starts.
