Kubernetes CI/CD Pipelines: GitHub Actions with Devtron

Introduction

In the previous blog, we built a complete CI/CD pipeline using GitHub Actions, automating build, test, image creation, and deployment steps. We even secured the setup using a custom self-hosted runner to prevent KubeConfig exposure.

While GitHub Actions is powerful for Continuous Integration, it falls short in Continuous Deployment and Day-2 operations — such as drift detection, rollbacks, health monitoring, and advanced deployment strategies. Managing these with scripts and custom logic adds unnecessary complexity.

So, what if GitHub Actions could be paired with Devtron’s Kubernetes-native intelligence?
The result is a seamless, automated workflow that scales from CI through post-deployment operations.

GitHub Actions + Devtron = Continuous Integration meets Continuous Control.

Enhancing Kubernetes Deployments with Devtron

Devtron is a software delivery platform for Kubernetes, that helps you seamlessly create and manage Kubernetes deployments. It can help you manage the entire application lifecycle, integrate with different tooling from the Kubernetes ecosystem, help you troubleshoot and debug your applications, real-time status of workloads, SLO-based rollbacks, etc. You can create an end-to-end CI and CD pipeline within Devtron, and integrate various functionalities such as image scanning with Trivy.

Apart from several Devtron-Native integrations, you have the option to use several different plugins for defining some pre and post-CI actions. These plugins include dependency trackers for various tech stacks, integrating Sonarqube, k6 load testing, and many more.

For our purposes, we will be using the same application that we used in the previous blog. We already had set up a CI and CD pipeline. We are going to be using the same pipeline, and send the information of the newly created image to Devtron. Further, Devtron will then use the image to create the CD pipeline.

Creating a Continuous Deployment Pipeline with Devtron

Within Devtron, you have the option to create a CI and CD pipeline for your application. However, since we already have the CI pipeline set up with GitHub Actions, we can use an external webhook which can be used for triggering the deployment within Devtron. Let’s walk through the entire process of setting up an external webhook for the GitHub CI pipeline, and see what are the additional capabilities that Devtron enables us with.

Before proceeding please make sure that you have Devtron setup and is accessible through an external webhook API. The installation is pretty much straightforward with just helm commands. For more details, you can refer to the documentation on installing Devtron.

helm repo add devtron https://helm.devtron.ai

helm repo update devtron

helm install devtron devtron/devtron-operator \
--create-namespace --namespace devtroncd \
--set installer.modules={cicd} \
--set argo-cd.enabled=true

Also, make sure that you have the CI/CD and the GitOps integrations enabled if you want to have GitOps-based deployments. You can enable them from the Devtron Stack Manager.

On the Devtron Dashboard, we have to first create an application. Click on Create and create a Custom app from the Applications Dashboard.

We have to set a few configurations for this application. Give your application a name, and select which environment you want to deploy it to. Then click on Create. For this application, we will call it gin-app

After creating the application, there are certain application-specific configurations that we need to configure. The first thing to configure is to set up a Git Repository. We will point it to our gin-kv repository.

The next step is to set up a container registry. To set the container registry. You need to first add and authenticate to the Registry from the Global Configuration. Please check this doc to learn how to add a container registry to your Devtron Platform.

After adding the registry in the Global configurations, we can add the registry for the application.

If you have read the previous blog, we had to create our Kubernetes manifest files, i.e. Deployment, Service, and Ingress YAML files. Within Devtron, we do not need to create our own YAML files. It comes with a deployment template, which satisfies most of the use cases.

Within this Deployment template, you can easily configure ingress, PDB, HPA, KEDA, Service, etc, and the best part is, that you don't need to write and manage the Kubernetes manifests. Additionally, you don't even need to worry about API deprecations, or config changes as Devtron makes sure it's forward and backward-compatible with Kubernetes clusters which can also help you in cluster upgrades if the configurations are being managed through Devtron.

Now, let’s create the Deployment Pipeline. Within Devtron, you have the option to create the CI pipeline within Devtron itself. However, since we already have a pipeline created and configured, we will select the external pipeline option. Click on Deploy Image from External Service

After selecting the destination, you will have to set the deployment pipeline options. Within this pipeline, you have to configure the environment where you wish to deploy the application and the deployment strategy. You can also configure if you want to trigger the deployment manually, or automatically.

If you select the Automatic deployment, Devtron will trigger the deployment as soon as it receives the image from the external pipeline.

As we have chosen an external pipeline, Devtron is not aware of which pipeline we are using for the build. All Devtron cares about is the correct image. We will be providing this information to the Devtron pipeline using a webhook.

After clicking on the external pipeline from the workflow editor, you will see the configurations of the webhook. From the below image [Fig. 8], you can see that we already have a template for the curl request that needs to be sent by the GitHub pipeline.

Before the request can be made, we need to generate an Authentication token. If you have previously generated an API token in Devtron, you can use an existing token. If not, Devtron can auto-generate a token for you with the required permissions.

We are auto-generating a token named github-ci-token. To maintain good security practices, we will reference this token within the pipeline using a Secret variable.

Let’s create a new secret variable within the GitHub repository and its value will be the token generated by Devtron. We will call this token as DEVTRON_TOKEN and it will be referenced in the curl command which we run in the CI pipeline.

To create the token, head to the repository settings, and from Secrets and Variables, select Actions. Here you can create a secret variable.

Next, we want to put the curl command within the build and push action. As a quick recap, the Build and Push action builds the docker image and pushes it to DockerHub. We want to add a step within this job i,e sending a curl request to Devtron.

We can use the following YAML to create the new job.

      - name: Ping devtron server
        run: |
              curl --location --request POST \
              'http://35.184.124.194:31515/orchestrator/webhook/ext-ci/3' \
              --header 'Content-Type: application/json' \
              --header 'api-token: ${{ secrets.DEVTRON_TOKEN }}' \
              --data-raw '{
              "dockerImage": "siddhantkhisty/gin-kv:latest"
              }'

The above step sends the correct POST request to the Devtron CD pipeline. Notice that in the api-token section, we have referenced the secret variable that we created earlier. This ensures that the token is not leaked.

For the dockerImage field, we have defined the image name as well as the tag. If you want to have custom tags, you can use a tool such as Jinja to dynamically tag the image, and use the same tag within the curl command.

With this, we have created the entire CI and CD pipeline. When we trigger the GitHub Actions, the GitHub CI will build and test the application, run security scans using CodeQL, build the docker image, and push it to DockerHub. As an additional step, the pipeline will send a curl request to the Devtron dashboard with the correct Docker Image.

What we have created right now, is a simple pipeline. What if we wanted to deploy this application to multiple different environments, or we wanted to pass it through a QA environment before releasing it to production? Within Devtron, we can build any kind of workflow that we want. Be it a parallel pipeline or a sequential pipeline, there are different steps involved before deploying it on production.

When you’re deploying your application to a production environment, you would not want to directly set up a deployment. You want to ensure that the production environment gets proper approval before the deployment gets triggered.

Within the deployment pipeline for the production environment, we can set the number of approvals that are required to trigger the deployment. Check out this blog to learn how to configure and use approval workflows with Devtron.

For many applications, you also have a config map to define configurations or secrets that contain sensitive data such as database passwords or security tokens. You want to ensure that these tokens do not get leaked no matter what.

By using GitHub Actions, it would be tricky to create these tokens. You might need to have a separate private repository that listens for a webhook from the main application repository to trigger the deployments of the config maps and secrets. This process becomes very complex very quickly.

Within Devtron, you can create these configmaps and secrets with ease, without having to worry about the keys getting into the wrong hands. Unless the user has the correct permissions, they will not be able to view or change the secrets.

When you’re deploying applications to multiple different environments, you will want to change certain configurations within those environments. Devtron will let you configure files for all the different environments.

In our case, since we have 5 different environments, we can set environment-specific config maps and secrets along with the deployment configurations for each. We can even change the deployment template as needed. For example, you might want the ingress host for your QA application to be a host defined for the QA environment. Similarly, your dev and production environments would have different ingress hosts.

Within Kubernetes, it becomes a challenge to monitor and configure various configuration drifts. Many times, you want to ensure that the configurations of a particular environment cannot be changed unless the user has the correct permissions.

Within Devtron, you can protect the configuration of environments using the Protect Configuration capability. This aids developers and the operations team to minimize drifts caused by human intervention.

Within the above image [Fig. 14], we have protected the configuration for the production environment. Unless the user has the correct permissions, they will not be able to change any of the configurations that have been set for the production environment.

Before deploying your application to production, you will run the application within a QA environment to ensure that all the configurations are working properly and ensure that nothing is breaking within your deployments. Ideally, you would want to carry the same configurations to your production environment after the tests have passed. You can ensure that the configurations are carried over using the Environment Overrides.

To check for the configuration drift between the QA and production environments, you can use the dropdown on the top right to compare the configuration of the prod environment, with any environment you wish. In this case, we are comparing it with the QA environment. You can see the complete configuration drift and carry the same configurations in the production environment and save it. For critical environments, it is also recommended to have a configuration lock, so that if any changes are made, they first need to be approved by the respective approver then only those configurations will be deployed on prod.

Deploying the application to Kubernetes

After you’ve built the application and the curl command has successfully run, you are ready to deploy the image. In the Build and Deploy tab, you can see that the deployment stage has only the images that were sent via the curl request. Here, we can see that all the images have the latest tag, as we build the images with only one specific tag. If we used a tool such as Jinja to template the tags, each image would have a unique tag.

From here, we can go ahead and trigger a build. When creating the deployment pipeline, if you select the automatic deployment mode, then the deployment will be triggered as soon as the curl request succeeds.

After you’ve triggered the deployment, you will be able to see the real-time status of the entire deployment. You can also see the health of each individual resource.

The different pods, deployments, networking resources, and all other resources will be grouped into their logical sections.

As you can see above [Fig. 17], we have successfully deployed the application. But that’s not where it ends. There are still a lot more things that we will need to do after the initial deployment is completed. Let’s explore what are some of the Day-2 operations that Devtron can help us out with.

Preventing Drift and Managing Day-2 Operations

Once your applications are deployed, the real challenge begins — maintaining performance, ensuring reliability, and optimizing cost across environments.
Most teams rely on multiple disconnected tools for monitoring, scaling, compliance, and debugging — leading to context switching and operational chaos.
Devtron unifies all Day-2 operations into one intelligent control plane, built for continuous visibility, resilience, and automation.

Devtron Unifies Day-2 Operations with:

1. Real-Time Observability: Get instant visibility into your entire Kubernetes landscape from logs and metrics to resource health and performance. Custom dashboards, unified app & service metrics, and intelligent alerting help you predict and prevent outages before they happen.
2. Drift Management & Incident Response: Automatically detect and reconcile configuration drifts across clusters. Devtron’s GitOps-powered fleet management ensures every environment stays in the desired state, while Helm lifecycle automation simplifies ongoing updates.
3. AI-Driven Debugging & Troubleshooting: Diagnose issues faster with AI-assisted analysis that correlates signals across applications and infrastructure.
   Understand root causes, predict failures, and let AI suggest the optimal resolution, reducing mean time to recovery (MTTR).
4. Security & Compliance Automation: Maintain continuous security with policy-as-code, automated compliance scanning, and break-glass RBAC procedures for controlled access. Built-in license and dependency risk detection ensures production stays secure without slowing innovation.
5. FinOps & Cost Intelligence: See and control every dollar spent across clusters, teams, and workloads. Devtron provides real-time cost visibility, workload resizing recommendations, and anomaly detection to optimize resource utilization continuously.

Conclusion

While GitHub Actions are amazing for creating CI pipelines for applications, they lack certain critical functionality when it comes to creating a CD pipeline. There is a lack of many essential functionalities for Kubernetes deployments, such as multi-cluster deployments, configuring a rollout strategy, or specifying environment-specific configurations. Moreover, once the application is deployed, there is a lack of visibility on the health of the application. The GitHub action will appear as successful once the action is complete, regardless of whether the deployment is healthy or not.

Devtron provides a complete view of your application and its deployment status within Kubernetes. It is a Kubernetes native dashboard, which lets you easily configure the secrets and config maps securely, and prevent any data leaks. Moreover, since Devtron allows you to deploy to multiple clusters, you can also set the environment-specific configurations. To simplify your deployments for Kubernetes, install Devtron and integrate it with your existing GitHub Actions CI pipeline.

FAQ

Siddhant Khisty

Siddhant is a Product Executive at Devtron with expertise in Kubernetes, ArgoCD, and DevOps. An organizer for Cloud Native Nashik, he loves open-source tech, automation, and securing deployments.