Open-source alternative to the OpenAI embeddings API

Open-source alternative to the OpenAI embeddings API: the short answer

If a renewal, a data residency rule or a price change has made you rethink where your embeddings are generated, the short answer is that vLLM can serve open-weight embedding models behind an OpenAI-compatible `/v1/embeddings` endpoint, so most client code changes only in the base URL and the model name. The part that does not change is the index: every vector already stored was produced by a specific model, so a new model means re-embedding the whole corpus and rebuilding the index before search results are trustworthy again.

vLLM is open source under the Apache-2.0 license and has no paid edition, so the software itself costs nothing to license. What you pay for is GPU or other accelerator capacity, the surrounding infrastructure such as storage, networking and monitoring, the implementation work to wire it into your applications, and the engineers who operate it and keep it patched. Ask any implementation partner to split a quote along those lines so you can see which costs recur and which are one-time, and which of them move with the volume of documents you embed.

This page covers embedding only. It does not compare chat or completion inference, which is a separate decision with its own gateway, capacity and safety questions. Confirm with your own team which embedding models your quality tests support and whether the vLLM version you plan to run serves them, because model support changes between releases.

Which embeddings capabilities map to which open-source components

This table maps each part of the OpenAI embeddings workflow to vLLM for serving, pgvector or Qdrant for storage and search, and the gaps to plan for. Read each row as a requirement, then check the gap column before you choose a component. Embedding model support and output dimensions depend on your vLLM version, so confirm both before you commit a vector index.

Capability	vLLM (embedding serving)	pgvector or Qdrant (storage and search)	Gap or action
Endpoint compatibility	Exposes an OpenAI-compatible /v1/embeddings endpoint, so existing client code can point at it	Not applicable, the database has no OpenAI-style endpoint; your application writes and queries vectors	Confirm the specific embedding model and its output dimensions in your vLLM version
Batching and throughput	Serves embedding requests with the same serving engine used for generation; throughput depends on GPU capacity	Bulk inserts run as ordinary database or API writes; batch size is set by your re-embedding job	Benchmark your own corpus, since no throughput figure is supplied for embedding workloads
Vector storage and dimensions	Not applicable	pgvector stores vector and halfvec types up to 16,000 dimensions; Qdrant stores vectors in collections	pgvector cannot index vector columns above 2,000 dimensions, so high-dimension models may need halfvec or Qdrant
Distance metrics	Not applicable	pgvector supports L2, inner product, cosine, L1, Hamming and Jaccard; Qdrant supports its own metric settings per collection	Use the metric the embedding model was trained for, and do not mix metrics across one index
Index types	Not applicable	pgvector offers exact search by default plus HNSW and IVFFlat approximate indexes; Qdrant builds its own index per collection	Approximate indexes trade recall for speed, so test recall on your data after re-embedding
Filtering	Not applicable	pgvector applies filters after the index scan and offers iterative scans to fetch more rows; Qdrant filters are part of its query API	Test filtered queries directly, since filters that remove many rows can return fewer results
Storage requirements	Not applicable	Qdrant needs block storage with a POSIX file system, not NFS or S3; SSD or NVMe is recommended	Do not place Qdrant data on object storage, even if object storage is cheaper
Access control	The --api-key option protects /v1 routes but not /metrics or /health	pgvector uses PostgreSQL roles; Qdrant offers admin and read-only API keys, TLS and JWT per-collection permissions	Put a reverse proxy in front of vLLM that allowlists only /v1/embeddings for applications
Metrics and monitoring	Exposes Prometheus metrics at /metrics covering request counts, latency and throughput	PostgreSQL and Qdrant each expose their own operational metrics for storage and query health	Restrict /metrics to the monitoring network, since the API key does not protect it

Which vector store fits beside vLLM: pgvector or Qdrant

Once embeddings come from a model you serve yourself, the vectors need a home that your team can operate, back up and secure. pgvector and self-hosted Qdrant are the two open-source options covered here, and the right one depends mostly on what your organization already runs.

pgvector inside an existing PostgreSQL estate

pgvector adds vector columns and indexes to PostgreSQL, so embeddings sit in the same database as the records they describe. If your team already runs PostgreSQL 13 or later, backups, replication, access control and upgrade routines carry over without a new system. Check that your PostgreSQL version and extension packaging match your upgrade calendar, and confirm how HNSW index builds will affect your write load.

Vector limits and index choices in pgvector

pgvector offers exact search by default plus HNSW and IVFFlat approximate indexes, and indexes vector columns of up to 2,000 dimensions. Filters are applied after the index scan, so a restrictive WHERE clause can return fewer rows than expected. Test your filtered queries against the iterative index scan settings before you commit to a schema, and confirm that your embedding model's output size fits the indexable limit.

Dedicated vector search with Qdrant

Qdrant is an Apache-2.0 vector search engine built for workloads where embeddings are the primary data and need their own tuning, sharding and capacity planning. It runs well on local SSD or NVMe block storage, but it cannot use NFS or S3-style object storage. Ask your team whether they will operate a second stateful system, and who owns its upgrades and backups.

Scaling Qdrant with Raft and shards

Qdrant distributed mode uses Raft consensus for cluster topology, splits collections into shards and keeps copies through a replication factor. The documentation recommends at least three nodes for production so quorum survives a node failure. A replication factor of 2 doubles storage, so include that multiplier when you size disks and ask your implementation partner to model it against your expected vector count.

Locking down Qdrant access

A default self-deployed Qdrant instance listens on all interfaces with no authentication, so the first step is configuration, not capacity. Qdrant supports admin and read-only API keys, TLS for REST and gRPC, and JWT tokens with per-collection read or write permissions. Confirm which service accounts need write access to re-embedded collections, and enable JSON audit logging for those writes.

Commercial Qdrant options for comparison

Qdrant Cloud offers a free single-node tier and usage-priced plans, while Hybrid Cloud runs managed clusters in your own infrastructure and Private Cloud provides a dedicated enterprise deployment. Both paid options are priced through Qdrant sales, so request written quotes that state the uptime commitment, support level and where data is stored. These are worth weighing only if your team does not want to operate the cluster itself.

Running embeddings next to the existing vector database and application

The lowest-risk split leaves the current vector database and its application code alone and changes only the embedding call. The application still reads and writes vectors through the same client, but the function that turns text into a vector now calls vLLM's OpenAI-compatible /v1/embeddings endpoint instead of OpenAI. The request and response shape stay close to what the application already expects, so the change is usually confined to a base URL, a model name and configuration.

Base URL and model name: point the client at the internal vLLM address and set the model name to the open-weight embedding model you serve.
Dimension check: confirm the new model's output dimension matches the column or collection definition before any write happens.
Config switch: keep the embedding provider behind a configuration flag so you can roll back without a deploy.
Mixed-model guard: never let one query path embed with the old model and another with the new one against the same index.
Test coverage: add a test that embeds a fixed set of sample strings and checks the output shape.

Confirm with your application owners whether any code path compares a query vector to stored vectors produced by a different model, because that path will return misleading results without any error.

Re-embedding every stored document is a batch job that should run as a separate worker, not inside the request path. The worker reads source text or chunks, calls the vLLM embedding endpoint in batches, and writes the new vectors to a new collection or a new column. Writing to a new target keeps the existing index serving production reads until the new one is validated.

Separate target: create a new Qdrant collection or a new pgvector column with its own index, rather than overwriting vectors in place.
Batching and retries: size batches to the throughput vLLM sustains, and retry failed batches with checkpoints so a restart resumes from the last committed batch.
Metrics: watch vLLM's /metrics endpoint for request counts and latency during the run, and keep the worker's own progress counters.
Idempotent writes: key each vector by source document ID and model version so reruns do not create duplicates.
Source of truth: re-read from the system of record, not from a cache of old vectors.

Size the job from your own corpus, not from a generic figure. Ask your team how many chunks exist, how fast your GPU capacity embeds them, and how long the old index must keep serving.

vLLM should run on an isolated network segment, reachable only from the application and the re-embedding worker, and it should sit behind a reverse proxy that allowlists the endpoints users need. The vLLM security documentation warns that its --api-key option does not protect every path, including /metrics, /health and /invocations, and recommends a proxy that passes only the intended routes. For embeddings, that means allowlisting /v1/embeddings and blocking the rest from the application network.

Route allowlist: the proxy forwards /v1/embeddings and denies /pause, /resume, /abort_requests, /invocations and other control paths.
Authentication at the proxy: require client credentials at the proxy and check them against your identity system.
Metrics separation: scrape /metrics from a monitoring network, not from the application network.
Node traffic: if you run multiple GPU nodes, keep inter-node traffic on its own isolated network, because vLLM's multi-node communication is insecure by default.
Vector database access: restrict the vector database to the same private network and disable public listeners.

Ask your security team to confirm the proxy configuration with a test that tries each blocked path from the application subnet.

Filtered approximate search is where the new index can quietly return fewer results than expected. In pgvector, approximate indexes such as HNSW and IVFFlat apply filters after the index is scanned, so a restrictive WHERE clause can remove most candidates and return too few rows. The pgvector README describes iterative index scans, in strict or relaxed ordering modes, that fetch more results when filters remove too many. Test this with the same tenant, date or category filters your application uses in production.

Filter inventory: list every metadata filter the application combines with vector search.
Iterative scans: check the pgvector version and documentation for the setting that enables iterative scans, and test it on your filters.
Recall tests: compare filtered results from the exact search and the approximate index on a sample.
Dimension limit: remember that pgvector indexes vector columns of up to 2,000 dimensions, so confirm the new model's output fits.
Qdrant equivalent: if you use Qdrant, test filtered queries with the payload indexes your collection defines.

Schedule these tests before cutover, because a recall problem found after reads have moved is harder to diagnose than one found in shadow indexing.

Why every stored vector must be re-embedded when the model changes

Vectors from different embedding models do not share a coordinate space, so you cannot mix them in one index and expect similarity search to work. Two models can both output 1,024 or 1,536 dimensions and still place the same sentence in unrelated positions. A cosine or inner product score between a query vector from model B and a document vector from model A is a number with no meaning. This is why matching dimensions are not a compatibility check. Before cutover, confirm the exact model name, weights revision and pooling or normalization settings your embedding server reports, because those details define the space as much as the model family does.

Query vectors and stored document vectors must come from the same model and the same settings. Your application embeds each user query at request time with the new model, so every document already in the vector store, whether in pgvector, Qdrant or another index, must be regenerated with that same model. Changing the model, a minor version, a quantization level or the text preprocessing pipeline all count as changes that require a full rebuild. Partial re-embedding leaves the corpus split across two spaces, and the failure is silent: results look plausible while relevance quietly degrades. Plan the re-embedding job as a complete pass over the source documents, not as an incremental update of changed records.

Keep the old index live until validation passes. Build the new collection or table beside the existing one, run a fixed set of labeled queries against both, and compare recall and ranking with reviewers who know the content. Route traffic to the new index only after those checks pass, and keep the old index for a rollback window that your team sets in advance. Ask whoever runs the vector database how long the duplicate storage will sit idle, since replication settings in Qdrant and disk sizing in pgvector both affect how much extra capacity the overlap needs.

Migrating the corpus to a new embedding model without downtime

This sequence moves every stored vector to an open-weight embedding model while search keeps running on the old index, and ends with one verified index serving all reads. It turns a risky in-place swap into a checked, reversible cutover.

Inventory collections and their embedding models
The platform or data owner lists every collection, index and table that holds embeddings, including the model name, dimension, distance metric and the date each was built. Application teams confirm which services query each collection and whether any use hybrid keyword and vector search. The output is a written inventory that shows which collections must be re-embedded and which callers must change. Each collection should have one owner who signs off on the list.
Pin the open-weight model and dimension
The team selects an open-weight embedding model, records its exact weights revision, its output dimension and the vLLM version used to serve it, and stores these in configuration rather than in code. Because each stored vector depends on the model that produced it, the pinned values become the identity of the new corpus. The check is a short model card that the security and data teams approve, plus a test call to the vLLM server's /v1/embeddings endpoint that returns vectors of the expected length. Vector columns and indexes must be created for that dimension before any backfill starts.
Benchmark retrieval on a representative query set
Engineers assemble a set of real user queries with known relevant documents, drawn from search logs with appropriate privacy controls, and run them against the old index and a candidate index built on a small sample. They compare recall, ranking order and failure cases, and they check that filters and metadata still behave as before. Results are reviewed by the product owner who knows what good answers look like. The step is done when the team has a documented decision to proceed, with the candidate model's known weak queries recorded.
Backfill a parallel index in batches
A job reads source documents in batches, calls the embedding endpoint with the pinned model name, and writes vectors into a new collection or table beside the live one. Batch size, concurrency and retry rules are tuned against the vLLM server's throughput and the vector store's write capacity, and progress is checkpointed so the job can resume after a failure. Sizing comes from the document count, average chunk length and GPU capacity, which the team measures on the sample run. The step ends when row counts match the source and a random sample of vectors reproduces the scores seen during benchmarking.
Keep new writes flowing into both indexes
Until cutover, every new or changed document is embedded with the new model and written to both the old and new indexes, so the parallel index does not fall behind. The ingestion pipeline owner adds a dual-write path and an alert for failed writes to either side. The check is a reconciliation query that compares document identifiers in both indexes and reports any gaps. Teams should not start the switch while that report shows missing documents.
Run shadow queries and dual reads
The application sends a share of live queries to the new index in shadow mode, logging results without showing them to users, then compares them with the production results. When the comparison is stable, a small share of users receives results from the new index, with an instant switch back to the old index if quality or latency degrades. Dashboards track latency, error rate and click-through or feedback signals. The step is complete when the team has signed off on both the shadow comparison and the live split.
Switch reads to the new index
The routing setting that selects the collection is changed to the new index for all readers, and the old index stays in place untouched for rollback. For applications already written against the OpenAI client, the call shape can stay the same, since changing the base URL to the vLLM endpoint and the model name to the pinned embedding model is usually the only edit on the client side. The check is a clean error and latency report across a full business cycle, agreed in advance with the owners.
Retire the old index after a verified rollback window
Once the team agrees the new index is stable, the dual-write path is removed, the OpenAI embedding calls are disabled in configuration, and the old collection is archived or deleted according to the retention policy. Backups or snapshots of the old index are kept for as long as the agreed rollback window requires. The final record is a change note listing the model, dimension, index names, the date of cutover and the person who approved deletion. Confirm the rollback window and retention period with your own governance and compliance owners before deleting anything.

What does it cost and take to replace OpenAI embeddings?

What are the main cost drivers when replacing OpenAI embeddings with a self-hosted model?

The bill has four parts: accelerator time for the one-time backfill, ongoing capacity to embed queries, storage and memory for the vector index, and the engineering and operations people who run the stack. OpenAI's embeddings endpoint charges per token, so its cost scales with usage. A self-hosted model moves that cost into GPU or CPU hours, disks, RAM for the index and staff time. vLLM itself has no license fee, so the spend comes from the hardware or cloud capacity, the surrounding infrastructure, implementation and the people who operate it. Ask the vendor or partner to split each quote along these four lines so you can see which one dominates in your environment.

Which costs are one-time and which recur every month?

The one-time costs are the backfill, meaning embedding every stored document with the new model, plus the initial setup, model evaluation and integration with your vector database. The recurring costs are the GPU or CPU capacity that serves live query embeddings, storage and memory for the index, backups, monitoring, patching and on-call support. Re-embedding is also recurring whenever you change models or move to a new embedding dimension, because every stored vector must be regenerated. Keep these categories separate in any budget so that a future model change is visible as its own line item.

How do corpus size and re-embedding frequency change the bill?

Backfill cost grows with the number of documents and their average length, since the work is proportional to the tokens you embed. Query cost grows with request volume rather than corpus size. Index memory and storage grow with the number of vectors and their dimensions, and pgvector and Qdrant both document that index choice affects memory use. Re-embedding frequency matters most: a corpus that changes daily needs ongoing embedding of new and updated content, while a stable corpus only needs occasional full rebuilds. Illustrative example: a team that changes its embedding model once a year pays for one full backfill per year, while a team that changes models every quarter pays four. Ask for the corpus size, change rate and expected query volume in the quote.

Can our team replace OpenAI embeddings on its own?

A team with experience running GPU workloads, Kubernetes and PostgreSQL or a dedicated vector database can usually do the core work in-house, because vLLM exposes an OpenAI-compatible /v1/embeddings endpoint and the client change can be small. The harder parts are sizing accelerators, choosing a model that performs well on your documents, validating retrieval quality after the switch, securing the endpoint and running the backfill without disrupting search. Vendor documentation also warns that vLLM's --api-key option does not cover every endpoint and that Qdrant is insecure by default, so hardening needs attention. If those skills are thin, an implementation partner can take the work under a written, fixed scope.

How long does a replacement take and what decides it?

No duration is published here, so treat any timeline as something to confirm for your environment. The main factors are the number of documents and pipelines that call the embeddings API, how many vector collections or tables need rebuilding, whether accelerator capacity is already available, the security review for the new endpoint, and how much retrieval testing you require before cutover. Teams with existing Kubernetes and GPU platforms and a single vector store usually have a shorter path than teams starting from zero. Ask for a timeline that lists each phase, the owner of each phase and the acceptance criteria.

What should we ask for in a quote for this work?

Ask for the scope in writing, including the models to be evaluated, the endpoints to replace, the vector stores involved and the corpus size and change rate you provided. Request a breakdown of one-time work (setup, evaluation, backfill, cutover) and recurring work (capacity, monitoring, patching, upgrades, support). Ask which hardware assumptions were made and what happens if they change. Confirm who owns the accelerators and the cloud accounts, what handover documentation you receive, and what acceptance tests define done. DeployOpen works from a written scope, and its ongoing support and testing are offered as retainers, so ask for those as separate lines.

What does the engineering effort cover beyond the GPU bill?

Beyond hardware, the effort covers model selection and retrieval evaluation, because a new embedding model changes which documents match a query. It also covers the vector database work: pgvector runs inside PostgreSQL and supports exact search by default plus HNSW and IVFFlat indexes, while Qdrant needs block storage and a multi-node layout for production. Operations work includes Prometheus metrics from vLLM, backups, upgrades and security hardening of the endpoint and the database. Budget for people who will answer the pager after go-live, not only for the people who build it.

Does the replacement need a security or compliance review?

Yes, in most regulated settings. The new embedding endpoint handles the same source text as the hosted API, so its access controls, logging and network placement need review. vLLM's security documentation says inter-node traffic is insecure by default and recommends a reverse proxy that allowlists only user-facing endpoints, and Qdrant's documentation says self-deployed instances listen on all interfaces without authentication until you configure it. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report, so confirm which evidence your auditor will require before the work starts.

Securing the embedding endpoint and monitoring the job

The --api-key option on vLLM is not enough to protect the embedding endpoint on its own, so place a reverse proxy in front of the server and allowlist only the routes that applications need, starting with /v1/embeddings. The vLLM security docs say the key covers /v1 routes but not /metrics, /health, /pause, /resume, /abort_requests or /invocations, and they warn against relying on the key alone. Configure the proxy to deny everything else by default, keep /metrics and /health reachable only from the monitoring network, and confirm the allowlist with a test request to each blocked path from a client outside that network. Also confirm which routes your vLLM version exposes, because the list changes between releases.

Scrape vLLM's Prometheus-format metrics at /metrics to watch the re-embedding job. The metrics cover request counts, token throughput, latency histograms and KV cache use, and histogram buckets can be configured, so set buckets that match your latency targets before the job starts. Alert on sustained queue growth and on latency that climbs as batch size rises, since either signal means the job will overrun its window. Because /metrics is open by design, it must sit behind the same network control as the proxy, not behind the API key.

Qdrant is the other exposed surface. Its security docs state that self-deployed instances listen on all interfaces and have no authentication by default, so set an admin API key and a read-only key before any application or the re-embedding writer connects, enable TLS for REST and gRPC, and bind the service to the private network. For granular control, the JWT-based per-collection permissions and JSON audit logging described in the security docs let you give the writer write access to the new collection only. Pgvector has a different planning task: it runs inside PostgreSQL, so confirm your PostgreSQL major version against the pgvector README's minimum (version 13 or later) and the PostgreSQL versioning policy, and schedule any major upgrade so it does not collide with the cutover.

Risks that derail an embeddings migration

Most embeddings migrations fail in the same few places: mixed vectors in one index, a changed dimension count, weaker retrieval on your own text, batch jobs that crowd out live queries, and a vector store exposed without authentication. Each card names one of these risks and a check you can run in your own environment before cutover.

Mixed-model vectors in one index

Vectors from OpenAI and from an open-weight model are not comparable, so a single collection holding both returns meaningless nearest neighbors. Re-embed the whole corpus into a new collection or table, then switch the application to it in one step. Check that every stored point or row records the model name and version in its payload or metadata, and run a query that counts vectors per model before you cut over.

Dimension mismatch at query time

An index is created with a fixed vector size, and a different embedding model may produce a different number of dimensions. pgvector indexes vector columns of up to 2,000 dimensions, so a model with a larger output needs a planned column change or a different index approach. Confirm the output size of the chosen model from its model card, then test an insert and a query against the target index in staging before the full job starts.

Quality drop on domain text

Open-weight embedding models are trained on different corpora, so retrieval on your contracts, clinical notes or product codes can rank differently than the old model did. Build a labeled set of real queries with known relevant documents, score both models with recall at k, and compare results before approving the switch. Do not treat a general benchmark as proof for your domain.

Batch jobs starving live traffic

A full re-embedding run sends thousands of requests to the same GPUs that serve production queries, which can raise latency for users. Run the batch with a concurrency cap, on a separate vLLM instance or during a low-traffic window, and watch the latency and KV cache panels in the vLLM metrics endpoint while it runs. Ask your platform team to confirm that query latency stays within your agreed limit throughout.

Unprotected embedding endpoints

The vLLM --api-key option does not cover every route, and the vLLM security docs recommend a reverse proxy that allowlists only the paths users need. Qdrant instances listen on all interfaces with no authentication by default. Confirm that /v1/embeddings is the only embedding route reachable from application subnets, that the vector store requires an API key or JWT, and that neither service is reachable from the internet.

Storage sized without replication

Vector storage grows with corpus size and dimension count, and a replication factor of 2 doubles the stored data in a Qdrant cluster. Qdrant also needs block storage with a POSIX file system, so object storage or NFS will not work. Before you provision, calculate raw vector bytes for the new dimension count, multiply by the replication factor, add index overhead, and confirm the disks are SSD or NVMe with your storage team.

When to keep OpenAI embeddings and when to move

Keep the hosted OpenAI embeddings endpoint when your data may leave your infrastructure under terms you already accept, when retention and residency are settled in writing, and when your volume is small enough that GPU capacity and an on-call rota would cost more than the per-token bill. For many teams that is the honest answer for a pilot, an internal search over non-sensitive documents, or a workload that is still changing shape. Before deciding, confirm the current data processing terms, retention settings and regional processing options with OpenAI directly, since these are contractual facts that change independently of this page.

Move when the reasons are structural rather than preferential. The strongest are data control (embedding inputs can contain the same sensitive text as prompts), deprecation pinning (an embedding model that is retired forces a full re-embedding on the vendor's schedule, while a self-hosted model version stays fixed until you choose to change it), and unit cost at sustained volume. Each has a cost on the other side: GPU capacity, the vector store, monitoring, and engineers who patch and upgrade the serving stack. Ask for a written estimate that separates these components, and model the re-embedding cost of a future model change before you commit, because that cost recurs every time the model changes.

For the wider trade-off, read the related pages on OpenAI API cost versus self-hosted vLLM and on self-hosted OpenAI API alternatives for EU data residency before you choose. They cover per-token spend, residency uplifts and the operating model in more depth than this section. A practical rule is to run both paths on a representative sample of your documents and measure retrieval quality, latency and total monthly cost side by side, then decide on your own numbers rather than on a general claim about either option.

How DeployOpen scopes and delivers an embeddings migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For an embeddings move, that means agreeing in writing which models, vector stores and re-embedding jobs are in scope, then delivering them inside your environment with the evidence your teams need to sign off.

How we scope

Inventory every application and collection that calls the OpenAI embeddings endpoint, and record the model name and dimensions each one stores.
Agree the target open-weight embedding model, the vLLM serving setup and the vector database, including whether pgvector or Qdrant fits your existing stack.
Define the re-embedding window, validation method and rollback path in the written scope before any work starts.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing. Ask for a quote based on that written scope.

How we build

Deploy vLLM's OpenAI-compatible /v1/embeddings endpoint in your environment and place it behind a reverse proxy that exposes only the routes applications need.
Build the re-embedding job so it writes new vectors to a separate collection or column, so the live index is untouched until validation passes.
Configure endpoint authentication, TLS, network isolation between nodes and metrics collection, and test each control before cutover.

How we hand over

Document the deployed architecture, configuration keys, runbooks for re-embedding and rollback, and the retrieval quality checks used during validation.
Provide the evidence your compliance and security reviewers ask for, such as access control settings, logging configuration and change records. DeployOpen prepares this evidence but does not issue audit reports or certifications.
Walk your operations and platform engineers through the handover so they can run future model changes without a rebuild.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after handover.
Retainers can cover vLLM and vector database version upgrades, which ship on a regular cadence, along with re-testing after each change.
Confirm the response expectations, upgrade approach and testing frequency you need in the retainer scope before you sign.

Open-source alternative to the OpenAI embeddings API