jamstack.org: what the Jamstack site repository actually contains

What jamstack.org is for, and who should touch it

The repository is the source of https://jamstack.org. The README describes it as "an entry-point for learning about this architectural model" and as a place to learn what Jamstack is, share tools, tips, examples and articles, and find a local community meetup or get support starting one. That is a narrow purpose. The site is an explanation of an architectural model, plus a directory of learning resources and community groups.

The audience follows from that. If you want to add a video, a presentation or an article to the resource pool, the README says contributions are accepted as pull requests. If you run a meetup and want it listed, the same path applies. If you are a front-end developer looking for a starter for a marketing site, this repository is a poor fit: its content types, navigation and page structure exist to explain Jamstack and to index community material, and you would spend more time deleting than building. The project is a site, and the site's subject is Jamstack itself.

Eleventy, Nunjucks and a Tailwind pipeline

The repository layout shows the shape of the build. There is a .eleventy.js config at the top level, a src/ directory holding the site, plugins/ for Eleventy plugins, postcss.config.js and tailwind.config.js for the CSS pipeline, and netlify.toml for deployment. The primary language is Nunjucks, which is the templating layer Eleventy renders.

The scripts in package.json show two separate pipelines that run together. The build script runs build:html and build:css in sequence. build:html is plain eleventy. build:css runs postcss over src/css/tailwind.css and writes dist/css/styles.css. The start script runs watch:html and watch:css in parallel via npm-run-all. watch:html sets ELEVENTY_ENV=dev, runs eleventy --serve --port=8080 --quiet, and watch:css runs the same PostCSS command with --watch.

Styling is Tailwind utility classes written directly in the HTML, as the README explains, with a small number of bespoke rules kept in src/css/tailwind.css and used sparingly. The README notes that the production build strips unused CSS and compresses the result, and that this step is skipped during local development. That difference matters when you review a change: a class that appears fine locally may be purged from the production output if Tailwind cannot see it in the templates. The dependency list also carries @11ty/eleventy-cache-assets, d3, d3-textwrap, gray-matter, js-yaml, luxon, markdown-it and i18n-iso-countries, which points at data-driven and map-like pages in the site, though the README does not document those pages individually.

Installing jamstack.org and previewing a resource page

The README lists Node and NPM as the only prerequisites, and package.json requires Node 22 or newer through the engines field. The install sequence is four commands, run from a clone of the repository. The last one starts the development server on port 8080.

git clone [email protected]:jamstack/jamstack.org.git
cd jamstack.org
npm install
npm start

After npm start, both watchers run in parallel. The Eleventy server serves the site on port 8080 and the PostCSS watcher rewrites dist/css/styles.css as you edit. To see the optimised output instead, the README gives a two-step production preview: run npm run build, then npm run start.

npm run build
npm run start

The first real use is adding a resource. The README says to create a new Markdown file in src/site/resources with a unique, descriptive name, and to populate the front matter in this structure:

---
title: Resource title
date: Publish date (YYYY-MM-DD)
link: the URL of this resource
thumbnailurl: /img/cms/resources/resource-thumbnail.jpg
type:
  - article
---

The type field groups and sorts resources and the README lists article, video and presentation as the accepted values. For a presentation or a video you can add a thumbnail to src/site/img/cms, and the README specifies a JPEG 600 pixels wide by 400 pixels tall. Then open a pull request. If the new page does not appear, the front matter is the first thing to check, because Eleventy will silently skip a file it cannot parse into a page.

The licence is declared in package.json, not in the repository metadata

The repository metadata does not carry a licence, which is why the licence shows as unknown in the listing. The package.json file inside the repository declares "license": "MIT" and names Phil Hawksworth as author. Those two facts sit side by side, and the practical reading is that the package manifest is the only licence statement available here. There is no LICENSE file in the top-level entries.

That gap is worth naming rather than smoothing over. If you plan to reuse the templates or the CSS outside this site, the package.json field is the only basis you have for doing so, and it is a package field rather than a repository-level licence grant. This is not legal advice, and the difference between the two placements is something to raise with whoever owns the decision on your side. For ordinary contribution work, the question rarely comes up: you are sending a Markdown file and a pull request upstream, not redistributing the codebase.

Where the contribution model gets in the way

The failure mode here is not a crash. It is a pull request that does not fit the content model. The README defines resource files in src/site/resources with a fixed set of front matter fields, and it does not document any other content type for external contributions. If your material is a tutorial series with ten parts, a podcast, or a tool with a changelog, there is no documented place for it. The README does not describe a general page type you can add, and it does not document how the resource list is sorted beyond the type grouping.

The second constraint is the thumbnail. A video or presentation entry expects an image in src/site/img/cms at 600 by 400 JPEG. The README states the dimensions and does not say what happens to an image that does not match, so a wrong-sized thumbnail is a review comment rather than a build error you can catch locally.

The third is the deployment path. The README offers a one-click clone and deploy to Netlify, which requires free GitHub and Netlify accounts, and netlify.toml is checked in. That is convenient for a test site, but it means the project is shaped around one host's build pipeline. If your organisation runs something else, you are adopting the repository without the deployment half of its documentation.

Eleventy versus a full CMS-backed site

The obvious alternative approach is a content management system paired with a generated front end, where editors write in an admin interface and the build pulls content from an API. The difference is where the content lives and who can change it. Here, a resource is a Markdown file with YAML front matter committed to the repository, reviewed as a pull request, and rendered by Eleventy at build time. There is no database, no admin UI and no editorial role outside the git workflow.

That trade is deliberate and it has costs. A non-technical contributor has to learn the front matter format and open a pull request, which the README acknowledges by walking through the file structure step by step. In exchange, every change is reviewable in a diff, and the published site is a directory of generated files with no runtime content lookup. The README's own framing of the site as a place to share resources and find meetups fits that model, because the volume of contributions is low and each one is a discrete link rather than a stream of posts. If your content changes hourly or is written by people who will not touch git, this repository's approach will not carry you, and no amount of Tailwind configuration changes that.

Editorial conclusion

Adopt this repository if you are contributing a resource link, a meetup, or a fix to the Jamstack community site, or if you want a working Eleventy plus TailwindCSS example to study. Do not adopt it as a starting point for your own product site: the content model is built around resource entries, community listings and the site's own information architecture, and the licence situation is not settled by the repository metadata even though package.json declares MIT. Before you spend time on a change, run npm start and confirm the page renders locally, then check whether the resource front matter matches the fields the site expects. The build is the easy part; the contribution path is where the real decisions are.

Frequently asked questions

Official sources

1. Issues
2. jamstack/jamstack.org on GitHub
3. Project website
4. README