# 90DaysOfDevOps: a day-wise challenge where the deliverable is a commit > 90DaysOfDevOps is not a course but a schedule: ninety folders, one task per day, and a public repository where each learner's work is the evidence. The curriculum runs from Linux fundamentals through Docker, CI/CD, Kubernetes and Terraform to observability, and the README's own framing is discipline and execution rather than content. It is a useful pattern and a rough curriculum, and the two are worth separating. **TrainWithShubham/90DaysOfDevOps** — This repository is a Challenge for the DevOps Community to get stronger in DevOps.The reason for making this Public is so that others can learn from the community and help each other grow. - Repository: https://github.com/TrainWithShubham/90DaysOfDevOps - Stars: 1,428 · Forks: 8,678 - Language: Shell - License: MIT - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/trainwithshubham-90daysofdevops ## A schedule with deliverables, not a course with videos 90DaysOfDevOps is a structured, hands-on DevOps challenge by TrainWithShubham, and the README's framing is unusually blunt about what kind of thing it is. It is not a theory-heavy course, it is a discipline plus execution challenge, and the repository description says it is a challenge for the DevOps community to get stronger at DevOps, made public so that others can learn from the community and help each other grow. The design decisions follow from that. Every day has one clear task. Every task has a real-world DevOps outcome. Every learner builds a public GitHub proof of work. Every concept is reinforced through hands-on practice, and the learning is aligned with live classes and recordings. The outputs are listed explicitly, and they are the outputs of a portfolio rather than of a certificate, so strong DevOps fundamentals, multiple mini-projects, one end-to-end capstone, a GitHub profile that clearly shows consistency, and confidence for interviews and production systems. The audience is stated as students and freshers entering DevOps or Cloud, working professionals switching to DevOps, SRE or Cloud roles, developers who want to understand infrastructure and CI/CD, and anyone who believes consistency beats talent. No prior DevOps experience is required, but the commitment is called mandatory. ## Ninety folders, and what you actually do in each The repository structure is the whole interaction model, and the README shows it as a flat sequence of day folders, each with a README file of its own. ```text 90DaysOfDevOps/ │ ├── README.md ├── CONTRIBUTING.md ├── LICENSE ├── .gitignore │ ├── scripts/ │ └── helper-scripts.sh │ ├── day-01/ │ └── README.md ├── day-02/ │ └── README.md ├── ... ├── day-90/ │ └── README.md ``` Participation is five steps, and the middle one is the point. You fork the repository, clone your fork, navigate to the current `day-XX` folder, complete the task, and commit and push your work. The push is not optional bookkeeping, it is the mechanism by which the challenge produces the public proof of work it advertises, and it is why the README encourages daily commits. There is also a `scripts/helper-scripts.sh` in the tree, which suggests the tasks share some automation, and a top level `TOC.md`, which is the table of contents the README's structure diagram does not show. ## The curriculum arc, in the order the README lists it The list of what you will learn is a conventional DevOps curriculum in a sensible order, and reading it tells you what the ninety days cover. It opens with Linux fundamentals and troubleshooting, then shell scripting and automation, then networking basics for DevOps, then Git and GitHub workflows. Containerisation comes with Docker, then AWS core and advanced services, then CI/CD using Jenkins, GitHub Actions and GitLab, then DevSecOps fundamentals. The platform layer follows with Kubernetes, Helm and ArgoCD, then infrastructure as code with Terraform and Ansible, then observability with Grafana, Prometheus and OpenTelemetry, and it closes with an end-to-end DevOps project. Two details are worth flagging. The first is that three CI/CD systems appear in one line, which is generous for ninety days and suggests the earlier days are more foundational than the later ones. The second is that observability and infrastructure as code sit at the end rather than the beginning, so a learner who wants a job in platform engineering should expect the capstone to land on the Kubernetes and Terraform material rather than on the Linux and shell material. ## Live class days, practice days, and the time budget The section on how the challenge works explains the rhythm. One day equals one task, the tasks are aligned with live classes, the live class days focus on core concepts, and the weekday days focus on practice and reinforcement. That split is the mechanism that makes a daily commitment survivable, because a day that is only a lecture can be absorbed on a commute while a day that is a task needs an hour. The time budget is stated plainly, that even 30 to 60 minutes per day is enough if done honestly, and the word honestly is doing work there, because the outcome that the README promises, a GitHub profile that clearly shows consistency, only follows if the commits actually happen on the days they are supposed to. The final note in the README puts the philosophy in one line, that DevOps is not about tools but about ownership, reliability and consistency, followed by one day at a time and one commit at a time. ## Learn in public, and what the profile ends up looking like The social part of the design is explicit rather than implied. The README asks learners to share their progress on LinkedIn with three hashtags, the challenge name, the community tag and the author's own tag, and the features list says every learner builds a public GitHub proof of work, and one of the stated outcomes is a GitHub profile that clearly shows consistency. The reasoning is that in a hiring market where everyone claims DevOps on a resume, a fork with ninety days of commits is a different kind of claim. There is a trade-off here that the README does not discuss, which is that a public record of daily work is also a public record of the days you did not do the work, and a repository with gaps tells its own story. Whether that is a problem depends on what you are optimising for. ## What the repository looks like now, and where the value sits The current tree has moved on from the flat layout in the README's diagram. The top level now holds year directories, 2023, 2024, 2025 and 2026, alongside the README, the `CONTRIBUTING.md`, a `TOC.md`, a `scripts/` directory, a `.github/` directory and two licence files, `LICENSE` and `LICENSE.md`, with the licence stated as MIT. That shift is informative, because it shows a challenge that ran across multiple years and kept its history rather than resetting the counter, and it tells you where to look for the day you want. The last push was on 2026-04-26 and there are no GitHub releases, which is consistent with a repository whose unit of delivery is a folder of instructions rather than a version. The honest assessment is that the pattern is the reusable part here. A day-wise structure with one deliverable per day and a public commit is a mechanism any mentor can copy for any subject, and the day folders are useful where they exist and thin where a task is only a bullet list, so read a few days in the year you plan to join before you commit ninety evenings to them. ## Conclusion Adopt the structure of 90DaysOfDevOps rather than the content, because the one task a day with a public commit is the part that works and the day folders are only as good as the task in them. Do not adopt it as a substitute for a structured curriculum, because the README describes it as a challenge aligned with live classes and recordings, so the daily material assumes you are following a course alongside it. Before you start, check that the day you want is actually written, since the repository's own structure has evolved from the flat `day-01` to `day-90` layout shown in the README into year directories from 2023 to 2026, and pick the year folder that matches the run you are joining. The licence is MIT, the last push was on 2026-04-26, and the repository publishes no GitHub releases. ## FAQ ### What is 90DaysOfDevOps? It is a day-wise DevOps learning challenge by TrainWithShubham, described as a discipline and execution challenge rather than a theory-heavy course, where every day has one clear task with a real-world DevOps outcome and every learner builds a public proof of work in a fork of the repository. ### How do I participate in 90DaysOfDevOps? Fork the repository, clone your fork, navigate to the current `day-XX` folder, complete the task, and commit and push your work. The README says daily commits are encouraged and that 30 to 60 minutes per day is enough if done honestly. ### What topics does the 90DaysOfDevOps curriculum cover? Linux fundamentals and troubleshooting, shell scripting and automation, networking basics, Git and GitHub workflows, Docker and containerization, AWS core and advanced services, CI/CD with Jenkins, GitHub Actions and GitLab, DevSecOps fundamentals, Kubernetes with Helm and ArgoCD, Terraform and Ansible, observability with Grafana, Prometheus and OpenTelemetry, and an end-to-end DevOps project. ### Where are the daily tasks in the repository? The README's structure diagram shows a flat `day-01` to `day-90` sequence of folders, each with a README, and the current repository instead holds year directories for 2023, 2024, 2025 and 2026 alongside a `TOC.md` table of contents and a `scripts/helper-scripts.sh`, so look in the year folder that matches the run you are joining. ## Sources - [Issues](https://github.com/TrainWithShubham/90DaysOfDevOps/issues) - [License: MIT](https://github.com/TrainWithShubham/90DaysOfDevOps/blob/master/LICENSE) - [README](https://github.com/TrainWithShubham/90DaysOfDevOps/blob/master/README.md) - [TrainWithShubham/90DaysOfDevOps on GitHub](https://github.com/TrainWithShubham/90DaysOfDevOps) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/trainwithshubham-90daysofdevops