90DaysOfDevOps: A CC BY-NC-SA Curriculum in a Git Repository
This repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.
At a glance
- What is it?
- MichaelCade/90DaysOfDevOps is a three-year, community-written DevOps learning map stored as Markdown and a small amount of Shell. It is a study resource, not installable software, and its non-commercial licence is the first thing a corporate reader should check.
- Who is it for?
- Adopt it if you are an individual engineer or a study group working through foundations on your own time, and clone the repository rather than relying on the website so you can diff your checkout against main. Skip it if you need a vendor-supported training path, graded exercises, or material you can repackage inside a paid internal platform, because the CC BY-NC-SA 4.0 licence and the absence of any release since 0.2 in January 2022 rule those out.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 83 days ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
A learning map, not a program you install
The repository exists because its author wanted to document his own study of DevOps foundations and did it in public, starting on 1 January 2022 and running to 31 March 2022, which is where the ninety days come from. What began as one person's notes became, in the README's words, a structured way of learning the foundations of DevOps principles, processes and tooling. The intended reader is someone early in a DevOps career, or an engineer from an adjacent discipline, who wants a reading and watching order rather than a syllabus invented from scratch. It is explicitly not a complete treatment: the README states that it will not cover all things DevOps, and that the encouragement is to read and watch the content, be curious, and discuss findings in the community. The material is also vendor-neutral by design. The README says the project is not a sponsored operation by any vendors and that everything is accessible using free, community and open source software. That constraint shapes what you find inside: no paid platform walkthroughs, no product certification tracks.
Three yearly tracks and how they are split
The content is organised by year, not by topic index. The README links three entry files at the repository root: 2022.md for the original DevOps run, which the README describes as 90 days and 110k words; 2023.md for a DevSecOps track that the README says focuses on security and topics not covered in 2022, with perspectives from community subject matter experts; and 2024.md for a Community Edition built from community sessions, described as 91 sessions shared on YouTube. The README also names the three content types separately: DevOps written content by the author, corrected and enhanced by the community; DevSecOps material contributed by others; and the Community Edition sessions. That split matters when you plan study time. The 2022 track is a single long written narrative. The 2023 track is a set of contributed chapters on security topics. The 2024 track is session-based, so the repository holds the pointer and the supporting resources while the substance sits in video. If you learn better from text, the 2024 track will feel thinner in the repository itself.
Getting the material onto your machine
There is nothing to build or run. The primary language listed for the repository is Shell, but the substance is Markdown, so the practical setup is a clone and a text editor. The command is git clone https://github.com/MichaelCade/90DaysOfDevOps.git, followed by cd 90DaysOfDevOps, after which the root files 2022.md, 2023.md and 2024.md are the entry points named in the README. The default branch is main, which is what a plain clone gives you. If you would rather not clone, the README points at the project site, https://www.90daysofdevops.com, and the README's own badge row links that site alongside the repository. For questions and discussion the README names Twitter as the quickest route, with the handle @MichaelCade1. There is no package to install, no configuration file to edit, and no service to start. Anyone expecting a lab harness or an exercise runner will not find one here.
The licence decides who can use this at work
The README states that the work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License, and ships the matching badge and links to the licence text. Note that the repository metadata reports the licence as NOASSERTION, which is GitHub saying it could not map the file to a known licence identifier; the README is the clearer statement of intent, and it names CC BY-NC-SA 4.0 directly. The NonCommercial term is the one that bites. A study group inside a company, running through the material on internal time, is a different case from a training vendor repackaging the chapters into a paid course, and the ShareAlike term means adapted versions carry the same licence. I am not giving legal advice, and the boundary between internal training and commercial use is exactly the kind of question to put to whoever owns licensing at your organisation before you copy chapters into an internal wiki. Treat the README's licence section as the authoritative claim and verify it against the licence file in the repository root.
Maintenance cost sits with you, not with the project
The release history is the clearest signal about upkeep. The repository has two releases, 0.1 and 0.2, both dated 11 January 2022, and none since. The last push recorded is 24 June 2026, so the repository is active, but the release mechanism was never used again after the first fortnight, which means there is no versioned curriculum to pin against. You cannot say "we study the 0.2 content" and expect that to mean anything useful. What you get instead is a moving main branch plus three year-files, and the practical cost is re-reading and re-checking as tools change. The 2022 track is four years old at the time of writing. Any command in it that targets a specific tool version is a candidate for drift, and the repository gives you no changelog mapping a chapter to a tool release. Budget for that verification, or work from the year-file that matches your current stack rather than treating all three as one continuous course.
Where it is the wrong tool
Two failure modes are worth naming. The first is assessment. There are no graded exercises, no solution branches and no check runner described in the README, so the repository cannot tell you whether you learned anything. If you need evidence of competence for a hiring loop or a compliance record, this is not that. The second is depth on a single tool. The README frames the whole project as foundational and says plainly that it will not cover all things DevOps. The topics list spans ansible, backup, containers, devops, iac, kubernetes, networking and terraform, which is a breadth-first map. Someone who already runs Kubernetes in production and wants to go deep on one subsystem will find the relevant chapter short and will need the upstream documentation anyway. The repository is a route through the territory, and the README says as much when it asks readers to be curious and discuss their findings rather than treating the text as complete.
How it differs from vendor certification paths
The obvious alternative is a vendor certification track, such as a cloud provider's own learning path or a Kubernetes certification curriculum. The difference is structural, not just editorial. A certification path is built backwards from an exam blueprint: fixed scope, versioned objectives, a practice test at the end, and a renewal cycle that forces the vendor to update the material. 90DaysOfDevOps is built forwards from one person's study log and then extended by contributors, with no exam to anchor scope and no renewal forcing function. The vendor path gives you a credential and a guaranteed refresh cadence; this repository gives you a broader spread of topics, no credential, and no cadence you can rely on. The README's second differentiator is independence: it states the project is not sponsored by any vendors and uses only free, community and open source software. That is a real editorial advantage if you want tool comparisons that are not written by the tool's owner, and a real disadvantage if you want the material maintained on a schedule someone is contractually obliged to keep.
Editorial conclusion
Adopt it if you are an individual engineer or a study group working through foundations on your own time, and clone the repository rather than relying on the website so you can diff your checkout against main. Skip it if you need a vendor-supported training path, graded exercises, or material you can repackage inside a paid internal platform, because the CC BY-NC-SA 4.0 licence and the absence of any release since 0.2 in January 2022 rule those out. Before you commit a team to it, open 2022.md, 2023.md and 2024.md on main and confirm that the tooling versions in the sections you care about still match what you run, since the repository's own release history shows no versioned curriculum after the first two tags.
Community notes