> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mixpeek.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Customer-Hosted Mixpeek

> Run the Mixpeek runtime inside your own Kubernetes environment

You provide Kubernetes, compute, storage and IAM. Mixpeek deploys and operates the
Mixpeek **runtime** inside a namespace you grant, in your account, on your network:
the services that ingest your data, the vector store that holds your index, the Ray
cluster that runs extraction and inference, and the models.

Every byte of your content and every GPU it touches stays inside your environment.

What does not move is the part that has no data in it. The pipeline compiler, the
evaluation and tuning logic, our prompts and model-selection rules, the source and
the build chain stay with Mixpeek. That split is why your platform team is not in
our release cycle, and why we can ship a fix on a Tuesday without asking you for a
change window.

<Note>
  **The short version, for a security review.** Your data plane and your compute
  plane are yours and local. Our authoring plane is ours and remote. Nothing that
  carries your content crosses that line, and the [data
  flow](/docs/customer-hosted/data-flow) traces every stage that could.
</Note>

## What runs where

```text theme={null}
Your account / VPC
│
└── Your Kubernetes cluster
    │
    └── Mixpeek namespace
        ├── Mixpeek API and services
        ├── MVS (the vector store)
        ├── Redis and required stateful services
        └── Mixpeek RayService
            ├── our Ray
            ├── our image
            ├── our Python and CUDA userspace
            └── our models

You provide:
├── CPU and GPU nodes
├── persistent volumes / approved storage classes
├── object storage
├── networking
└── IAM
```

The whole plane lands in the namespace, so there is no second install to reason
about and no component you have to stand up yourself before we arrive.

## What stays with Mixpeek, and why

A platform team's first question about a vendor running software in their cluster
is usually "what are you hiding in there". The honest answer is that we are not
hiding anything in there, because the parts worth protecting are not shipped.

| Runs in your namespace                     | Stays with Mixpeek                      |
| ------------------------------------------ | --------------------------------------- |
| API and services handling your requests    | The pipeline compiler                   |
| MVS, holding your index                    | Evaluation and tuning logic             |
| Ray, running your extraction and inference | Prompts and model-selection rules       |
| The models, executing on your GPUs         | Source repositories and the build chain |
| Redis and required stateful services       | Release engineering                     |

The line is not drawn around sensitivity, it is drawn around **data**. Everything
that touches your content runs where your content already is. Everything that
decides *how* Mixpeek works, and touches no customer data to do it, stays on our
side where we can change it without a deploy into your cluster.

That is also what makes the upgrade story work. A pipeline change is ours to make
and ship; it does not become a Kubernetes change in your environment.

## Why we bring our own runtime

Mixpeek pins a Ray version, a Python version and a CUDA userspace, and ships them
together in one image. That pin is the reason an upgrade is ours to perform.

The test we hold ourselves to: **can Mixpeek upgrade itself without asking your
platform team to upgrade a dependency first?** With our own runtime the answer is
yes. If we adapted to whatever Ray, Python and CUDA you already run, every
Mixpeek release would be gated on your cluster's version matrix, and your Ray
upgrade would become a Mixpeek compatibility event.

So you own where the bytes and the GPUs live. We own how Mixpeek works.

## Supported environments

Customer-Hosted Mixpeek supports qualified Kubernetes environments. We start
narrow on purpose and widen as real deployments ask for it.

|                | Supported today                              |
| -------------- | -------------------------------------------- |
| **Kubernetes** | EKS, GKE                                     |
| **Compute**    | NVIDIA GPU nodes at a known driver baseline  |
| **Storage**    | S3 or GCS, plus approved CSI storage classes |
| **KubeRay**    | operator versions Mixpeek qualifies          |
| **Install**    | the Mixpeek Helm chart                       |

If your environment is outside this list, tell us what it is. Widening the matrix
is a qualification exercise with a real answer at the end of it, and we would
rather run it than guess.

## What Mixpeek asks for

One Kubernetes namespace, and two namespace-scoped Roles inside it.

There is one cluster-scoped prerequisite: the KubeRay operator, which installs
CRDs and ClusterRoles. It is installed once, by you, before Mixpeek arrives, and
it is the only thing outside the namespace.
[Security and RBAC](/docs/customer-hosted/security-rbac) lists every verb we ask for,
that one prerequisite and its lifetime, and how to check all of it with one
command rather than take our word for it.

## What stays yours

Node pools, quotas, taints, tolerations, autoscaler policy and network policy.
Mixpeek's workloads schedule under your rules.

That is a testable claim, and the
[qualification suite](/docs/customer-hosted/qualification) tests it. It submits work
that must land on the pool you designate, work that must be refused for want of a
toleration, and work your quota must reject, then reports which of those actually
happened.

## Before anything is deployed

The suite runs against your bare cluster first and gives you the report: a
plain-text table of checks and verdicts covering reachability, storage
durability and throughput, permissions, networking, capacity, scheduling,
isolation and teardown.

Rows that could not be run say so. A row that cannot establish something reports
what it could not determine rather than reporting an absence, because "we found
no problem" and "we could not look" are different sentences and only one of them
is evidence.

## Teardown

Uninstalling removes the namespace-scoped objects and the workloads. The suite
has an `--expect-clean` mode that runs afterwards and fails if Mixpeek residue
remains, so "we left your cluster as we found it" gets checked.

<Note>
  Customer-Hosted Mixpeek sits at the far end of the [deployment
  ladder](/docs/resources/deployment-models). If you would rather not operate Kubernetes
  at all, BYO Cloud keeps the data in your cloud account while Mixpeek operates the
  infrastructure.
</Note>

<Note>
  Already running your own Ray cluster and want Mixpeek inside it? That is a
  different contract from this one, and it is
  [not part of v1](/docs/customer-hosted/existing-raycluster).
</Note>