devops-daily is a Next.js content platform that builds as a static export

A site that builds to static files

DevOps Daily describes itself as a modern, open-source content platform for DevOps professionals, with articles, guides, exercises, news and resources to help people level up their DevOps skills. The readme frames it as community-driven, with a belief in learning by doing and sharing knowledge.

What it is technically is a Next.js application deployed as a static export. The readme says the project powers the devops-daily.com website and is built with modern web technologies, deployed on Cloudflare Pages for performance and reliability. The tech stack section is explicit that the framework is Next.js with the App Router and a static export, and the export script in the package metadata is next build followed by next export.

That last point is the architectural decision that shapes everything else. A static export means no server, no database and no request time rendering, which is why the content lives in the repository as markdown and why the build script has to generate a search index and a feed before the site can be built. The site is a program that turns a directory of files into a directory of HTML.

The feature list reads like a modern content site checklist, and it is worth reading the parts that are not about looks. There is a fully responsive design, a dark mode, and a PWA mode so the site can be installed and used offline. On the content side there are multi-part guides, exercises, quizzes and interactive games, an RSS feed, and the organisation is by tags, categories and authors.

The audience is a DevOps engineer who wants to learn by doing, and a technical writer who wants somewhere to publish the material.

The content directory is the product

The project structure section of the readme is the most informative part of the documentation, because the content taxonomy is listed in full and it is unusually broad for a learning site.

Under content/ there are posts for blog posts, guides for multi-part guides, categories, quizzes, exercises, news, checklists, comparisons for side-by-side tool comparisons, flashcards, interview-questions for question sets, experts for an expert directory, newsletters for issues, advent-of-devops for calendar content, and hacktoberfest.

That list tells you what kind of site this is. A blog post is one thing, but a flashcard deck, an interview question set, a side-by-side tool comparison and a multi-part guide are four different content models with four different sets of required fields, and the readme says each type has its own required fields, with the templates for all of them in CONTRIBUTING.md.

So the platform is not a generic blog. The structure is built around a pedagogy, learn by doing, with a lot of formats that are not prose. A comparison page for two tools and a flashcard deck are things a static site generator will not give you for free, and the fact that they are first class here says more about the project than the feature list does.

Mechanically, the content is markdown with YAML frontmatter, parsed with gray-matter and rendered with marked, with highlight.js for the code blocks and Framer Motion for the animations. On the front end there is Tailwind for the styling and shadcn/ui for the components, with Lucide for the icons.

The consequence for a fork is that adding a content type means adding a directory, a template and a generation rule, and the readme is clear that the templates live in the contribution guide rather than in the code.

The build is a chain of content generation steps

The build script in the package metadata is the clearest description of what this project does, and it is not a single next build.

The full build is pnpm images:all, then pnpm copy:markdown, then pnpm generate-search-index, then pnpm generate-feed, then pnpm generate-devto-feed, then next build, then pnpm copy:markdown:out.

Each of those is a real step with a script behind it. The images step runs the OG cover image generation, and there is a separate convert:svg-to-png step and a validate:images step that runs the generator in check mode, plus a regenerate:content-covers script that forces regeneration, converts the SVGs and prunes them. The copy:markdown and copy:markdown:out steps move the markdown into the build and then into the output directory. The two feed scripts generate the RSS feed and a second feed for dev.to, and the search index script builds the client side index.

There are also lighter paths. build:fast drops the image generation, and build:cf is a variant of the fast path, which suggests the Cloudflare deployment needs a slightly different set of outputs.

What this tells you is that the site is a generator with a content pipeline, not a hand written application. The build is deterministic and takes longer than a page build because it produces images, two feeds, a search index and a static export in one pass. That is a good shape for a site that is rebuilt on every content change, and it is a real cost for a site that is edited often by many people.

Getting it running is three commands and a version check

The getting started section is short, and it starts with the versions because the project enforces them.

The prerequisites are Node.js 22.13.1 or later but below 25, and pnpm 10 or later but below 11, and the readme says both are enforced by the engines field in package.json. The package metadata confirms it, with node >=22.13.1 <25 and pnpm >=10 <11, and the packageManager field pinning [email protected].

Then the three commands.

git clone https://github.com/The-DevOps-Daily/devops-daily.git
cd devops-daily

pnpm install

pnpm dev

And then open http://localhost:3000 to see the site running locally. The readme closes with the message that you are ready to start contributing.

The other scripts matter as soon as you want to check your work rather than just view it. The test script is vitest run, there is a watch variant and a ui variant, and the end to end suite is a separate playwright test script, with a playwright.config.ts in the repository. The lint command covers the app, components, hooks, lib, scripts and tests directories, with an eslint cache, and the project also carries prettier configuration, a markdownlint configuration and a markdown link check configuration, which is what you would expect from a repository whose main output is prose.

The environment file is minimal, with NODE_ENV, NEXT_TELEMETRY_DISABLED, WATCHPACK_POLLING for the file watcher, a commented optional PORT and a commented optional OPENAI_API_KEY.

The container image and a pnpm version that does not match

The Dockerfile and the compose file are thorough, and there is one inconsistency in them worth flagging before you build.

The Dockerfile is a multi-stage build on node:${NODE_VERSION}-bookworm-slim, with the version and the pnpm version as build arguments, and pnpm installed globally in the base stage. The development stage installs with pnpm install --frozen-lockfile and runs pnpm run dev. The image carries the usual OCI labels for the title, description, source, licence, vendor and authors, exposes port 3000, and has a healthcheck that curls the local URL every 30 seconds with a 40 second start period and three retries.

The compose file is more elaborate. The dev service builds with target development, mounts the source at /app for hot reload, uses a named volume for node_modules to avoid conflicts with the host, and mounts a pnpm store volume for faster installs. It sets the development environment variables, keeps a tty open for logging, restarts unless stopped, and has the same curl healthcheck. The resources are capped at two CPUs and 4G with reservations of one CPU and 2G, and the logging driver is json-file with a 10m maximum size.

The inconsistency is the pnpm version. The compose file passes PNPM_VERSION 9.12.3 as a build argument, while the Dockerfile defaults to 10.34.5 and the package manager field pins [email protected]. The engines field also requires pnpm 10 or later but below 11, so the compose build argument is a major version behind what the project requires.

It may be harmless, since a lockfile produced by a newer pnpm may still install under an older one, but it is the kind of detail that produces a confusing failure on a first container build, and it is trivial to fix by aligning the argument with the Dockerfile default.

Version numbers that track content, not code

The release history is the last piece, and it is the one that changes how you read the project.

The three most recent releases are 0.132.0 on 2025-10-17, 0.133.0 on 2025-10-23 and 0.134.0 on 2025-10-24, and every one of them is titled with the same content series, Linux 101. The repository is not archived and the last push was on 2026-10-14, so the code is being worked on continuously, and the version line has passed 134 with three releases in a week around the same series.

So the version number is a content release counter. That is a sensible convention for a project whose output is lessons, because a reader can tell which set of articles a given site build contains, and a maintainer can publish a new article without bumping anything that looks like an API change. The corollary is that the version number tells you nothing about the code, and anyone tracking upgrades by semver will be misled.

The sponsorship model is worth one paragraph too, because it explains the shape of the project. The readme says the site is kept free by its sponsors, and the sponsor table lists Bitrise for managed runners for GitHub Actions, Atomsized for AWS platform engineering and GitOps, DigitalOcean for cloud infrastructure, DevDojo for a developer community, SMTPfast for a developer first email API, and QuizAPI for a quiz platform.

The last two are the interesting ones. A quiz API and an email API are sponsors of a learning site, which suggests that the quizzes are not decoration but a product surface, and that the sponsors are using the platform rather than just supporting it.

Editorial conclusion

devops-daily is worth adopting if you want a self hosted DevOps learning site with a real content model, because the content taxonomy, the generation scripts and the static export are all in the repository and the build is reproducible. It is the wrong choice if you want a community around it, since the content model assumes a maintainer who curates, and it is the wrong choice if you need a server rendered application, since the deployment target is a static export. Before you fork it, read the content guidelines in CONTRIBUTING.md, and note that the current release is 0.134.0 from 2025-10-24 while the repository was pushed to on 2026-10-14.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. The-DevOps-Daily/devops-daily on GitHub