DEV Community: Alexy Pulivelil

Stop Manually Editing GitOps Files: ArgoCD Image Updater on Kubernetes

Alexy Pulivelil — Wed, 08 Apr 2026 10:45:41 +0000

Every time a developer pushes new code, someone has to manually update the image tag in the GitOps repo. ArgoCD then deploys it. Sound familiar? Let’s fix that.

The Problem🥲

If you’re running ArgoCD with a GitOps setup, you’ve probably experienced this pain:

Developer pushes code
CI (Jenkins/Gitlab) builds and pushes a new image to the registry
Someone (u/me/dev) manually edits the image tag in the GitOps repo
ArgoCD detects the change and deploys it.

What is ArgoCD Image Updater?

ArgoCD Image Updater automatically watches your container registry for new image tags and updates your ArgoCD applications without any manual intervention. When a new image is pushed, it detects the change and triggers a deployment without manual interventions.

Prerequisites

Before we begin, please ensure you have:

An EKS cluster running
kubectl configured
helm installed
A container registry (DockerHub, ECR, GitLab Registry etc.)
A GitHub/GitLab repo for your GitOps values

Step 1 — Install ArgoCD on EKS

First, create the ArgoCD namespace and install it:

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

If you see a CRD annotation size error, apply the server-side flag:

kubectl apply --server-side -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Access the ArgoCD UI:

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

Retrieve the initial admin password by opening another terminal:

kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d && echo

Use this password to log in.

Step 2 — Understanding the Multisource Pattern

In real-world GitOps setups, ArgoCD applications often use multiple sources:

Source 1 — The Helm chart from a Helm registry (e.g., Bitnami, your internal registry)
Source 2 — The values files from your GitOps repository

This is a clean separation — the chart is versioned independently from your environment configuration.

Here’s what a multisource ArgoCD application looks like:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: nginx-sample
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  sources:
    - repoURL: https://charts.bitnami.com/bitnami
      chart: nginx
      targetRevision: 21.0.5
      helm:
        releaseName: nginx-sample
        valueFiles:
          - $values/values/values.yaml
    - repoURL: https://github.com/AlexyPulivelil/gitops-sample.git
      targetRevision: main
      ref: values
  destination:
    server: https://kubernetes.default.svc
    namespace: nginx-sample
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

The values.yaml file typically looks like this:

replicaCount: 1
service:
  type: ClusterIP
  port: 80
image:
  registry: docker.io
  repository: repository/nginix
  tag: "10.0"
  pullPolicy: Always

We are addressing the issue of manually updating these tags on every deployment.

Step 3 — Why ArgoCD Image Updater Old Version Won’t Work Here

(skip this if having single source.)

I tried 0.12.2 initially

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj-labs/argocd-image-updater/v0.12.2/manifests/install.yaml

And add annotations to your ArgoCD Application:

annotations:
  argocd-image-updater.argoproj.io/image-list: myapp=myregistry/myapp
  argocd-image-updater.argoproj.io/myapp.update-strategy: latest

And if you check logs you could see

level=warning msg="skipping app 'nginx-sample' of type '' 
because it's not of supported source type"

v0.12.2 does not support multisource ArgoCD applications. It uses annotations on the Application resource and relies on detecting the source type, which fails for multisource apps.

NB: If working on single source, this would be sufficient

This limitation is why we need v1.1.1.

Step 4 — Install ArgoCD Image Updater v1.1.1

v1.1.1 introduces a CRD based approach — instead of annotations on the ArgoCD Application, you create a dedicated ImageUpdater custom resource. This completely solves the multisource problem.

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj-labs/argocd-image-updater/v1.1.1/config/install.yaml

Verify the controller is running:

kubectl get pods -n argocd | grep image-updater-controller

Grant the controller permissions to access ArgoCD applications:

kubectl create clusterrolebinding image-updater-binding \
  --clusterrole=cluster-admin \
  --serviceaccount=argocd:argocd-image-updater-controller \
  -n argocd

Note: For production, scope down the permissions using a dedicated ClusterRole instead of cluster-admin.

Step 5 — Create the ImageUpdater CR

This is the key difference in v1.1.1. Instead of annotating your ArgoCD Application, you create a separate ImageUpdater resource:

apiVersion: argocd-image-updater.argoproj.io/v1alpha1
kind: ImageUpdater
metadata:
  name: nginx-sample-updater
  namespace: argocd
spec:
  applicationRefs:
    - namePattern: "nginx-sample"
      images:
        - alias: nginx
          imageName: your-registry/nginx-sample-image
          commonUpdateSettings:
            updateStrategy: newest-build
            forceUpdate: true
          manifestTargets:
            helm:
              tag: image.tag
              name: image.repository

What each field means:

namePatternWhich ArgoCD application to watch

imageNameWhich image to monitor in the registry

updateStrategyHow to pick the new tag (newest-build, semver, alphabetical)

forceUpdateUpdate even if image isn't directly referenced in app status

manifestTargets.helm.tagWhich Helm value holds the image tag

manifestTargets.helm.nameWhich Helm value holds the image repository

Apply it:

kubectl apply -f imageupdater-cr.yaml

NB: The apply order should be

# First the ImageUpdater CR
kubectl apply -f argocd/image-updater-cr.yaml
# Then the ArgoCD Application
kubectl apply -f argocd/application.yaml

Now push a new image tag:

docker tag your-dockerhub/nginx:1.0 your-dockerhub/nginx:2.0
docker push your-dockerhub/nginx:2.0

Watch the magic happen in the logs🧙‍♂️

kubectl logs -f deployment/argocd-image-updater-controller -n argocd

You’ll see

msg="Setting new image to your-dockerhub/nginx:2.0"
msg="Successfully updated image to your-dockerhub/nginx:2.0"
msg="Successfully updated application spec for nginx-sample"
msg="images_updated=1"

Zero manual editing. Fully automated.

Key Features

Multiple Update Strategies:

newest-buildAlways pick the most recently pushed tag

semverFollow semantic versioning constraints e.g. ~1.29

alphabeticalPick the last tag alphabetically

digestTrack by image digest

One CR Per Application:

Each ArgoCD Application gets its own ImageUpdater CR. This gives you fine-grained control — each service can have a different update strategy, different registry credentials, and different tag filters.

Write-back Methods:

argocd (default) Updates ArgoCD application parameters directly via API

gitCommits the tag change back to your GitOps repo

For true GitOps, use the git write-back method so every deployment change is tracked in Git.

Limitations💭

Being transparent about limitations is important before adopting any tool in production:

1. One CR per Application: Every ArgoCD Application needs its own ImageUpdater CR. In large setups with many services these requirements can become a lot of CRs to manage.

2. argocd write-back overrides values.yaml: When using the default argocd write-back method, Image Updater sets a parameter override directly on the ArgoCD Application. This takes priority over your values.yaml file. If you manually edit values.yaml, it won't take effect. Use git write-back to avoid this.

3. Registry rate limiting: Image Updater polls the registry every 2 minutes by default. On DockerHub's free tier this can hit rate limits, especially in teams with many services. Configure credentials or use webhooks for instant updates.

4. newest-build picks by push timestamp If you push tags out of order (e.g., push 9.0 after 10.0), Image Updater will pick 9.0 because they were pushed more recently. Use semver strategy to avoid this.

5. No conflict resolution between multiple CRs If two ImageUpdater CRs accidentally target the same ArgoCD Application, they will continuously overwrite each other, causing the application to flip between versions. ensure that only one CR targets each application.

Getting Started with AWS Bedrock

Alexy Pulivelil — Sun, 16 Feb 2025 11:06:49 +0000

Developers can create and scale generative AI applications with Amazon Bedrock, a fully managed service, by utilising foundation models from AWS and other suppliers. In this guide, I’ll walk you through getting started with AWS Bedrock and invoking the Amazon Titan Text Lite v1 model for text generation.

Prerequisites
Before you begin, ensure that you have the following:

AWS Account with access to Amazon Bedrock(For testing will be using AmazonBedrockFullAccess)
AWS CLI installed and configured with appropriate permissions
Boto3 (AWS SDK for Python) installed on your machine

You can install Boto3 using:

pip install boto

Step 1: Set Up AWS Credentials

If you haven’t already configured your AWS credentials, run:

aws configure

Enter your AWS Access Key ID, Secret Key, and select your preferred region where Amazon Bedrock is available (e.g., us-east-1).

Step 2: Initialize the Bedrock Client
To interact with Amazon Bedrock, we need to initialise the AWS Bedrock runtime client using Boto3:

import boto3
import json

# Initialize Bedrock client
bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")
Step 3: Invoke Amazon Titan Text Lite v

Let’s create a simple script to invoke Amazon Titan Text Lite v1 for generating a text response.

# Define the input text
question = "What is the capital of India?"

# Prepare the payload
payload = {
    "inputText": question,
    "textGenerationConfig": {
        "maxTokenCount": 100,
        "temperature": 0.5,
        "topP": 0.9
    }
}

# Invoke Titan Text Lite v1
response = bedrock.invoke_model(
    modelId="amazon.titan-text-lite-v1",
    contentType="application/json",
    accept="application/json",
    body=json.dumps(payload)
)

# Parse response
result = json.loads(response["body"].read().decode("utf-8"))

# Extract and print the output text
if "results" in result and isinstance(result["results"], list):
    print("Answer:", result["results"][0]["outputText"].strip())
else:
    print("Unexpected response format:", result)

Step 4: Running the Script

Save the script as invoke_bedrock.py and run it using:

python invoke_bedrock.py

Expected Output:
Answer: New Delhi is the capital of India. It is situated in the countrys federal district, which is known as the National Capital Territory of Delhi (NCT), and is located in the Indian subcontinent.

Step 5: Fine-tuning Model Parameters

Amazon Titan models allow temperature and topP tuning for response variation:

temperature: Controls randomness (Lower = More deterministic, Higher = More creative)
topP: Controls sampling probability (Higher = More diverse responses)
Adjust these values in the textGenerationConfig section for different results.

Conclusion
You have successfully invoked the Amazon Titan Text Lite v1 model using AWS Bedrock! You can now integrate this into your applications for chatbots, summarization, and content generation.

Happy coding! 🚀

Cloud Computing

Alexy Pulivelil — Sun, 23 May 2021 17:47:31 +0000

Basics of Cloud Computing

Moving to the cloud. Running in the cloud. Stored in the cloud. Accessed from the cloud.
Anyone with a smartphone have done at-least any one of the above operations. So cloud is a place where you can access apps and services, and where your data can be stored securely, i.e. it is the on-demand delivery of IT resources via Internet.

History of Cloud Computing

The Internet has its roots in the 1960s, and as Internet connections got faster and more reliable, a new type of company called an Application Service Provider or ASP started to appear. By the end of the 1990s, salesforce.com introduced its own multi-tenant application which was specifically designed:

to run “in the cloud”
to be accessed over the Internet from a web browser
to be used by large numbers of customers simultaneously at low cost.

Why Cloud Computing ?

Cloud computing is a big shift from the traditional way businesses think about IT resources. Benefits of cloud computing are:

Cost- Cloud computing eliminates the capital expense of buying hardware and software and setting up and running on-site datacentres.
Speed- Most cloud computing services are provided self service and on demand, so even vast amounts of computing resources can be provisioned in few mouse clicks
Performance- The biggest cloud computing services run on a worldwide network of secure datacentres, which are regularly upgraded to the latest generation of fast and efficient computing hardware.
Security- Many cloud providers offer a broad set of policies, technologies and controls that strengthen your security posture overall, helping protect your data, apps and infrastructure from potential threats.
Global scale- The benefits of cloud computing services include the ability to scale elastically.

Cloud Computing Architecture

Cloud computing architecture is a combination of service-oriented architecture and event-driven architecture. Cloud computing architecture is divided into the following two parts -
Frontend
Backend

Frontend — The front end is used by the client. It contains client-side interfaces and applications that are required to access the cloud computing platforms. The front end includes web servers (including Chrome, Firefox, internet explorer, etc.), tablets, and mobile devices.
Backend — The back end is used by the service provider. It manages all the resources that are required to provide cloud computing services. It includes a huge amount of data storage, security mechanism, virtual machines, deploying models, servers, traffic control mechanisms, etc.

Client-Server Architecture
Client-Server Architecture is a distributed application structure that partitions tasks or workloads between the providers of a resource or service called servers and service requesters called clients. Many client requests and receive service from a centralized server. Here, additional hardware can be easily added to increase computing power.

Types of Cloud Computing

Public Cloud — Public clouds are owned and operated by a third-party cloud service providers, which deliver their computing resources like servers and storage over the Internet. With a public cloud, all hardware, software and other supporting infrastructure is owned and managed by the cloud provider. AWS, Azure, Google Cloud etc.
Private Cloud — A private cloud refers to cloud computing resources used exclusively by a single company or organisation. A private cloud can be physically located on the company’s on-site datacentre. Some companies also pay third-party service providers to host their private cloud. A private cloud is one in which the services and infrastructure are maintained on a private network.
Hybrid Cloud — Hybrid clouds are a combination of public and private clouds, bound together by technology that allows data and applications to be shared between them.
Community Cloud — It operates as a public cloud. The difference is that this system only allows access to a specific group of users with shared interests and use cases. This type of cloud architecture can be hosted on-premises, at a peer organization, or by a third-party provider. A combination of all three is also an option.

Types of Cloud Services

Infrastructure as a service (IaaS) — The most basic category of cloud computing services. With IaaS, you rent IT infrastructure — servers and virtual machines (VMs), storage, networks, operating systems — from a cloud provider on a pay-as-you-go basis. Example: Aws, Microsoft Azure
Platform as a service (PaaS) — Platform as a service refers to cloud computing services that supply an on-demand environment for developing, testing, software applications. It is designed to make it easier for developers to quickly create web or mobile apps, without worrying about setting up or managing the infrastructure of servers, storage, network and databases needed for development. Example: Google App Engine
Software as a service (SaaS) — Software as a service is a method for delivering software applications over the Internet, on demand and typically on a subscription basis. With SaaS, cloud providers host and manage the software application and underlying infrastructure and handle any maintenance, like software upgrades and security patching. Example: Gmail, Google Docs etc.
Hardware as a service (HaaS) — Hardware as a service refers to managed services or grid computing, where computing power is leased from a central provider. In each case, it is similar to other service-based models, where users rent, rather than purchase, a provider’s tech assets.

Disadvantages of Cloud Computing

Security Threat in the Cloud — Before adopting cloud technology, you should be well aware of the fact that you will be sharing all your company’s sensitive information to a third-party cloud computing service provider. Hackers might access this information.
Downtime — cloud provider may face power loss, low internet connectivity, service maintenance, etc.
Lower Bandwidth — Many cloud storage service providers limit bandwidth usage of their users. So, in case if your organization surpasses the given allowance, the additional charges could be significantly costly.
Technical Issues — Cloud technology is always prone to an outage and other technical issues. Even, the best cloud service provider companies may face this type of trouble despite maintaining high standards of maintenance.

MLH CUSAT Guild

Alexy Pulivelil — Sun, 17 Jan 2021 13:57:14 +0000

After Local Hack Day: Learn in the month of October, in the month of January they are organising Local Hack Day: Build, which is a week-long celebration of creating hacks both big and small. Next Local Hack Day: Share will be conducted in the month of March/April.
Working and completing the challenges and learning something are the main steps done in the Local Hack Day Build. And in this virtual environment there was no lose in the spirit and enthusiasm. It is a great opportunity to learn and collaborate with other fellows. Enjoyed a lot.

HACKTOBERFEST

Alexy Pulivelil — Sat, 17 Oct 2020 07:30:37 +0000

What I Learned From Hacktoberfest

Really thankful to Digital Ocean for providing a Fest like this. Hacktoberfest was really fantastic and only because of this I get to know about PRs and open source.