NotHarshhaa/DevOps-Projects: 41 Numbered Project Folders for Learning AWS, Docker and CI/CD

What NotHarshhaa/DevOps-Projects Is and Who It Is For

This is a project collection, not a program. The top level of the repository holds forty-one directories named DevOps-Project-01 through DevOps-Project-41, plus .github/, CODE_OF_CONDUCT.md, CONTRIBUTING.md, SECURITY.md and README.md. The README describes the intent as catering to aspiring DevOps engineers of all skill levels, and splits the contents into Beginner, Intermediate and Advanced categories. The primary language reported for the repository is Java, which lines up with the README's example of deploying a Java-based login application integrated with a MySQL database.

The audience is therefore someone studying, not someone shipping. If you want a weekend exercise that forces you to touch EC2, RDS, VPC, Auto Scaling and IAM roles, the folder structure gives you a numbered path through them. If you want a library to import, this is the wrong repository. There is no package manifest at the top level, no build file, and the README does not describe an installable artefact. The thing you work with is prose: each project's own README is where the steps live.

How the Project Folders Are Organised and What Each Guide Contains

The architecture is deliberately flat. One directory per project, numbered, with no shared module directory and no monorepo tooling connecting them. That means each DevOps-Project-NN is self-contained: its own instructions, its own prerequisites, its own validation steps. The README states that these README files provide detailed instructions for implementing the projects, emphasising practical deployment steps, pre-requisites and validation processes.

Two projects are named in the top-level README. One deploys a Java application on AWS using a three-tier architecture. Another covers modular VPC network setups on AWS. The technology list the README gives for the collection as a whole is EC2, RDS, VPC, Auto Scaling, IAM roles, Maven, SonarCloud, JFrog Artifactory, CloudWatch for monitoring, custom AMIs and automation scripts. That is an AWS-heavy stack. Kubernetes, Docker, Jenkins and Terraform appear in the repository topics and description, but the README's own feature analysis leans toward AWS services and the Java build chain.

The flow in a typical project is the same shape: provision infrastructure, build the Java artefact with Maven, run quality analysis, publish to a repository, deploy, then validate. Because each folder repeats that shape at a different level of complexity, the collection works as a progression rather than a single system.

Getting Started: Cloning and Working Through Your First Project

There is nothing to install in the usual sense. The README does not describe a package, a binary or a service to run. What you get is a Git repository of guides, so the first step is cloning it and reading the folder you intend to work through.

git clone https://github.com/NotHarshhaa/DevOps-Projects.git
cd DevOps-Projects
ls -d DevOps-Project-*

After the clone you should see the numbered project directories listed, from DevOps-Project-01 upward. Pick one and read its own README before touching a cloud account, because the top-level file does not restate each project's prerequisites.

cd DevOps-Project-01
ls

The README does not specify which number maps to which topic, so the folder listing is the only index you have. For the Java deployment project described at the top level, the README says the application is a login service backed by MySQL and that the deployment uses a three-tier architecture on AWS. Expect to need an AWS account, a MySQL instance via RDS, and a Maven build environment before the guide's steps make sense. It does not publish a cost estimate for the AWS resources involved, which is worth checking yourself before you provision anything.

The companion site at projects.prodevopsguytech.com is described as a Next.js and Tailwind CSS interface over the same curated list. It is a browsing aid, not a second source of instructions.

Where the Repository Falls Short: Versioning, Maintenance and Cloud Scope

The most concrete limitation is that the repository has no releases. The release data returns nothing, so there is no tagged version to pin, no changelog to diff against, and no way to say which state of a guide you followed. If a project's steps break because an AWS console changed, you have no version boundary to point at.

Maintenance is a separate question. The last push was on 2026-09-04, which is recent, so the repository is not dormant. But a recent push on a documentation collection tells you the files changed, not that every one of the forty-one guides was re-validated against current AWS behaviour. The README does not describe a review or testing process for the guides, and there is no CI configuration visible at the top level beyond the .github/ directory. Treat each guide as a starting point that may need adjustment.

The AWS concentration is a real boundary. Someone who wants to learn Kubernetes operators, Terraform module design, or GitOps with Argo CD will find those words in the repository topics but the README's own feature list is dominated by EC2, VPC, RDS and IAM. The README does point to a separate AWS-Projects repository for AWS-specific material, which suggests the maintainer sees this collection as the broader umbrella. The licence is also not stated in the repository listing, so if you intend to reuse the text in a course or internal wiki, confirm the terms before you copy anything.

DevOps-Projects Compared with a Structured Course or a Template Repository

The closest real alternative is a paid video course on a platform such as Udemy, and the difference is in what you receive. A course gives you a recorded sequence with an instructor's environment, a fixed order, and a support channel. This repository gives you text guides in numbered folders with no ordering guarantee beyond the beginner, intermediate and advanced labels in the README. You choose the path; nothing enforces that DevOps-Project-07 builds on DevOps-Project-06.

A second alternative is a template or scaffold repository that ships working configuration you clone and run. The difference there is reproducibility. A scaffold pins versions in its manifests, so the environment is the same for everyone. These project folders describe steps rather than pinning an environment, which is why the absence of releases matters. You get guidance, not a locked dependency set.

The trade-off is honest: text guides age faster than pinned code, but they are also easier to adapt when a service changes. A course recording ages the same way and you cannot edit it.

Maintenance, Contribution and Licence Questions

The repository carries CONTRIBUTING.md, CODE_OF_CONDUCT.md and SECURITY.md at the top level, and the README's badge row links to all three. That is a normal open source governance skeleton, and the contributing guide is the place to look if you want to add a project folder or fix a broken step. The README does not describe how submitted projects are reviewed or what a new folder must contain.

Upgrade cost is close to zero in the dependency sense, because there is nothing to upgrade. The cost is in re-reading a guide when the underlying service changes. If you forked the repository to adapt guides for a team, your maintenance burden is keeping your fork aligned with the upstream folder structure.

The licence is not identified in the repository listing, which is unusual for a repository of this size and matters if you plan to reuse the text. Without a stated licence, the default copyright position applies and you should not assume you can republish the guides. Check the repository for a LICENSE file before reusing content; the top-level listing does not show one.

Editorial conclusion

Adopt this repository if you are building a practice portfolio and want project briefs that name concrete AWS services, Maven, SonarCloud and JFrog Artifactory, or if you teach DevOps and need ready-made exercise outlines. Do not adopt it if you need a maintained library, a CLI, or a pinned environment you can reproduce in CI; there are no releases and no documented versioning. Verify first that a given DevOps-Project-NN folder actually contains the guide you need, since the top-level listing shows only directory names, and check the folder's own notes for prerequisites before provisioning anything in a cloud account.

Frequently asked questions

Official sources

1. Issues
2. NotHarshhaa/DevOps-Projects on GitHub
3. Project website
4. README