GitOps for k8s
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Michael Bridgen 96afd8df48
Merge pull request #1606 from weaveworks/issue/1560-check-for-chart-exist
1 day ago
.circleci Add makefile target for verifying generated code 1 month ago
.github Soften the changelog requirement for PRs 1 month ago
api Actually return the SyncError for controllers 3 weeks ago
bin Bump to kubeyaml 0.5.1 to fix (F)HR updating 1 month ago
chart Add timeout validation to HelmRelease instead of FHR 1 week ago
checkpoint making compiling work on raspberry pi's 1 month ago
cluster Bump to kubeyaml 0.5.1 to fix (F)HR updating 1 month ago
cmd A few more updates to verbose output 5 days ago
daemon Reindent test file 1 day ago
deploy Add container resources requests for Flux and helm-op - set requests to 10m CPU and 64Mi memory to prevent Flux containers from being scheduled on exhausted nodes 3 weeks ago
deploy-helm Add helm release install/upgrade timeout to CRD 2 weeks ago
docker Bump baked-in kubectl to 1.11.3 1 month ago
errors Downgrade non-specific errors to application-level 10 months ago
event Fix typo: should be ReleaseContainersSpec instead of ReleaseImageSpec 1 month ago
git Use golang idiomatic short if statement 2 weeks ago
guid Make new subscriptions kick old subscriptions 2 years ago
http Add events for container release For ReleaseEventMetadata use spec with both types: ReleaseImageSpec and ReleaseContainersSpec 1 month ago
image Include parsed string in error for ParseRef() 2 months ago
integrations Check that chart exists when updating its deps 1 day ago
internal_docs Update doc on release process 1 month ago
job Break dependencies among git, job, event packages 8 months ago
metrics Standardize http metrics, to flux_request_duration 1 year ago
policy Remove spurious ServicesWithPolicies 4 months ago
registry Break update on context cancel and set wait group increment after the select 3 weeks ago
release Fix tests 1 month ago
remote Add HelmRelease to the kinds supported in RPC 1 month ago
resource Verify releases with a model comparison 6 months ago
site Make it clear Slack integration uses a service 1 week ago
ssh Generate keys in a separate tmpfs volume 9 months ago
sync Move sync error tracking to Cluster 1 month ago
test Keep current-context 1 year ago
update Add events for container release For ReleaseEventMetadata use spec with both types: ReleaseImageSpec and ReleaseContainersSpec 1 month ago
.gitignore Basic integration tests 1 year ago Changelog entry for Helm operator 0.5.1 4 weeks ago Add note re kubectl version to changelog 1 month ago Move code of conduct into its own file. 2 months ago add note about where to find GH issues as first-time contributor 3 months ago
DCO docs: steal and DCO docs from scope, modify slightly 3 months ago
Gopkg.lock Wait for connection to Tiller to succeed, on start 1 month ago
Gopkg.toml Wait for connection to Tiller to succeed, on start 1 month ago
LICENSE Initial commit 2 years ago
MAINTAINERS Add Slack handles to MAINTAINERS 2 months ago
Makefile Merge pull request #1562 from mgazza/feature/1560-helm-op-add-tests 1 day ago Fix Typo 2 weeks ago
flux.go Allow colons in the name component of resource IDs 4 months ago
lint Basic circle.yml, respecting Glide etc. 2 years ago
resourceid_test.go Allow colons in the name component of resource IDs 4 months ago


We believe in GitOps:

  • You declaratively describe the entire desired state of your system in git. This includes the apps, config, dashboards, monitoring and everything else.
  • What can be described can be automated. Use YAMLs to enforce conformance of the system. You don’t need to run kubectl, all changes go through git. Use diff tools to detect divergence between observed and desired state and get notifications.
  • You push code not containers. Everything is controlled through pull requests. There is no learning curve for new devs, they just use your standard git PR process. The history in git allows you to recover from any snapshot as you have a sequence of transactions. It is much more transparent to make operational changes by pull request, e.g. fix a production issue via a pull request instead of making changes to the running system.

Flux is a tool that automatically ensures that the state of a cluster matches the config in git. It uses an operator in the cluster to trigger deployments inside Kubernetes, which means you don’t need a separate CD tool. It monitors all relevant image repositories, detects new images, triggers deployments and updates the desired running configuration based on that (and a configurable policy).

The benefits are: you don’t need to grant your CI access to the cluster, every change is atomic and transactional, git has your audit log. Each transaction either fails or succeeds cleanly. You’re entirely code centric and don’t need new infrastructure.

Deployment Pipeline

CircleCI GoDoc

What Flux does

Flux is most useful when used as a deployment tool at the end of a Continuous Delivery pipeline. Flux will make sure that your new container images and config changes are propagated to the cluster.


Its major features are:

Relation to Weave Cloud

Weave Cloud is a SaaS product by Weaveworks that includes Flux, as well as:

  • a UI and alerts for deployments: nicely integrated overview, all Flux operations just a click away.
  • full observability and insights into your cluster: Instantly start using monitoring dashboards for your cluster, hosted 13 months of history, use a realtime map of your cluster to debug and analyse its state.

If you want to learn more about Weave Cloud, you can see it in action on its homepage.

Get started with Flux

Get started by browsing through the documentation below:


As Flux is Open Source, integrations are very straight-forward. Here are a few popular ones you might want to check out:

Community & Developer information

We welcome all kinds of contributions to Flux, be it code, issues you found, documentation, external tools, help and support or anything else really.

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting a Flux project maintainer, or Alexis Richardson <>. Please refer to our code of conduct as well.

To familiarise yourself with the project and how things work, you might be interested in the following:

Getting Help

If you have any questions about Flux and continuous delivery:

Your feedback is always welcome!