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 traces every stage that could.
What runs where
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.
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.
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 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 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.
Customer-Hosted Mixpeek sits at the far end of the deployment
ladder. If you would rather not operate Kubernetes
at all, BYO Cloud keeps the data in your cloud account while Mixpeek operates the
infrastructure.
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.