Skip to main content
Version: 0.3.1

Getting Started

Let's get an app deployed with Weave GitOps.

This is Work In Progress

Follow our workshops where we go through these steps!


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 and Gitlab.

Other Git providers are coming soon.

To follow along with this guide you will need:

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

Install the Weave GitOps 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:
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 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.yaml2 directories, 7 files
  1. Let's enable GitOps for this workload
gitops app add .

You should see something like:

โ—Ž Checking cluster statusโœ” GitOps installed
Visit this URL to authenticate with Github:
Type the following code into the page at the URL above: ABCD-1234
Waiting for authentication flow completion...

Copy the code and visit the URL shown to grant temporary repo access for Weave GitOps.

device flow activation

You should then see this confirmation:

device flow complete

Once complete, the process will continue and you will see something like:

Authentication successful!
uploading deploy keyDeploy key generated and uploaded to git providerAdding application:
Name: nginxURL: ssh:// ./Branch: mainType: kustomize
โœš Generating Source manifestโœš Generating GitOps automation manifestsโœš Generating Application spec manifestโ–บ Cloning ssh:// Request created: <link to PR>
โ–บ Applying manifests to the clusterโ–บ Committing and pushing gitops updates for applicationโœ” App is up to date
  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 gitops app status command to see the reconciliation.
gitops 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. gitops 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 gitops 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
gitops 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.