Let’s say that you’ve finished a Docker tutorial. Perhaps you have already created a Jenkins pipeline or deployed something onto kubernetes. But when somebody asks, “Can you walk me through a devops project you’ve built,” suddenly getting them all together into one comprehensive workflow becomes confusing.
That’s because DevOps isn’t about learning one tool at a time. In the software teams, Docker, CI/CD, Kubernetes, monitoring, and infrastructure provision work together to move an application from development to production.
With that in mind, this guide is designed as a progression of projects with each step building off of the last. You will start by Dockerizing a simple application, automate the build and deployment with CI/CD, deploy it on Kubernetes, set up infrastructure, add monitoring, and lastly, implement GitOps. You will also apply hands-on DevOps principles and practices to real-world scenarios such as working with microservices deployments, centralized logging, chaos engineering, and pipeline security, along the way.
The One-App-Through-the-Pipeline Approach
The projects in this guide are divided into two parts.
1. Projects 1-9: Build one complete DevOps pipeline
These projects follow the lifecycle of a single application. First, you will containerize it using Docker, automate builds and deployments using CI/CD, deploy it on Kubernetes, provision infrastructure using Terraform, add monitoring using Prometheus and Grafana, and finish with GitOps. Each stage introduces a new DevOps concept, and builds upon the work you have already done.
2. Projects 10-15: Explore real-world DevOps scenarios
Once you’ve built the core pipeline, you’ll move on to projects that resemble typical production environments. These include microservices deployments, centralized logging, centralized configuration management using Ansible, blue-green deployments, chaos engineering, and security scanning. They complement each other to allow you to extend your practical skills beyond the application.
At the end of this guide you will not only have a list of devops projects, but you will also have a pipeline that brings in everything in one go and some production focused projects to demonstrate how modern software is built, deployed and managed.
New to CI/CD? Since many of the projects build on Continuous Integration and Continuous Deployment concepts, it’s helpful to understand the basics before you begin. You can explore them in our guide on CI/CD.
Stage 1-2: Containerize & Compose (Projects 1-2)
Every DevOps workflow starts with an application that can be packaged and deployed consistently across different environments. Before you automate builds or deploy to Kubernetes, you’ll first package the application and its dependencies into a portable environment. That’s exactly what you’ll do in this stage.
You’ll start off with a standalone web application and then move it into a multi-container application with a database. After these two projects, you will have a strong foundation on which other parts of your CI/CD pipeline will be developed.
Project 1: Containerize a Web Application with Docker
The challenge
An application that works perfectly on your machine may not work the same way on someone else’s laptop or on a production server. Unexpected problems can arise due to different operating systems, library versions and missing dependencies. This project is designed to be able to package your application into a Docker container, ensuring that it will run in a consistent manner across different environments.
How you can build it
Start from a basic web application, like a node.js, python (flask) or java (spring boot) application. Create a Dockerfile that packages your application, installs its dependencies, and configures everything needed to run it inside a container. Then, use a multi-stage build to separate the build stage from the final runtime image, reducing the image size and keeping only the files required to run the application.
By the end, you’ll have
- A web application packaged in a container.
- A multi-stage Dockerfile for production.
- The image is ready to be used in a CI pipeline.
Project 2: Run Your Application with Docker Compose
The scenario
Most applications don’t run as a single container. The back-end service will usually interact with a database, and most production applications rely on a combination of caching, message queues, or other back-end services. As this application scales up, it becomes hard to manage these containers – one at a time.
How you can build it
Add a database (PostgreSQL or MySQL) to the containerized application from Project 1. Define the two services using a docker-compose.yml file, connect them together, mount volumes to keep data and set the application’s configuration by environment variables. Last but not least: Start the full application stack with one command and check if all the services run together.
What you’ll explore
- Single running containers
- Service-to-service communication
- To store data with persistent volumes, use Docker volumes. Use Docker volumes for persistent storage.
- Environment-based configuration
- Managing a local development environment
Why this matters
Docker Compose closely resembles the way that developers put together applications prior to deployment into cloud environment. It also provides you with a full application stack ready for the next phase, in which you will automate testing, image creation, and deployments with a CI pipeline.
If you’re new to Docker or want to understand how images, containers, volumes, and networking work, you can check out this free Docker Tutorial.
Stage 3-4: CI, Then CD (Projects 3-4)
Your application is now containerized and can run consistently across environments. The next challenge is reducing manual work. Rebuilding Docker images, running tests, and deploying every change by hand quickly becomes repetitive and error-prone, especially as a project grows. This is where a CI/CD pipeline becomes an essential part of the development workflow.
In this stage, you’ll first automate testing and image creation using GitHub Actions. Once your Continuous Integration (CI) pipeline is in place, you’ll extend it into Continuous Deployment (CD) by automatically deploying the application to a virtual machine using Jenkins.
Project 3: Build a CI Pipeline with GitHub Actions
The workflow today
Imagine making a small code change. You run your tests, build a Docker image, tag it, and push it to a container registry, all manually. Repeat this process several times a day, and it becomes both time-consuming and prone to mistakes.
How you can build it
Create a GitHub Actions workflow that runs whenever code is pushed to your repository. Configure it to install project dependencies, execute automated tests, build a Docker image, and push the image to a container registry such as Docker Hub after all checks pass. As you make changes to the application, you’ll be able to verify that every commit follows the same automated process before it’s ready for deployment.
For a detailed understanding of how GitHub Actions workflows, events, and runners work, you can also refer to the official GitHub Actions documentation.
Pipeline outcome
- Automated testing for every code change
- Automatic Docker image builds
- Versioned images pushed to a container registry
- A reliable Continuous Integration workflow
Project 4: Automate Deployments with Jenkins
Why add another tool?
While GitHub Actions has become a popular choice for CI, many organizations continue to rely on Jenkins for building and managing deployment pipelines. Learning both gives you experience with cloud-native workflows as well as enterprise DevOps environments.
How you can build it
Using the Docker image generated by your CI pipeline, configure a Jenkins pipeline to deploy the latest version of your application to a virtual machine. Set up Jenkins to pull the updated image, replace the running container with the latest version, and verify that the deployment completes successfully. You can also extend the pipeline with simple post-deployment checks or notifications to simulate a production workflow.
If you’d like to explore Jenkins pipelines in greater depth, including declarative pipelines and pipeline stages, our Jenkins Pipeline guide covers the concepts used in this project.
Key takeaway
- Automated application deployments
- Hands-on experience with Jenkins pipelines
- Integration between CI and CD workflows
- A complete deployment process from code commit to running application
At this point, you’ve eliminated most of the repetitive work involved in delivering software. Every code change can now be tested, packaged, and deployed through an automated pipeline. In the next stage, you’ll move beyond deploying to a single virtual machine and learn how Kubernetes orchestrates containers across a cluster for greater scalability and reliability.
Stage 5-6: Kubernetes & Helm (Projects 5-6)
Your CI/CD pipeline can now automatically build and deploy your application. But what happens when your application starts to receive more traffic, needs multiple instances, or must recover automatically if a container crashes? This is where container orchestration becomes important.
Kubernetes helps manage containerized applications at scale by handling deployment, scaling, networking, and recovery. In this stage, you’ll first deploy your application to a Kubernetes cluster, then simplify application management with Helm, making deployments more consistent and easier to maintain.
Still confused between Docker and Kubernetes? Docker packages and runs containers, while Kubernetes manages those containers across a cluster. If you’re unsure where each tool fits, you can have a read about Docker vs Kubernetes to understand the differences before you continue.
Project 5: Deploy Your Application on Kubernetes
What’s changing?
So far, your application has been running on a single virtual machine. Kubernetes takes a different approach by distributing applications across a cluster, making them easier to scale, update, and recover from failures.
How you can do it
Start by creating a local Kubernetes cluster using Minikube and deploy the same application you’ve built so far. Define Kubernetes manifests for your Deployment and Service, expose the application, and verify that it’s running successfully. Once you’re comfortable with the workflow, try deploying the application to a managed Kubernetes service such as Amazon EKS, Google Kubernetes Engine (GKE), or Azure Kubernetes Service (AKS) to understand how the same deployment process extends to the cloud.
If you’re looking for a structured learning path after this project, this Kubernetes Roadmap covers the concepts and skills you’ll encounter as you progress from beginner to advanced Kubernetes deployments. You can also explore the official Kubernetes documentation for detailed implementation guidance.
Key concepts covered
- Pods, Deployments, and Services
- Scaling containerized applications
- Rolling updates
- Self-healing workloads
- Local and managed Kubernetes clusters
Project 6: Package Your Application with Helm
Why Helm?
As Kubernetes applications grow, managing multiple YAML files becomes difficult. A small configuration change may require updating several files, making deployments repetitive and harder to maintain. Helm solves this by packaging Kubernetes resources into reusable charts.
How you can build it
Convert the Kubernetes manifests from Project 5 into a Helm chart. Organize deployment templates, move configurable values into a values.yaml file, and install your application using Helm. Once everything is working, update the application’s configuration through Helm and perform an upgrade without manually editing Kubernetes manifests.
What you’ll gain
- Hands-on experience with Helm charts
- Reusable Kubernetes deployments
- Easier configuration management
- Version-controlled application releases
By this point, you’ve built an application that can move from source code to a Kubernetes cluster through an automated deployment pipeline. The next step is to automate the infrastructure supporting that cluster and monitor how your application performs in production.
Stage 7-9: Infrastructure as Code, Monitoring & GitOps (Projects 7-9)
By now, you’ve built an automated pipeline that takes your application from source code to a Kubernetes cluster. The next step is making that environment easier to manage, observe, and maintain over time. Rather than manually provisioning infrastructure or deploying updates, modern DevOps teams automate these tasks to improve consistency, reduce errors, and simplify operations.
In this stage, you’ll provision infrastructure using Terraform, monitor application health with Prometheus and Grafana, and adopt GitOps with ArgoCD to manage deployments through Git. Together, these projects introduce practices that are commonly found in production environments and are often expected in advanced DevOps roles.
Deploying to AWS? Many of the services used in these projects are available on AWS. If you’re looking to understand the cloud platform behind these deployments, explore Scaler’s Free AWS Course before getting started.
Project 7: Provision Infrastructure with Terraform
Why move infrastructure into code?
Creating cloud resources manually works when you’re experimenting, but it quickly becomes difficult to track changes or recreate environments consistently. Infrastructure as Code (IaC) solves this by defining your infrastructure in version-controlled configuration files.
How you can build it
Use Terraform to provision the infrastructure needed to run your application, such as a virtual machine, networking components, or a managed Kubernetes cluster. Organize your configuration into reusable files, apply the infrastructure, and verify that the resources are created automatically. Once everything is working, make a small configuration change and update the infrastructure through Terraform instead of the cloud console.
Infrastructure outcome
- Hands-on experience with Infrastructure as Code
- Version-controlled infrastructure
- Repeatable environment provisioning
- A foundation for cloud-based deployments
Project 8: Monitor Your Application with Prometheus & Grafana
What happens after deployment?
Deploying an application isn’t the end of the DevOps lifecycle. Teams also need to know whether the application is healthy, how it’s performing, and when something goes wrong. Monitoring provides that visibility before users notice an issue.
How you’ll build it
Deploy Prometheus to collect metrics from your application and Kubernetes cluster, then connect Grafana to visualize those metrics through dashboards. Create charts for CPU usage, memory consumption, request latency, and application availability. Finally, configure basic alerts so you’re notified when predefined thresholds are crossed.
What you’ll monitor
- Application health and uptime
- CPU and memory utilization
- Response times
- Error rates
- Alerting for operational issues
Project 9: Implement GitOps with ArgoCD
What’s changing?
So far, deployments have been triggered through your CI/CD pipeline. With GitOps, Git becomes the single source of truth for your application’s desired state. Instead of applying changes manually, updates are made through Git, and ArgoCD keeps your Kubernetes cluster synchronized automatically.
How you’ll build it
Install ArgoCD and connect it to the Git repository containing your Kubernetes manifests or Helm charts. Configure ArgoCD to watch the repository, synchronize changes automatically, and roll out updates whenever new configurations are committed. Test the workflow by modifying an application setting in Git and verifying that ArgoCD updates the cluster without manual intervention.
Production advantage
- Automated Kubernetes deployments through Git
- Version-controlled application configurations
- Easier rollbacks and change tracking
- A deployment workflow that closely mirrors modern platform engineering practices
Why this matters
At this stage, you’ve gone beyond building an application; you’ve automated how it’s provisioned, monitored, and deployed. These are the kinds of practices that distinguish production-ready DevOps workflows and help you demonstrate experience with modern cloud-native operations. The remaining projects build on this foundation by exploring specialized scenarios you’ll encounter in real-world DevOps teams.
Standalone Builds (Projects 10-15)
By this point, you’ve built an end-to-end DevOps pipeline, i.e, from containerizing an application and automating deployments to provisioning infrastructure, monitoring workloads, and implementing GitOps. While that gives you a strong foundation, real-world DevOps teams work on many specialized challenges beyond a single deployment pipeline.
The following projects focus on those scenarios. Each one explores a different aspect of modern DevOps, helping you gain experience with tools and practices that are commonly used in production environments.
Project 10: Deploy a Microservices Application
The challenge
As applications grow, they’re often split into multiple services instead of being maintained as a single codebase. Managing communication, deployments, and updates across these services introduces an entirely new set of operational challenges.
How to build it
Deploy an application made up of three independent services. For example, a frontend, backend, and authentication service, along with Apache Kafka for asynchronous communication. Containerize each service, deploy them using Kubernetes, and verify that they communicate reliably even as individual services are updated or restarted.
You’ll be able to cover
- Experience with microservices architecture
- Inter-service communication
- Event-driven workflows using Kafka
- Managing multi-service deployments
Project 11: Build a Centralized Logging Pipeline
Why centralize logs?
When applications run across multiple containers and services, checking logs one by one becomes inefficient. Centralized logging brings application and infrastructure logs together, making troubleshooting significantly easier.
How you can build it
Set up an ELK-based logging pipeline by collecting logs from your application, processing them, and storing them in Elasticsearch. Use Kibana to search, filter, and visualize logs so you can quickly identify errors, failed requests, or unusual application behaviour.
What you’ll explore
- Centralized log collection
- Log aggregation and search
- Troubleshooting distributed applications
- Basic observability practices
Project 12: Automate Configuration with Ansible
The problem
Keeping multiple servers configured manually often leads to inconsistencies. Configuration management tools help ensure every server follows the same setup and can be updated with minimal effort.
How to build it
Create Ansible playbooks to automate tasks such as installing software packages, configuring services, creating users, and deploying application updates across multiple servers. Organize your inventory and roles so your automation remains reusable and easy to maintain.
If you’re new to configuration management, our Ansible guide provides a detailed introduction to playbooks, inventories, and automation workflows. (Internal link: DevOps Ansible)
Automation outcome
- Reusable Ansible playbooks
- Automated server configuration
- Consistent environments across multiple machines
- Reduced manual administration
Project 13: Demonstrate a Blue-Green Deployment
What’s the goal?
Deploying a new version of an application shouldn’t interrupt users. Blue-green deployments reduce downtime by keeping two identical environments available and switching traffic only after the new version is ready.
How to build it
Deploy two versions of the same application—one serving live traffic and another running the updated release. Once the new version has been tested successfully, switch traffic to it and verify that the deployment completes without disrupting users.
Why teams use this approach
- Near zero-downtime deployments
- Faster rollback if issues occur
- Safer production releases
Project 14: Run a Chaos Engineering Experiment
Can your application recover from failure?
Production systems fail in unexpected ways. Chaos engineering helps teams understand how resilient their applications are by intentionally introducing controlled failures.
How you can build it
Simulate common failure scenarios such as stopping containers, increasing latency, or making a service temporarily unavailable. Observe how Kubernetes responds, verify that monitoring tools detect the issue, and confirm whether your application recovers automatically.
What you’ll learn
- Application resilience
- Failure recovery
- Self-healing Kubernetes workloads
- Incident response fundamentals
Project 15: Add Security Scanning to Your CI/CD Pipeline
Security starts before deployment
Finding vulnerabilities after an application reaches production can be expensive and risky. Modern DevOps teams integrate security checks directly into their CI/CD pipelines so issues are identified early.
How you can build it
Extend your existing CI pipeline by adding container image scanning and dependency vulnerability checks. Configure the pipeline to generate security reports and prevent deployments when critical vulnerabilities are detected.
Pipeline enhancement
- Automated vulnerability scanning
- Secure container images
- Security checks within CI/CD
- A stronger DevSecOps workflow
Together, these projects give you experience with the kinds of challenges DevOps engineers solve every day. From managing distributed applications and automating infrastructure to improving reliability, strengthening security, and troubleshooting issues, you’ll gain practical skills that make your portfolio more well-rounded.
Portfolio, Resume & the Pipeline Walkthrough Interview
Done with the projects? Consider reaching halfway through your journey! Now, you’ll have to focus on presenting them. Recruiters and interviewers are often more interested in understanding your approach than seeing a list of technologies on your resume. A well-documented project demonstrates not only what you built but also how you solved problems, automated workflows, and improved the deployment process over time.
Build a Portfolio That Tells a Story
Rather than creating separate repositories for each project, consider documenting your entire DevOps journey around the same application. This makes it easier for someone reviewing your portfolio to understand how your deployment pipeline evolved.
Your project repository should ideally include:
- A detailed README explaining the project’s objective and architecture
- An architecture diagram showing how Docker, CI/CD, Kubernetes, monitoring, and GitOps fit together
- Screenshots of your CI/CD pipeline, Kubernetes workloads, Grafana dashboards, and ArgoCD deployments
- Setup instructions so others can recreate the project
- Challenges you encountered, how you solved them, and possible future improvements
Highlighting DevOps Projects on Your Resume
Focus on the outcomes of your projects and the technologies you used to achieve them.
For example, you could highlight experience such as:
- Built an end-to-end CI/CD pipeline using GitHub Actions and Jenkins to automate testing and deployments.
- Containerized a multi-service application using Docker and Docker Compose, improving deployment consistency across environments.
- Deployed and managed containerized workloads on Kubernetes using Helm and Infrastructure as Code with Terraform.
- Implemented monitoring using Prometheus and Grafana and integrated GitOps workflows with ArgoCD for automated deployments.
Questions You Should Be Ready to Answer
Once you are done presenting your projects, it’ll often lead to follow-up questions during technical interviews. Be prepared to explain not just the tools you used, but the decisions behind them.
Some common questions include:
- Why did you choose Docker for this application?
- How does your CI/CD pipeline work from code commit to deployment?
- Why did you move from Docker Compose to Kubernetes?
- How does Helm simplify Kubernetes deployments?
- What infrastructure did you provision with Terraform?
- Which metrics did you monitor using Prometheus and Grafana?
- How does ArgoCD implement GitOps?
- If your deployment failed, how would you troubleshoot it?
Being able to answer these questions confidently shows that you understand the complete workflow, which often leaves a good impression.
Looking for your next step? If you’re planning to build a career in DevOps, this DevOps Roadmap outlines the skills to learn next, and you can also check out these DevOps Engineer Skills to get an idea of what employers typically expect from aspiring DevOps professionals.
Keep Building Beyond Projects
The projects in this guide give you practical experience across containerization, CI/CD, Kubernetes, Infrastructure as Code, monitoring, and GitOps. As you continue learning, focus on strengthening your cloud fundamentals, automation skills, and production troubleshooting techniques. These are the areas that help bridge the gap between completing projects and working on real-world DevOps systems.
Ready to Take the Next Step?
You’ve built the pipeline; now it’s time to understand the engineering principles behind it. If you’re looking for structured, hands-on learning with real-world projects, mentorship, and industry-relevant tools, explore Scaler’s DevOps Program and continue building the skills needed for modern cloud and platform engineering roles.
Frequently Asked Questions
1. What projects should a DevOps beginner build?
You can start by building one application through a complete DevOps workflow. Begin by containerizing it with Docker, automate testing and builds using GitHub Actions, deploy it through a CI/CD pipeline, move it to Kubernetes, provision infrastructure with Terraform, and add monitoring. This gives you practical experience with how DevOps tools work together and creates a portfolio project you can confidently discuss in interviews.
2. Should I use Jenkins or GitHub Actions for DevOps projects?
Yes. Learning both gives you broader exposure to real-world DevOps workflows. GitHub Actions is a popular choice for modern cloud-native projects because of its GitHub integration, while Jenkins is still widely used across enterprise environments. Building projects with both tools helps you understand where each one fits.
3. Do I need a cloud account to build DevOps projects?
No. You can complete the initial projects using Docker, Minikube, and Jenkins on your local machine. Cloud resources become useful when you start working with Infrastructure as Code (IaC) or managed Kubernetes services. If you use a cloud free tier, enable billing alerts to avoid unexpected costs.
4. Are DevOps projects enough to get a DevOps job?
Projects are one of the strongest ways to demonstrate practical skills, but they should be supported by a good understanding of Linux, networking, scripting, cloud platforms, and troubleshooting. A well-documented DevOps pipeline combined with these fundamentals can help you qualify for entry-level and career transition roles.
5. What is GitOps, and should my project include it?
GitOps is a deployment approach where Git stores the desired state of your infrastructure and applications. Tools like ArgoCD automatically synchronize your Kubernetes cluster with those configurations. Adding GitOps to your project demonstrates familiarity with modern deployment practices and production-ready workflows.
6. How should I showcase DevOps projects on my resume?
Describe the problem you solved, the tools you used, and the outcome you achieved. For example: Built a CI/CD pipeline using GitHub Actions and ArgoCD to automate Kubernetes deployments and improve release consistency. Support your resume with a GitHub repository that includes a detailed README, architecture diagrams, pipeline screenshots, and deployment instructions.
