Deployment Models

Mixpeek runs in three shapes. They differ in one dimension: how much of the stack you own. The API, the SDKs and the primitives are identical across all three, and code written against one runs unchanged against the others. This page names who owns what, so a security review can answer its questions without a call.

​

The ownership ladder

There are two products behind those three rows. The third row is the one with a boundary worth drawing, and it sits in exactly one place: You provide the substrate. Mixpeek provides and operates the software. Both planes move together. In customer-hosted Mixpeek the data plane and the compute plane are in your environment: MVS shards on your disks, Ray on your nodes, your object storage. That is the whole point, and it is why we do not offer a shape that moves only one of them.

​

The vector store, in every row

Every row above stores vectors in Mixpeek Vector Store on object storage. That is what we run, in all four models. Your vectors live in object storage in the row’s data plane, not in a separate database you have to operate. In customer-hosted Mixpeek, MVS runs in your Kubernetes, on your disks. It is Mixpeek software, operated by Mixpeek, running on substrate you provide. Your vectors do not leave your environment. MVS is a separate service rather than a Ray workload, deliberately: owning the storage layer end to end is what makes the learned index possible. That is why it moves with the rest of the plane rather than being something you host separately. Mixpeek Vector Store is the vector store in all three shapes. Bringing your own vector database is not a deployment we offer, because owning the storage layer end to end is what makes the learned index possible.

​

What changes, and what does not

On both Mixpeek Cloud rows the control plane stays with Mixpeek: the API gateway, auth, billing, and the routing that sends your requests to the right data plane. What moves is where the work runs and whose hardware it runs on. Customer-hosted is the row where that is a choice. The managed shape keeps the control plane with Mixpeek and your namespace egresses to it; a fully self-hosted install keeps it in your namespace and needs no outbound to us. The boundary section of the data-flow page gives the six collections involved and what the self-hosted shape gives up.

​

BYO Ray, in more detail

BYO Ray is the row where the most is yours, so it is the row with the most to say. You already run Ray or KubeRay. Mixpeek runs its indexing and inference workloads on it rather than asking you to stand up a second one. What you grant. One Kubernetes namespace, and two namespace-scoped Roles inside it. Nothing of ours is cluster-scoped: no ClusterRole, no CRDs of ours, no ability to create namespaces. The one exception, stated rather than buried. KubeRay is cluster-scoped: it ships 3 CustomResourceDefinitions and 5 ClusterRoles, and there is no namespace-only way to install it. Most customers already run it, and where they do not, their platform team installs it once with a Helm command we publish. If you would rather we owned that too, the grant is customresourcedefinitions + clusterroles + clusterrolebindings, and the qualification suite reports which side of that line you are on. Both are supported; the difference is whether a Mixpeek release needing a newer KubeRay waits on your change window. What stays yours. Your node pools, quotas, taints, autoscaler policy and network policy. Mixpeek’s workloads schedule under your rules; they do not change them. What we deploy. Our engine image into that namespace, and ephemeral batch jobs into the same namespace. A Ray cluster runs one image, so where we bring our own cluster your Ray, Python and CUDA versions are not inputs to whether it works. We bring our own Ray. Mixpeek deploys a RayService into your namespace with our image, our Serve applications and our worker groups, and submits batch as RayJobs into the same namespace. Your Ray, Python and CUDA versions are not inputs to whether it works, because a Ray cluster runs one image and that image is ours.

​

Serve isolation on a shared cluster

If you run Mode 2, Mixpeek’s Serve applications sit beside yours on a cluster you own. How we deploy them depends on how yours were deployed, and the difference is worth understanding before you grant access. Ray Serve’s configuration API is declarative over the whole application set: a config that does not name an application removes it. Whether that reaches your applications depends on whether Ray Serve holds a config for them. You can tell which you have: an application with an empty deployed_app_config in GET /api/serve/applications/ was deployed imperatively, and sits outside the lifecycle that config governs. Mixpeek does not use the whole-config path on a cluster it does not own. We add, scale and remove one named application at a time, which cannot reach another application regardless of how yours were deployed. For customers whose Serve apps are declaratively deployed, that is protection against a real and measured hazard rather than a precaution.

​

Qualifying your cluster

Before anything is deployed, Mixpeek runs a qualification suite against your Ray cluster and hands you the report. It checks reachability, the namespace-scoped permissions, connectivity to your object storage and control-plane endpoints, whether your node pools, taints and quotas remain authoritative when we schedule, and whether our workloads leave your existing Ray applications, jobs and actors untouched. The report is a plain-text table of rows and verdicts. Rows that could not be run say so rather than passing quietly, and a row that cannot establish something reports what it could not determine rather than reporting an absence.

​

Choosing a model

• Mixpeek Cloud if you want none of this. Most customers.
• Mixpeek Cloud, dedicated if you need isolated capacity but not custody.
• Customer-hosted if your data must stay in your environment, or your security posture requires that the software run on infrastructure you control.

Already running Ray or KubeRay is not by itself a reason to choose customer-hosted. The reason is custody of the data and the substrate.