SkyPilot: a YAML job layer that spreads AI workloads across clouds and Kubernetes
The AI Compute Platform for frontier teams. SkyPilot turns fragmented AI compute into one AI supercomputer, so frontier AI teams build custom intelligence faster.
At a glance
- What is it?
- SkyPilot puts one job spec and one CLI in front of Kubernetes, Slurm, and more than twenty cloud providers, then picks where each job runs. It is a scheduling and provisioning layer for teams whose GPUs are already scattered, not a training framework.
- Who is it for?
- Adopt SkyPilot if you already hold GPU capacity in more than one place (a Kubernetes cluster plus a cloud account, say) and you want one job spec and one queue in front of all of it. Do not adopt it if you run a single fixed cluster with a stable scheduler, because the failover and provisioning machinery buys you nothing there.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem SkyPilot addresses: GPU capacity that no single scheduler can see
AI teams rarely own one clean pool of accelerators. They hold reserved instances in one cloud, a Kubernetes cluster someone else operates, a Slurm cluster in a university or lab setting, and spot capacity that appears and disappears. Each of those has its own submission interface. A researcher who wants to run a training job has to know which one has room, how to authenticate to it, and how to get the environment onto it. The README frames the product as a system to "run, manage, and scale AI workloads on any AI infrastructure", with two audiences named separately: AI teams get "a simple interface to run jobs on any infra", and infra teams get "a unified control plane to manage any AI compute". That split is the honest description of the project. It is not a training library and it does not implement distributed collectives. It is the layer between a job description and a provider API, and its value scales with how many providers you actually have.
How the abstraction works: a task spec, a provisioner, and a controller
The unit of work is a task described in YAML, and the README describes the model as "Environment and job as code". A task carries a resource request (accelerator type, count, and any provider constraints), a setup command, and a run command. SkyPilot reads that spec, searches the infrastructure it has been configured with for a placement that satisfies the request, provisions it, transfers code and data, then executes. The README calls this "Flexible provisioning of GPUs, TPUs, CPUs, with smart failover", and the linked example is auto-failover, which means a request that cannot be satisfied in the first-choice region or provider is retried elsewhere rather than failing outright. On top of provisioning sits a job queue with the properties the README lists: queue, run, and auto-recover many jobs. Two resource-management behaviours are named explicitly, autostop for "automatic cleanup of idle resources" and binpacking for "workload binpacking on shared clusters". Those two are the cost-control mechanism, and they are also where the operational surprises live, because autostop is a policy about when a machine is considered idle. SkyPilot is BYOC, which the README states plainly: "Everything is launched within your cloud accounts, VPCs, and clusters." No data or credentials route through a SkyPilot-operated control plane in that model. The API server component is the exception worth noting, since it is a service you run yourself for team deployment and resource sharing.
Installing SkyPilot and launching a first job
The README gives uv as the primary install path, with pip, nightly, and from-source listed as alternatives in the installation docs. The command is an extras-based install where you name the providers you want:
uv pip install "skypilot[kubernetes,aws,gcp,azure,oci,nebius,lambda,runpod,fluidstack,paperspace,cudo,ibm,scp,seeweb,shadeform,verda]"
That extras list is the practical constraint. Every provider you add pulls in its own SDK and credential handling, so the install surface grows with the number of clouds you enable. The README points to a Quickstart that claims a cluster launch in two minutes after a one-minute install, and it mentions a SkyPilot Skill for driving the tool from an agent such as Claude Code or Codex by fetching an INSTALL.md from the repository. Beyond that, the README does not reproduce the YAML schema, the CLI subcommands, or the API server configuration keys, so treat the docs site as the source for those rather than the repository front page. What the README does establish is the deployment boundary: credentials stay in your accounts, and the tool acts on your behalf.
Where SkyPilot is the wrong tool
The clearest limitation follows from the design. SkyPilot is a provisioning and scheduling layer, so its cost is paid in indirection. A job that runs on one cluster you control, with a scheduler you already trust, gains nothing from auto-failover or binpacking and inherits a new YAML format and a new queue to learn. The README's own framing supports this: the Kubernetes section is addressed at making K8s "easy for AI & Infra teams" and at turbocharging "your existing Kubernetes clusters", which presumes you have clusters worth turbocharging. The second limitation is that the README is a marketing surface. It lists benefits, blog posts, and case studies, and it names no failure modes, no known constraints on specific providers, and no limits on how many concurrent jobs the queue handles. The claim that SkyPilot "supports your existing GPU, TPU, and CPU workloads, with no code changes" is the kind of statement that needs a definition of what counts as a workload before it means anything. If your job depends on a provider-specific feature, an unusual network topology, or a scheduler behaviour you have tuned by hand, verify it against the docs before assuming the abstraction covers it.
How it differs from Slurm and from Kubernetes-native schedulers
The README positions SkyPilot as "Slurm-like ease of use, cloud-native robustness" and lists Slurm clusters as one of the infrastructures it can sit in front of. That is the useful comparison. Slurm is a scheduler for machines you already own, with a submission model built around partitions and a queue that assumes the nodes are fixed. SkyPilot treats the machine set as elastic and the provider as a variable, so its scheduler has to reason about where to create capacity, not only where to place a job within existing capacity. The Kubernetes comparison runs the other way. Kubernetes schedules pods onto nodes in one cluster; SkyPilot schedules tasks across clusters and across clouds, and the README lists gang scheduling, multi-node jobs, and queueing as the features it adds to a K8s cluster. If your world is one Slurm cluster or one Kubernetes cluster, the native scheduler already knows more about that cluster than SkyPilot will. SkyPilot's advantage appears when the answer to "where should this run" spans more than one system, which is exactly the case the README's supported-infrastructure list describes.
Maintenance, releases, and the Apache-2.0 boundary
The project is active. The supplied material shows a 0.13 line with v0.13.0 released in July 2026, a release candidate before it, and a further release candidate after it, plus a last push date of September 2026 and a note that the repository is not archived. The README also references a v0.13.0 release note that names Hugging Face storage, batch inference abstractions, lifecycle hooks, and governance and robustness on the API server. That cadence matters for upgrade cost: an extras-based install tied to many provider SDKs means a version bump can move several dependencies at once, and the API server component carries its own governance surface that you operate. The licence is Apache-2.0. That permits commercial use and modification, and it includes a patent grant and a notice requirement. It does not come with a support contract or a warranty, and it does not tell you what the project's maintainers will accept into the mainline. Read the licence text against your own redistribution and attribution obligations rather than treating this paragraph as advice. The README does not describe a paid tier or an enterprise support offering, so the maintenance model visible here is community plus self-hosting.
Editorial conclusion
Adopt SkyPilot if you already hold GPU capacity in more than one place (a Kubernetes cluster plus a cloud account, say) and you want one job spec and one queue in front of all of it. Do not adopt it if you run a single fixed cluster with a stable scheduler, because the failover and provisioning machinery buys you nothing there. Before committing, verify two things in a staging project: that the providers you intend to use appear in the install list and have working credentials, and that the resource and autostop fields in your YAML behave the way the docs describe against your own quota. The licence is Apache-2.0, so read it for your redistribution case rather than assuming a support relationship.
Community notes