Mixpeek Appliance
S3-compatible object storage on your own disks, orchestrated by Mixpeek
A private multimodal AI data center in a single rack. Your media stays on hardware you own, behind a standard object API, with extraction, indexing, retrieval, inference and training all running beside it.
What is the Mixpeek Appliance?
The Mixpeek Appliance is a private mini data center for multimodal AI: a 27-32U rack holding a GPU compute node, a 24-bay storage node and the network between them, running a complete multimodal AI stack locally. Durable data sits behind an S3-compatible object API on disks you own, and Mixpeek orchestrates extraction, indexing and retrieval against that object namespace. Nothing has to leave the building for a video to become searchable.
The design is organised around the storage layer rather than the GPU, because the durable asset is the corpus and its namespace while compute is replaceable and additive. That is what lets it start as four disks beside a workstation and grow into a multi-node private AI cluster without any pipeline, dataset reference or index changing along the way.
Object storage first
A canonical s3:// namespace on your own ZFS pool. Disks, filesystems and servers change underneath it without anything above having to.
Compute is replaceable
96 GB of accelerator and 512 GB of ECC in a pod you can duplicate. Add a second GPU, a second node, or a future qualified accelerator.
Built for the next fabric
100 GbE to start, with the path to 200/400 GbE RDMA and a separate compute fabric when model parallelism warrants it.
On-premise by construction
Every layer runs in the rack. The secure overlay is a client convenience, not an infrastructure dependency, so air-gapping changes one thing.
The four principles behind it
The same four hold whether you buy this or build it yourself, which is why the full plan is published rather than gated.
- 01
Own your storage, and own it as S3
Owning the bytes is only half of it. Owning them behind a standard object API is what makes them useful.
- 02
Future-proof the storage before anything else
The namespace outlives every machine it has ever been served from.
- 03
Extend the rack so compute comes to the data
The endgame is NVMe and inference sitting beside the object store, so search over your own storage runs end to end without leaving the rack.
- 04
Start small, extend, never re-architect
Every phase should reuse the last one, which is a constraint on what you buy first.
Does moving to it mean rewriting anything?
No. It is fully S3-compatible, with no code change. The object endpoint speaks the S3 API, so an existing client changes an endpoint URL and keeps working: same SDKs, same bucket and key layout, same tooling, same commands in CI.
Before: cloud object storage
# Against AWS S3 aws s3 cp clip.mp4 s3://media-corpus/raw/clip.mp4 aws s3 ls s3://media-corpus/raw/
After: the Mixpeek Appliance
# Against the Appliance: same command, one flag aws s3 cp clip.mp4 s3://media-corpus/raw/clip.mp4 \ --endpoint-url https://appliance.internal:9000 aws s3 ls s3://media-corpus/raw/ \ --endpoint-url https://appliance.internal:9000
Set AWS_ENDPOINT_URL in the environment and even the flag disappears.
Before: cloud object storage
import boto3
s3 = boto3.client("s3")
s3.upload_file("clip.mp4", "media-corpus", "raw/clip.mp4")
for o in s3.list_objects_v2(Bucket="media-corpus")["Contents"]:
print(o["Key"], o["Size"])After: the Mixpeek Appliance
import boto3
s3 = boto3.client("s3", endpoint_url="https://appliance.internal:9000")
s3.upload_file("clip.mp4", "media-corpus", "raw/clip.mp4")
for o in s3.list_objects_v2(Bucket="media-corpus")["Contents"]:
print(o["Key"], o["Size"])One keyword argument. Every call below it is untouched.
Before: cloud object storage
// Storage connection, provider_type "s3"
{
"provider_type": "s3",
"provider_config": {
"provider_type": "s3",
"region": "us-east-1",
"credentials": {
"type": "access_key",
"access_key_id": "...",
"secret_access_key": "..."
},
"endpoint_url": null
}
}After: the Mixpeek Appliance
// The same connection, pointed at the Appliance
{
"provider_type": "s3",
"provider_config": {
"provider_type": "s3",
"region": "us-east-1",
"credentials": {
"type": "access_key",
"access_key_id": "...",
"secret_access_key": "..."
},
"endpoint_url": "https://appliance.internal:9000"
}
}Still provider_type "s3". One field differs. Buckets, collections, extractors, retrievers and taxonomies above this are untouched, because they address objects rather than disks.
How is it put together?
Clients reach the rack over a secure overlay. Inside, an isolated management plane and a high-speed data fabric connect the compute pods to the storage pod that holds the canonical objects.
Text version of this diagram
CLIENTS / CONTROL
┌──────────────────────┬──────────────────────┐
│ │ │
Mac Studio / amux Engineer laptop Customer client
│ │ │
└──────────────────────┴──────────────────────┘
│
TAILSCALE / VPN
SECURE ACCESS PLANE
│
▼
┌──────────────────────────────────────────────────────────────────────┐
│ MIXPEEK APPLIANCE │
│ │
│ MANAGEMENT: BMC/IPMI · K8s controllers · UPS · sensors │
│ SERVICES: Mixpeek API · inference · SSH/admin │
│ │
│ 100 GbE DATA FABRIC │
│ future 200/400G RDMA │
│ │ │
│ ┌──────────────────┼──────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────────┐ ┌──────────────┐ ┌────────────────────┐ │
│ │ COMPUTE-01 │ │ COMPUTE-02 │ │ STORAGE-01 │ │
│ │ 96GB GPU │ │ [future] │ │ S3 / ZFS │ │
│ │ 512GB ECC │ │ │ │ 12→24 HDDs │ │
│ │ local NVMe │ │ │ │ canonical corpus │ │
│ └──────┬───────┘ └──────┬───────┘ └─────────┬──────────┘ │
│ │ │ │ │
│ └──────────────────┼─────────────────────┘ │
│ ▼ │
│ LUSTRE [V2] │
│ shared hot POSIX │
└──────────────────────────────────────────────────────────────────────┘The full breakdown, including the storage hierarchy, the four network planes and the physical rack layout, is on the architecture page.
How does it grow?
In four phases, each of which leaves the previous one intact. The first purchase is disks, not a rack, and those disks are chosen so they move into the rack later.
Phase 0: Now
Buy the final storage chassis now, not a stand-in
Useful capacity immediately, on the exact hardware that becomes permanent. Nothing bought at this phase is ever replaced, only added to.
Phase 1: V1 rack
A self-contained multimodal AI appliance
Private large-scale ingestion, multimodal inference and model training in one 27-32U cabinet.
Phase 2: Horizontal scale
More nodes, one logical pool
Compute, storage and bandwidth scale independently of each other.
Phase 3: Frontier and off-grid
Nothing built in V1 is invalidated
A private AI cluster where newer accelerator nodes join without changing the object namespace.
Where Mixpeek fits
Mixpeek indexes unstructured files in object storage at the token level: a video becomes scenes, frames, a transcript and any attached documents, each embedded and individually searchable, so a query returns a timestamp rather than a filename. That is the same product that runs against cloud object storage, pointed at a bucket in your rack instead of one in a region.
The reason it matters here is read volume. Multimodal indexing re-reads the whole corpus every time a model or a pipeline changes, and that read pattern is exactly what makes remote object storage expensive. Running the extraction beside the disks turns a recurring transfer bill into power.
Not sure what you would actually need?
Tell us the corpus, the workloads and the constraints, and we will size it against the build sheet: drive count, GPU class, fabric, power, and which phase to start at. You own the hardware either way, and the plan is published in full whether you build it yourself or have us do it.
It is fully S3-compatible, with no code change. The object endpoint speaks the S3 API, so anything already talking to S3 points at a new endpoint URL and keeps working. Same SDKs, same bucket and key layout, same tooling.