Introducing Outpost

Last updated: March 19, 2026

STORAGE COMPUTE ------- ------- .-------------. .-------------. | models | | GPUs | | datasets | | CPUs | | code | | jobs | | artifacts | | services | '------+------' '------+------' | | v v .-------------------. | outpost cli | '-------------------'

You've trained a model. The checkpoint is 47GB. The dataset it was trained on is another 30GB. The training script, config files, and evaluation harness are scattered across your local machine, a shared drive, and two different S3 buckets.

Now you need to version it, reproduce it, and deploy it.

This is where most AI teams start duct-taping. Git can't handle the checkpoint. The dataset lives somewhere else. Getting a GPU for the next training run means filing a request or navigating a cloud console. Deploying to production means wiring up containers, load balancers, and autoscaling policies. Each step is a different tool, a different interface, a different bill.

We built Outpost to make this simple. The entire workflow — version, train, deploy — runs through one CLI and reduces to two primitives: storage and compute.

Store everything in one repository

Outpost has its own version control system, written from scratch in Rust. It handles files of any size — no LFS, no plugins, no external storage tiers. A 47GB checkpoint and a 200-line training script are versioned together in the same repository, with the same history.

Here's what that looks like in practice. You've just finished a fine-tuning run:

outpost add model.bin dataset/ train.py config.yaml

outpost commit -m "llama-3 finetune: learning rate 2e-5, 3 epochs"

outpost push

That's it. Your model, data, code, and config are now versioned, deduplicated, and accessible to anyone on your team with outpost pull.

outpost push | v .--------------------------. | MODEL 47 GB | | DATA 30 GB | | CODE 8 KB | | CONFIG 2 KB | | | | content-addressed | | deduplicated | | versioned | '--------------------------'

Storage is content-addressed — every object is identified by its hash. Push a 47GB model, change one layer and push again, and only the diff is transferred. Identical content is stored once across all versions and repositories.

Launch compute in seconds

Now you want to run the next experiment. On Outpost, you pick your workload type and go:

outpost dev launch --name finetune-v2 --cloud aws --region us-east-1 --gpus A100

You're SSH'd into an A100 machine in under a minute. Your IDE attaches over SSH. You iterate, debug, and run experiments interactively — like having a GPU desktop in the cloud.

When you're ready to run a longer training job unattended:

outpost jobs launch --name train-run --gpus H100:4 --cloud aws --region us-east-1 --command "bash train.sh"

The job provisions four H100s, runs your script, and terminates when it's done. Billing stops the moment the script exits.

Need a throwaway environment to test a new dependency or debug a CUDA issue?

outpost sandbox launch --image pytorch:latest

The sandbox spins up, you do your work, and it auto-destroys after an idle timeout. No cleanup required.

.--------. .--------. .--------. .--------. | DEV | | JOB | |SERVICE | |SANDBOX | | SSH+IDE| | batch | | HTTP | | ephem | '---+----' '---+----' '---+----' '---+----' | | | | +----------+----------+----------+ | .------------------------. | A100 . H100 . CPU | | auto-scale | | scale-to-zero | '------------------------'

Deploy to production in one command

Your model is trained and evaluated. Time to serve it. With Outpost, deployment is a single command:

outpost serve launch --name llama-api --cloud aws --region us-east-1 --gpus A100 --port 8080

This creates an HTTP endpoint behind a gateway that monitors P99 latency and adjusts replicas every 60 seconds. When nobody is calling your endpoint, it scales to zero — you pay nothing. When traffic spikes, new replicas come up automatically.

Multi-region deployment with automatic failover is built in. Your endpoint gets a stable URL, and the gateway handles routing, health checks, and load balancing.

The full picture

Here's the workflow from start to finish, all from the Outpost CLI:

  • outpost init — create a repository
  • outpost add / outpost commit / outpost push — version your model, data, and code together
  • outpost dev launch --name dev-box --cloud aws --region us-east-1 --gpus A100 — get a GPU machine to iterate on
  • outpost jobs launch --name train-run --gpus A100:4 --cloud aws --region us-east-1 --command "bash train.sh" — run a training job to completion
  • outpost sandbox launch --image pytorch:latest — spin up a throwaway environment
  • outpost serve launch --name my-api --cloud aws --region us-east-1 --port 8080 — deploy your model as a production endpoint

No YAML. No Terraform. No separate storage, compute, and serving accounts. One tool, two primitives.

Under the hood

Outpost is written in Rust end to end — the version control system, the orchestration engine, the proxy and gateway layer, the autoscaler. AI infrastructure moves large binary files, routes high-throughput inference traffic, and manages GPU clusters across the clouds and regions. Rust gives us the memory safety, predictable latency, and throughput this requires.

The orchestration engine manages provisioning, scheduling, networking, and teardown for every workload. The gateway routes traffic via host headers for multi-tenant isolation. The autoscaler adjusts replica counts based on observed P99 latency. All of this runs without any configuration from the user — it's the infrastructure behind the single commands shown above.

Get started in 5 minutes

brew install outpostkit

Then:

outpost login

outpost init my-project

outpost dev launch --name dev-box --cloud aws --region us-east-1 --gpus A100

You now have a versioned repository and a GPU machine. Push your first model, run your first job, deploy your first endpoint — all from the same CLI.

Create an account and start building. We'd love to hear what you're working on — reach out anytime.