# Weave GitOps: a UI and CLI on top of Flux for teams without Kubernetes expertise > Weave GitOps layers an application dashboard, a Graph view of resource relationships and a gitops CLI over Flux as the GitOps engine, and the project is transitioning to community driven. Its default stack is Flux, Kustomize, Helm, Sops and Kubernetes CAPI, and the newest tagged release is still a release candidate. **weaveworks/weave-gitops** — Weave GitOps is transitioning to a community driven project! It provides insights into your application deployments, and makes continuous delivery with GitOps easier to adopt and scale across your teams. - Repository: https://github.com/weaveworks/weave-gitops - Website: https://docs.gitops.weaveworks.org/ - Stars: 1,132 · Forks: 166 - Language: MDX - License: Apache-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/weaveworks-weave-gitops ## What the open source edition gives you Weave GitOps describes itself as a simple, open source developer platform for people who want cloud native applications but do not have Kubernetes expertise. The pitch is that you can enable GitOps and run your apps in a cluster, use Git to collaborate with team members, and then extend into defining and running your own enterprise platform. From Kubernetes it gives three things. Application Operations, which is managing and automating deployment pipelines for apps and more. Platforms, described as the easy way to have your own custom PaaS on cloud or on premise. And Extensions, which coordinate Kubernetes rollouts with things outside the cluster, for example VMs, databases and cloud services. The listed open source capabilities are concrete. Continuous Delivery through GitOps for apps and infrastructure. Support for GitHub, GitLab and Bitbucket, S3-compatible buckets as a source, all major container registries and all CI workflow providers. A secure pull-based mechanism operating with the least amount of privileges and adhering to Kubernetes security policies. Compatibility with any conformant Kubernetes version and common ecosystem technologies such as Helm, Kustomize, RBAC, Prometheus, OPA and Kyverno. Multitenancy with multiple Git repositories and multiple clusters. And alerts and notifications. The defaults matter for how you evaluate it. Weave GitOps defaults to Flux as the GitOps engine, with Kustomize, Helm, Sops and Kubernetes CAPI. The README says that if you use Flux already, you can easily add Weave GitOps to create a platform management overlay, which tells you the intended relationship: Flux reconciles, Weave GitOps observes and manages on top. ## The views that make a cluster legible The screenshot sequence in the README is effectively a feature list, because each view answers a different question. The application page manages and views applications in one place. The reconciliation page shows continuous deployments and what is being produced via GitOps, with multiple views for debugging and the ability to sync your latest Git commits directly from the UI. The Graph view is called out separately with its own heading, which suggests it is the piece the project wants people to try. The yaml view lets you review the manifest for a resource. The sources view shows everything you pull from, whether that is a git repository, a helm repository or a bucket. And the Flux runtime view shows the health of the reconciliation deployment runtime, the workers that ensure your software is running on the cluster. That last one is the view that solves a recurring operational problem. When a sync does not happen, the first question is usually whether the Flux controllers are healthy at all, and having the runtime health in the same UI as the application avoids a round trip to kubectl. The Graph view is the one to try first. Resource relationships in a cluster are hard to hold in your head, and a graph of what references what is the kind of view that changes how you debug, particularly when the same deployment touches a namespace, a secret, a config map and a workload. ## Installing the gitops CLI on macOS and Linux The CLI installation is a three line shell sequence that pulls a release tarball and moves the binary into place. ```console curl --silent --location "https://github.com/weaveworks/weave-gitops/releases/download/v0.39.0-rc.2/gitops-$(uname)-$(uname -m).tar.gz" | tar xz -C /tmp sudo mv /tmp/gitops /usr/local/bin gitops version ``` The archive name is built from uname and uname -m, so the same command works across macOS and Linux machines with different architectures. Homebrew is the alternative. ```console brew tap weaveworks/tap brew install weaveworks/tap/gitops ``` Note which version the curl command references. It points at v0.39.0-rc.2, a release candidate from 2025-02-25, while the newest tag in the repository is v0.39.1-rc.1 from 2026-01-25. So the documented command is not the newest artefact, and the gitops version command in the same sequence is how you confirm what you actually installed, and the CLI reference describes that command as showing the version along with commit, branch and flux version. ## What the gitops CLI can and cannot do The CLI reference in the README lists the command set, and the shape of it tells you where the product is pointed. ```console Available Commands: beta This component contains unstable or still-in-development functionality check Validates flux compatibility completion Generate the autocompletion script for the specified shell create Creates a resource get Display one or many Weave GitOps resources help Help about any command version Display gitops version ``` The command set is small, and the descriptions are the honest part. The command descriptions are generic verbs, so the interesting detail is in the flags. Several flags are about talking to Weave GitOps Enterprise rather than to your cluster. The endpoint flag is the Weave GitOps Enterprise HTTP API endpoint, and it can be set with the WEAVE_GITOPS_ENTERPRISE_API_URL environment variable. The username and password flags are the Enterprise credentials, settable with WEAVE_GITOPS_USERNAME and WEAVE_GITOPS_PASSWORD. Two flags are about your cluster. The kubeconfig flag takes a path and is only required if you are out of cluster. The namespace flag scopes the operation, and the default is flux-system, which is the namespace Flux itself runs in. One flag deserves care. The insecure-skip-tls-verify flag means the server's certificate will not be checked for validity, which the help text itself says will make your HTTPS connections insecure. That is fine against a development cluster with a self signed certificate and wrong for anything else. There is a beta command, described as containing unstable or still-in-development functionality, which is where the more speculative surface lives. ## A community transition, a pre-1.0 release and a mixed stack The project description leads with a status note rather than a feature: Weave GitOps is transitioning to a community driven project. That is the single most important fact for anyone considering a dependency, and it is not hidden. The release tags support a version of that story. The recent releases are v0.39.1-rc.1 from 2026-01-25, v0.39.0-rc.2 from 2025-02-25 and 0.39.0-rc.1 from 2025-02-04, named Rising Phoenix. Every one of them is a release candidate, and the version in the root package.json is 0.39.1-rc.1, matching the newest tag. The last push was on 2026-10-15 and the repository is not archived, so work continues even though tagged releases are sparse and pre-1.0. The stack in the repository is as mixed as the project. There is a Go side, with go.mod, cmd/, pkg/, core/ and api/ directories, and a TypeScript side, with ui/, website/ and yarn.lock, a.yarnrc.yml, package.json, babel config, jest config and setup-jest.ts. The ui/ directory is the application dashboard, built with Parcel given the.parcelrc file, and the default build target in package.json points at ui/index.html with an output directory of bin/dist. There are two Dockerfiles, gitops.dockerfile and gitops-server.dockerfile, plus a dev.dockerfile, and a Tiltfile for local development. The api/ directory has buf.yaml and buf.lock, so gRPC schemas are managed with buf, and the.golangci.yaml,.protolint.yaml and.prettierignore files show separate linting for the Go, protobuf and web sides. The licence is Apache-2.0, and the repository carries SECURITY.md, CODE_OF_CONDUCT.md, a DCO file, a MAINTAINERS file and a Conventional Commits setup with commitlint.config.mjs. The DCO plus commitlint combination means contributions are expected to be sign-off clean and to follow a structured commit message format, which is a reasonable signal about how a community run project expects to work. ## Conclusion Adopt Weave GitOps if you run Flux already and want a dashboard, a Graph view and a CLI for understanding what your clusters are actually doing, since it deliberately treats Flux rather than replacing it as the engine. Do not adopt it as a first GitOps tool, because the README positions it for teams that already use cloud native applications but lack Kubernetes expertise, and it assumes Flux and a conformant cluster are present. Verify first which release you install, since the newest tags are v0.39.1-rc.1 and v0.39.0-rc.2 release candidates, and check the project status in the README because Weave GitOps is transitioning to a community driven project. ## FAQ ### How do I install the Weave GitOps CLI? On Mac or Linux, download the release tarball named gitops-$(uname)-$(uname -m).tar.gz with curl and untar it into /tmp, then move the binary to /usr/local/bin with sudo and run gitops version. Homebrew is the alternative, using brew tap weaveworks/tap and brew install weaveworks/tap/gitops. ### Does Weave GitOps replace Flux? No. The README says Weave GitOps defaults to Flux as the GitOps engine, along with Kustomize, Helm, Sops and Kubernetes CAPI, and that if you already use Flux you can add Weave GitOps to create a platform management overlay on top of it. ### What does the gitops check command do? The CLI reference describes check as validating flux compatibility. The command set also includes get to display Weave GitOps resources, create to create a resource, completion to generate a shell autocompletion script, version, and a beta command for unstable functionality. ### Which Git providers and clusters does Weave GitOps support? The open source edition lists support for GitHub, GitLab and Bitbucket, S3-compatible buckets as a source, all major container registries and all CI workflow providers, plus multitenancy with multiple Git repositories and multiple clusters, and compatibility with any conformant Kubernetes version. ## Sources - [License: Apache-2.0](https://github.com/weaveworks/weave-gitops/blob/main/LICENSE) - [Project website](https://docs.gitops.weaveworks.org/) - [README](https://github.com/weaveworks/weave-gitops/blob/main/README.md) - [Releases](https://github.com/weaveworks/weave-gitops/releases) - [weaveworks/weave-gitops on GitHub](https://github.com/weaveworks/weave-gitops) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/weaveworks-weave-gitops