How to automate deployments on DOKS with ArgoCD?

How To Setup Automated Deployments using ArgoCD on DigitalOcean Kubernetes


Developing applications on Kubernetes has taken off over the last few years. Kubernetes has helped developers realize the potential of containerized application deployment paradigms. Though containerized development has changed the tools and ways people deploy applications, it has not replaced the need for streamlined integration and deployment. Having a proper deployment pipeline can be the difference between releasing that killer feature today and 4 weeks from now.

In this tutorial, we are going to set up a simple continuous deployment pipeline on DigitalOcean Kubernetes to enable automated deployments for your project.


Before you begin this guide you’ll need the following:

  • A DigitalOcean Kubernetes cluster with your connection configured as the kubectl default. Instructions on how to configure kubectl are shown under the Connect to your Cluster step when you create your cluster. To create a Kubernetes cluster on DigitalOcean, see Kubernetes Quickstart.
  • Github account
  • Helm chart

Step 1 — Installing the argocd CLI

ArgoCD provides us with a UI but I find it much simpler and more convenient when writing code to make use of its command line interface (CLI). The instructions for installing it are simple and can be found here

For Linux you can perform the following in a bash shell:

This command will query the argo repository for the latest release version and set a local variable equal to that version number.

  1. VERSION=$(curl --silent "" | grep '"tag_name"' | sed -E 's/.*"([^"]+)".*/\1/')

This command will then download the version of the argocd binary that we retrieved from the previous command and and save the binary as /usr/local/bin/argocd.

  1. curl -sSL -o /usr/local/bin/argocd$VERSION/argocd-linux-amd64

Finally we need to ensure that we give execute permissions to the newly downloaded binary:

  1. chmod +x /usr/local/bin/argocd

We now can run argocd commands however we need to configure our client binary to talk to our ArgoCD service. We will configure that in the next step.

Step 2 — Installing ArgoCD in your Kubernetes Cluster

We will be using ArgoDC as our CICD tool. Luckily for us ArgoCD is very simple to install! You can see the official instructions here. But for simplicity I will provide them below:

Lets create the namespace for ArgoCD to live in:

  1. kubectl create namespace argocd

Then we can create all of the ArgoCD manifests in our namespace using the command:

  1. kubectl apply -n argocd -f

For simplicity I am going to expose this argo service locally in a separate terminal using the following command:

  1. kubectl -n argocd port-forward svc/argocd-server -n argocd 8080:443

This command takes the argoCD service port and proxies it to my local machine on port 8080. I can now access the service by simply querying http://localhost:8080.

Now we are going to authenticate our argocd commandline interface we installed earlier.

We can get the default password for the argocd server using the command here:

  1. kubectl get pods -n argocd -l -o name | cut -d'/' -f 2

This should output what looks like the name of a pod and thats because it is. It will double as the initial password to authenticate as the admin user. We now can authenticate using this command:

  1. argocd login localhost:8080 --insecure --username admin

You should see output similar to the following:

'admin' logged in successfully Context 'localhost:8080' updated

The --insecure flag is used here because our service is not setup with SSL certificates to authenticate the server. This is outside the scope of this tutorial but is recommended for production installs.

You can get instructions on configuring ArgoCD with TLS in their documentation.

We now should have the basics of argoCD installed in our cluster and the service exposed at localhost:8080. Though there’s not much we can really do with it yet until we have a application to deploy with it. In the next steps we are going to tell argocd about our application so that it can configure our deployments.

Step 3 — Creating the Application

ArgoCD can help us deploy our applications in a repeatable way. This can make for an automated and rather seamless deployment pipeline. ArgoCD is capable of working with both plain git repos as well as helm charts. In this tutorial we will be deploying a helm chart.

If you do not have a helm chart in a repository you can perform the following:

  • Download an NGINX helm chart.
  • Extract the files from the tar of your choice version of NGINX.
  • Push all the files up to a git based repo so that your repository looks like the below structure:
> tree . ├── Chart.yaml ├── ci │ ├── daemonset-customconfig-values.yaml ... │ └── deployment-webhook-values.yaml ├── OWNERS ├── ├── templates │ ├── admission-webhooks │ │ ├── job-patch │ │ │ ├── clusterrolebinding.yaml │ │ │ ... │ │ │ └── serviceaccount.yaml │ │ └── validating-webhook.yaml │ ├── clusterrolebinding.yaml │ ├── clusterrole.yaml ... │ ├── _helpers.tpl │ └── NOTES.txt └── values.yaml

Once you have that in your repository using git push you will be ready to continue!

The first thing we need to do is tell ArgoCD about our application so it knows where the helm chart lives. We can accomplish this using the argocd app create command like so:

** Note: ** Your --repo value will be different.

  1. argocd app create helm-nginx --repo --path . --dest-namespace default --dest-server https://kubernetes.default.svc --helm-set-string 'app=helm-nginx' --self-heal --sync-policy auto

Lets break down what this is doing.

argocd app create Is telling the argo server that we would like to create and app for the ArgoCD server to track and manage. helm-nginx is the arbitrary name I decided on for my application. This value could be any meaningful description you choose. --repo is the git repository that my helm chart can be found in. If we want ArgoCD to be deploying our helm chart we have to tell ArgoCD where the chart can be found! --path is the path within the repository where the helm chart lives. My helm chart is not nested in a directory but exists at the root of the repository so here I just provide the path as .. --dest-namespace default is the Kubernetes namespace that I would like the application to be deployed into. --dest-server is the url to the kuberentes cluster we are using. If you have deployed the ArgoCD server within a Kubernetes cluster you can simply use https://kubernetes.default.svc to specify the cluster ArgoCD is deployed into. --helm-set-string is setting helm values on the Commandline if needed --self-heal is allowing argocd to self heal or auto deploy itself if it is found to be out of sync. --sync-policy setting this to auto will allow augocd to automatically sync the changes to the application.

After this command completes you should see output similar to the following:

application 'helm-nginx' created

We now have our app successfully created within ArgoCD! Once ArgoCD knows about your application, it can then start to do some more advanced tasks with it. In the next step we are going to be syncing the application that will deploy our chart into our Kubernetes cluster.

Step 4 — Syncing the application

Next we need to sync the application in ArgoCD. When we sync the application, ArgoCD is going to be comparing the git repository values and object definitions to what is currently deployed in the cluster. If it finds a difference between the definitions in the repository and the currently deployed objects, it will modify the objects in the cluster to reflect the configuration of the repository. Because we have only added the application to ArgoCD, you will see that the application is not yet Sync’d or deployed. We simply told ArgoCD about the application but we havent told ArgoCD to do anything with it yet. This is where sync comes in.

We currently have none of our helm chart deployed after completing step 1. To initiate a sync we can perform the following argocd command. This can take a few minutes to complete:

  1. argocd app sync helm-nginx

Alternatively, you could also achieve this using the ArgoCD web console. To do this simply you can expose the service locally. Using kubectl port-forward can be helpful for quickly exposing services via ports on your local machine:

  1. kubectl port-forward svc/argocd-server -n argocd 8080:443

Then you can access and login to your argoCD server by opening your browser and navigating to https://localhost:8080. This will be an insecure connection as we have not set up any certificates for the server. Any browser warning when accessing our server should be safe to ignore.

This should now bring your repository’s defined chart into your Kubernetes cluster. Though this is a very basic example this actually can be quite powerful for managing deployed applications and updating them. This methodology encourages the repository to be the source of truth and allows you to control and simplify your deployments by delegating that control to ArgoCD. However, it can be annoying to have to manually trigger deployments each time we make a change. In the next step we are going to configure a webhook to automatically tell Argo to about repository changes when we push code to the repository.

Step 5 – Configuring Git Webhooks

Too many developers are still using manual and troublesome deployment methods. There are so many variables that can affect deployment that it is no wonder some of the most dynamic and innovative companies have moved to some form of continuous deployment. Automating the deployment of your application can greatly increase the velocity in which you develop your application. Having a smooth and automated pipeline is crucial to timely and less error prone deployments. One way to implement a continuous deployment model is to automate deployments to trigger on a specific action. A good example action to trigger a deployment on would be a push to a git repository. This specifically would be helpful for a quickly developing git branch that will allow for quick test and QA feedback loops for developers. In this step we are going to configure automatic deployments by triggering ArgoCD’s Sync operation with git webhooks.

First navigate to you git provider. Under your repository’s settings page you should be able to find a section to configure webhooks for your repository. For your Payload URL specify where your ArgoCD server is accessible by your git provider.This URL could be or an IP such as

To expose your service via a LB you can use:

  1. kubectl -n argocd patch svc argocd-server -p '{ "spec": { "type" : "LoadBalancer" }}'

The Content-type should be set to application/json.

You also have the options to configure SSL validation (or to disable it) for your ArgoCD instance if you specify https:// in your URL.

Lastly you may want to use a shared secret to further secure your server. Setting a secret on a git webhook can help prevent against DDoS attacks if your Argo server is publicly avialable. To configure a webhooks secret enter an arbitrary secret value in your webhooks git provider. You then need to edit your Argo servers secret to let your server know what the value of the secret is. You can perform that using the steps outlined here.

Now that your webhooks is configured lets make a change and look into how this works!

Next we are going to trigger an automatic sync in ArgoCD by pushing a change to our repository. With the configured webhook our repository should notify ArgoCD that a change has occurred. We next need to enable automatic syncing to fully automate this process and allow argo to automatically rollout our changes.

Now that the sync policy is set we should be able to push a change. For example I am going to be changing my values.yml file to modify my image’s tag from latest to 1.16.

Now as long as a difference is detected by ArgoCD the sync process will occur. Go ahead and push a change to your helm chart and watch the automated magic!


In this article you created a helm chart that will automatically deploy your latest code changes automatically. You added webhooks to your git provider to tell ArgoCD about code changes, configured your app to an automated sync policy, and pushed a change to your repository to trigger a deployment.

This was a demonstration of the power of CICD and the time and reliability benefits of automating common deployment workflows. Now you can further tweak the configuration to fit your particular use cases. Be sure to poke around the ArgoCD Project docs for help and info on configuration options and other functionality. Also, check out the ArgoCD User Guide see all the great capabilities of ArgoCD!.

If you would like to do more with Kubernetes, head over to our Kubernetes Community page or explore our Managed Kubernetes service.

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.

Hi @jkwiatkoski, that’s good article, but I want ask some question I have 2 cluster in DOKS, cluster A(ArgoCD installed) and cluster B(used for cluster target)

my question “what is value of --dest-server if we need to set destination to cluster B?”

before I try with this value

  1. k8s master endpoint
  2. cluster id

but still not working, maybe you have solution for that, I appreciate, thanks.