Skip to main content
Version: 0.2.1

Getting Started

Let's get an app deployed with Weave GitOps.

This is Work In Progress


In this short guide, we will see how to get a simple workload running in a cluster using GitOps, and then make a change to that deployment and see it updated automatically via GitOps. Further guides will then show how to move that workload into staging and/or production.


This guide is for Mac and Linux only (so far!). At the moment, Weave GitOps supports Github.

Gitlab and other Git providers are coming soon.

To get this working you need:

  1. A Github account
  2. A Github token
  3. kubectl installed instructions
  4. A development Kubernetes cluster (this guide uses kind)
  5. Kind requires Docker

Github Token#

You need a Github Token with repo access.

If you don't already have one, please follow the Github guide

Make sure that the token is in your environment as GITHUB_TOKEN

Install the CLI#

Please follow the instructions in the CLI installation page to install the command-line tool.

Getting Started with a Kind cluster and Podinfo workload#

Create the cluster#

  1. Create a fresh kind cluster:
kind create cluster
Creating cluster "kind" ... โœ“ Ensuring node image (kindest/node:v1.20.2) ๐Ÿ–ผ โœ“ Preparing nodes ๐Ÿ“ฆ โœ“ Writing configuration ๐Ÿ“œ โœ“ Starting control-plane ๐Ÿ•น๏ธ โœ“ Installing CNI ๐Ÿ”Œ โœ“ Installing StorageClass ๐Ÿ’พSet kubectl context to "kind-kind"You can now use your cluster with:
kubectl cluster-info --context kind-kind
Have a nice day! ๐Ÿ‘‹

You now will have the right kubeconfig for the kind cluster.

Run kubectl cluster-info --context kind-kind

Install Weave GitOps onto the cluster#

  1. Install Weave GitOps into the currently active Kubernetes cluster:
wego gitops install

You should see:

โœš generating manifestsโœ” manifests build completedโ–บ installing components in wego-system namespaceโ—Ž verifying installation

The install will pause while the containers are loaded into the cluster. (roughly 1 to 2 minutes depending on your system)

Once the system is verified you will see:

โœ” image-reflector-controller: deployment readyโœ” image-automation-controller: deployment readyโœ” source-controller: deployment readyโœ” kustomize-controller: deployment readyโœ” helm-controller: deployment readyโœ” notification-controller: deployment readyโœ” install finished
  1. You can see what has been installed:
kubectl get pods --namespace wego-system
NAME                                           READY   STATUS    RESTARTS   AGEhelm-controller-69667f94bc-ngpwv               1/1     Running   0          113simage-automation-controller-6cd8b8fb95-ktgz7   1/1     Running   0          113simage-reflector-controller-55fb577bf9-bhs2b    1/1     Running   0          113skustomize-controller-6977b8cdd4-6p762          1/1     Running   0          113snotification-controller-5c4d48f476-nwrkx       1/1     Running   0          112ssource-controller-b4b88948f-kz2lr              1/1     Running   0          112s

Configure Weave GitOps to reconcile the workload automatically#

First we will fork a basic workload repository, then we will add the wego GitOps automation to deploy into the cluster

Fork and clone the Podinfo repository#

We are going to use a deployment of the podinfo sample Kubernetes app as the workload to test.

Please note that these instructions do not use the base podinfo repository, but a specific repository containing only the deployment YAML

  1. Fork the following repository on Github:


  1. Clone the fork using SSH (replacing <yr-org-goes-here>)
git clone<yr-org-goes-here>/podinfo-deploy.git

(Note Weave GitOps doesn't support repositories that are cloned via HTTPS)

  1. Change directory into the path where you cloned your fork of podinfo-deploy - for example:
cd podinfo-deploy

This repository only contains Kubernetes YAMLs (and a README):

.โ”œโ”€โ”€ README.mdโ”œโ”€โ”€ backendโ”‚ย ย  โ”œโ”€โ”€ deployment.yamlโ”‚ย ย  โ”œโ”€โ”€ hpa.yamlโ”‚ย ย  โ””โ”€โ”€ service.yamlโ”œโ”€โ”€ frontendโ”‚ย ย  โ”œโ”€โ”€ deployment.yamlโ”‚ย ย  โ””โ”€โ”€ service.yamlโ””โ”€โ”€ namespace.yaml
2 directories, 7 files
  1. Let's enable GitOps for this workload
wego app add .

You should see something like:

Updating parameters from environment... using URL: 'ssh://' of origin from git config...
Checking cluster status... WeGOInstalled
Generating deploy key for repo ssh:// ...uploading deploy keyGenerating Source manifest...Generating GitOps automation manifests...Generating Application spec manifest...Applying manifests to the cluster...Writing manifests to disk...Pull Request created: <link to PR>

(PLEASE NOTE: the 0.2.0 version does not print the link to the PR. However, it is creating the PR. )

  1. A Pull Request has been created against the git branch.


Go to your Github fork and merge the Pull Request.


Once you have merged the PR it should look like this: Merge Complete

  1. Once the PR is merged wait for the workload to show up in the cluster:
kubectl get pods --namespace test
NAME                        READY   STATUS    RESTARTS   AGEbackend-66b5655895-ms79n    1/1     Running   0          42sfrontend-7fb9f4bf99-qmkqh   1/1     Running   0          42s
  1. You can use the wego app status command to see the reconciliation.
wego app status podinfo-deploy
Latest successful deployment time: 2021-06-29T14:41:14ZNAMESPACE   NAME                            READY   MESSAGE                                                         REVISION                                        SUSPENDEDwego-system gitrepository/podinfo-deploy    True    Fetched revision: main/cb6fc97b304740347e1d98195bc3d972ee07d733 main/cb6fc97b304740347e1d98195bc3d972ee07d733   False
NAMESPACE   NAME                            READY   MESSAGE                                                         REVISION                                        SUSPENDEDwego-system kustomization/podinfo-deploy    True    Applied revision: main/cb6fc97b304740347e1d98195bc3d972ee07d733 main/cb6fc97b304740347e1d98195bc3d972ee07d733   False

This shows you when the last deployment was as well as the specific SHA from Git that has been deployed.

You have successfully deployed the app!

  1. wego app add will have created a .wego directory in your repository (you can configure where this goes - see GitOps Automation configuration)

This directory contains the GitOps Automation configuration.

If you do a tree inside this directory you should see something like:

$ tree .wego/.wego/โ”œโ”€โ”€ appsโ”‚ย ย  โ””โ”€โ”€ podinfo-deployโ”‚ย ย      โ””โ”€โ”€ app.yamlโ””โ”€โ”€ targets    โ””โ”€โ”€ kind-kind        โ””โ”€โ”€ podinfo-deploy            โ””โ”€โ”€ podinfo-deploy-gitops-runtime.yaml
5 directories, 2 files

You can find out more about these YAMLs and the .wego directory here.

Notice that wego has checked in this YAML into your fork (This will change in a future release to create a PR against your repository instead).

  1. To access the podinfo UI you can set up a port forward into the pod.
kubectl port-forward service/frontend 9898:9898 --namespace test
Forwarding from -> 9898Forwarding from [::1]:9898 -> 9898

NB: This command does not return

Now you can browse http://localhost:9898

You should see something like:


Use CTRL+C to cancel the kubectl port-forward command to continue with your command prompt.

See GitOps reconciliation#

  1. The real aim of GitOps is not just to deploy once, but to reconcile as well. Let's test that out. Edit frontend/deployment.yaml

Change the PODINFO_UI_COLOR to grey:

        env:        - name: PODINFO_UI_COLOR          value: "#888888"
  1. Commit the change to your forked repository.
git add .git commit -m "change color"git push

(If you want an even better experience, create a PR and then merge!)

  1. Wait for the reconciliation to take place
wego app status podinfo-deploy
Latest successful deployment time: 2021-06-09T10:36:26ZNAMESPACE   NAME                            READY   MESSAGE                                                         REVISION                                        SUSPENDEDwego-system gitrepository/podinfo-deploy    True    Fetched revision: main/0927f4649817186103f14612bd3a0426d21de601 main/0927f4649817186103f14612bd3a0426d21de601   False
NAMESPACE   NAME                            READY   MESSAGE                                                         REVISION                                        SUSPENDEDwego-system kustomization/podinfo-deploy    True    Applied revision: main/0927f4649817186103f14612bd3a0426d21de601 main/0927f4649817186103f14612bd3a0426d21de601   False
  1. You should see the pods recycle
kubectl get pods --namespace test
NAME                       READY   STATUS              RESTARTS   AGEbackend-5cd878f8dd-rl64h   1/1     Running             0          33mfrontend-5c45876f-pnxrq    1/1     Running             0          6m51sfrontend-ff74574fc-7ntw4   0/1     ContainerCreating   0          1s

And a little later:

NAME                       READY   STATUS        RESTARTS   AGEbackend-5cd878f8dd-rl64h   1/1     Running       0          34mfrontend-5c45876f-pnxrq    0/1     Terminating   0          7m9sfrontend-ff74574fc-7ntw4   1/1     Running       0          19s

Notice that the backend has not changed and so the backend pod is not affected.

Restart the kubectl port-forward and you will see the color has changed.

(If you use a real ingress then you wouldn't need to do this).

  1. Congratulations

You have successfully demonstrated GitOps using Weave GitOps! Well done.