# Skaffold: a client-side build and deploy loop for Kubernetes > Skaffold is a Go CLI that watches your source, builds images, and deploys them to any Kubernetes cluster without a cluster-side component. It is production ready and Apache-2.0 licensed, but the README does not document rollback. **GoogleContainerTools/skaffold** — Easy and Repeatable Kubernetes Development. It can manage and keep Skaffold up-to-date while providing a more guided startup experience, along with providing and managing other common dependencies, and works with any kubernetes cluster. - Repository: https://github.com/GoogleContainerTools/skaffold - Website: https://skaffold.dev/ - Stars: 15,894 · Forks: 1,702 - Language: Go - License: Apache-2.0 - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/googlecontainertools-skaffold ## The gap Skaffold fills between editing a file and seeing it run Kubernetes development has a repetitive middle: edit source, build an image, tag it, push it somewhere the cluster can pull from, update a manifest, apply it, then find the new pod and read its logs. Skaffold exists to collapse that middle into one command. The README describes it as "a command line tool that facilitates continuous development for Kubernetes applications" and says it handles the workflow for building, pushing and deploying your application. The audience is narrow but common: engineers who run a real Kubernetes cluster (local or remote) and want their inner loop to look the same as their CI pipeline. The README frames portability as a feature, with the claim that sharing a project is as simple as git clone followed by skaffold run. That matters for onboarding, because the build and deploy steps live in a checked-in config file rather than in a wiki page. It is not a cluster installer, not a service mesh, and not a GitOps controller. The README states plainly that Skaffold is client-side only, with no cluster-side component. Everything Skaffold does happens from the machine where you type the command. ## Build, tag, deploy: the pipeline the CLI runs on every change The mechanism is a detect, build, deploy loop. Skaffold watches your source tree, and when it sees a change it runs the pipeline stages configured for the project. The README calls this "optimized source-to-deploy" and notes policy based image tagging, which is how Skaffold decides what tag the new image gets and how the manifests are updated to reference it. Two behaviours round out the loop. First, log aggregation: the README says Skaffold "automatically aggregates logs from deployed resources", so you do not need a second terminal running kubectl logs. Second, port forwarding: it forwards container ports to your local machine, per the same feature list. The configuration is declarative and pluggable. skaffold init inspects your files and generates a starting config, and the README states the architecture is pluggable enough to integrate with any build or deploy tool. The examples directory backs that up with directories such as examples/getting-started, examples/helm-deployment, examples/getting-started-kustomize, examples/buildpacks, examples/compose and examples/custom-buildx, which suggests the intended pattern: pick the builder and deployer that match what you already use. For CI, the same pipeline is exposed as separate phases. skaffold run executes the whole thing, while skaffold render emits hydrated Kubernetes manifests for a GitOps workflow, according to the README's CI/CD building blocks bullet. ## Installing Skaffold and running your first skaffold dev loop The README points at the install page on skaffold.dev and at the GitHub Releases page for release info or a specific version. It does not reproduce per-platform commands in the README itself, so treat the install page as the source of truth for your platform. Once the binary is on your PATH, the first thing worth running is a version check, because Skaffold's behaviour and config schema have moved across major versions. ```bash skaffold version ``` You should see the version string of the installed binary. If the command is not found, the binary is not on your PATH yet. From a project directory, the README's own path is to let Skaffold discover your files and write its config. Run init and answer its prompts: ```bash skaffold init ``` According to the README, this generates Skaffold's own config file after discovering your files. The result is a skaffold.yaml at the repository root. The repository ships examples/annotated-skaffold.yaml, which is the reference to read once the generated file exists. With a config in place and a kubeconfig context pointing at the cluster you intend to use, start the continuous loop: ```bash skaffold dev ``` This is the command the README's feature list describes: it detects source changes, builds, pushes and deploys, then streams logs and forwards ports. Leave it running while you edit; stop it with Ctrl+C when you are done. For a one-shot pass with no watching, the README names skaffold run instead. ## Where Skaffold stops being the right tool The client-side-only design is the source of both its lightness and its limits. There is no cluster-side component, so nothing reconciles your cluster back to the declared state when your laptop is closed. If a pod is deleted at 3am, Skaffold is not the thing that notices. That is a deliberate trade the README states as a benefit ("no overhead or maintenance burden"), and it is also the boundary: Skaffold is a development and pipeline tool, not a runtime controller. The README does not document rollback. If a deploy leaves the cluster in a bad state, no mechanism for Skaffold to undo it is described, and no flag for it is listed. Teams that need automatic rollback have to get it from the deploy layer they chose, not from Skaffold. Build correctness is another boundary. The README says Skaffold integrates with any build tool, which means the tool you point it at has to be installed and working on the machine running Skaffold. A misconfigured builder fails before Kubernetes is involved at all, and Skaffold will not diagnose your Dockerfile for you. Finally, the project's own go.mod shows heavy version pinning, including replace directives for k8s.io/client-go, k8s.io/api and k8s.io/apimachinery at v0.33.4 and a pinned go-containerregistry. That is normal for a tool that must track Kubernetes APIs, but it means dependency bumps are not casual. The repository also carries a deprecation-policy.md and links a Deprecation Policy page, which is a signal that config surface does change over time and you should read that policy before pinning your team to a version. ## Skaffold vs Helm, Tilt and Argo CD: different layers, not substitutes The comparison people reach for is Skaffold vs Helm, and the honest answer is that they operate at different layers. Helm is a packaging and templating format for Kubernetes manifests. Skaffold is the loop that builds your image and then applies manifests. The repository itself demonstrates the combination: examples/helm-deployment and examples/helm-deployment-dependencies exist, so Skaffold can drive a Helm deploy rather than replace it. If your problem is "my charts are a mess", Helm is the subject. If your problem is "I rebuild and reapply by hand twenty times a day", that is Skaffold's subject. Against Tilt, the difference in approach is the pipeline model. Skaffold describes its pipeline as opinionated and minimal, with declarative config and pluggable builders and deployers. Tilt is a live-update oriented development server. The practical distinction for a team is what the config file has to express: Skaffold's config is the same artifact you can feed into CI through skaffold run and skaffold render. Against Argo CD, the split is even cleaner. Argo CD is a cluster-resident GitOps controller that continuously reconciles a cluster against a Git repository. Skaffold has no cluster-side component at all. The README positions skaffold render as the bridge: it outputs hydrated manifests that a GitOps workflow can consume. So the two can sit in the same delivery chain, with Skaffold producing the manifests and Argo CD keeping them applied. ## Maintenance, upgrades and what the Apache-2.0 licence means here The repository is not archived, and the last push was on 2026-07-23, which is roughly two months before this article. Recent releases are close together: v2.22.0 on 2026-06-08, v2.23.0 on 2026-06-26 and v2.24.0 on 2026-07-23. That cadence is the upgrade cost you are signing up for. Skaffold has to track Kubernetes client libraries, and the go.mod pins k8s.io/api, k8s.io/client-go, k8s.io/apimachinery and k8s.io/kubectl at v0.33.4 through replace directives. A cluster that moves ahead of the client libraries Skaffold was built against is where you will feel it. Skaffold is licensed under Apache-2.0, and the LICENSE file sits at the repository root. In practical terms that is a permissive licence that allows commercial use and modification, with the usual notice and attribution conditions. It also includes an explicit patent grant, which is the reason some organisations prefer it over MIT for infrastructure tooling. This is a description of the licence text, not legal advice; have your own counsel read it if the distinction matters to your organisation. On support, the README states that Skaffold is generally available and considered production ready, and points to a Deprecation Policy for feature maturity and how features are retired. Security advisories are managed through GitHub's advisory system, per the README's security section. The repository's top level also carries a ROADMAP.md and a deprecation-policy.md, so the project publishes both forward direction and removal rules. Neither document is summarised in the README, so read them directly before a major upgrade. ## Conclusion Adopt Skaffold if your team already has Dockerfiles or Buildpacks and wants one skaffold.yaml to drive build, push and deploy on any cluster, including CI via skaffold run and skaffold render. Do not adopt it if you need a cluster-resident reconciler that repairs drift while nobody is watching, or if you expect the tool to roll a bad deploy back on its own; the README does not document rollback. Verify first that your chosen builder is installed and reachable (Docker, Buildpacks or another supported builder), that your kubeconfig context points at the intended cluster, and that the deploy renderer you pick (kubectl, Helm or Kustomize) is present at the version your manifests expect. ## FAQ ### What is Skaffold used for? It is a command line tool for continuous development of Kubernetes applications. It detects changes in your source code and handles the pipeline to build, push and deploy your application, then aggregates logs and forwards container ports. ### What does "skaffold" mean? The README does not give an etymology for the name. It only describes what the tool does: it facilitates continuous development for Kubernetes applications by handling the build, push and deploy workflow. ### Is Skaffold free? Yes. Skaffold is licensed under Apache-2.0, and the LICENSE file is at the repository root. The README also states that Skaffold is generally available and considered production ready. ### What are the key differences between Skaffold and Tilt? Skaffold describes its pipeline as opinionated and minimal, with declarative, pluggable configuration for builders and deployers, and the same config can drive CI through skaffold run and skaffold render. The README does not describe Tilt's internals, so a feature-by-feature comparison is not possible from it. ### How do I install Skaffold on Windows or macOS? The README does not list per-platform install commands. It points to the install page on skaffold.dev and to the GitHub Releases page for release info or to install a specific version, so those are the two places to follow for your platform. ### What is skaffold build? Building is one phase of the pipeline Skaffold runs. The README states that Skaffold detects changes in your source code and handles the pipeline to build, push and deploy automatically with policy based image tagging, and that individual Skaffold phases can be used to build up a CI/CD pipeline. ## Sources - [Official documentation](https://skaffold.dev/) - [Official README](https://github.com/GoogleContainerTools/skaffold#readme) - [Project repository](https://github.com/GoogleContainerTools/skaffold) - [Release notes](https://github.com/GoogleContainerTools/skaffold/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/googlecontainertools-skaffold