An Eleventy starter is a repository you clone to skip the setup: a working config, a layout, a posts collection, an RSS feed and a build script, so that the first day is spent writing pages rather than reading docs. The official eleventy-base-blog is the right default because it tracks the current Eleventy release and carries nothing you did not ask for. The community starters add a design, a CSS framework or a CMS, which is useful when you want exactly that and a cleanup job when you do not. Pick the smallest one that has the features you will keep, then deploy it from the repository so that pushes build.
The starter directory on the Eleventy site lists dozens of options with a screenshot each, and the theme aggregators list hundreds more. The search result that helps is not another list. It is a way to choose in five minutes, a checklist for the first hour with the one you chose, and the deploy step that the starters leave to you.
Table of contents
- What a starter is and is not
- How to choose in five minutes
- Setting up the one you chose
- What to strip out on day one
- Deploying it from the repository
- When to skip the starter
- How this fits the rest of the stack
- FAQ
What a starter is and is not
Eleventy is deliberately unopinionated: it takes templates in a dozen languages and produces HTML, and it does not ship a layout, a CSS approach, a folder structure or a content model. That is its strength and it is why the empty project stares back at you. A starter is somebody’s answer to those decisions, packaged as a repository.
A starter is not a theme in the WordPress sense. There is no separation between the theme and your content; you clone the whole thing and it becomes your project. Updating to a newer version of the starter later is a manual merge, so the choice is more permanent than it looks.
It is also not a framework. Everything in it is ordinary Eleventy configuration and templates that you can read in an afternoon, which is the point of choosing Eleventy in the first place.
How to choose in five minutes
Four questions, in order.
- Does it track the current Eleventy version? Open package.json and check the @11ty/eleventy dependency. A starter pinned to 1.x or 2.x when 3.x is current will need a migration before you have written a page. The official base blog is always current; many community starters are not.
- What does it add beyond Eleventy? A CSS framework, an image pipeline, a CMS integration, a component library. Each one is a dependency you will maintain. Want it or drop the starter.
- How much of it is the demo? Some starters are a real site with lorem ipsum swapped in; you will be deleting for an hour. Others are a skeleton. Look at the content folder and count the files.
- Is it a template repository on GitHub? The Use this template button gives you a clean history. A starter that expects you to fork it leaves you with a fork relationship and someone else’s commits.
If in doubt, the official eleventy-base-blog wins by default: layouts, a posts collection with tags, an RSS feed, a sitemap, syntax highlighting, image optimisation and a bundle plugin, with no CSS framework and nothing decorative. It is the one whose every line you will understand.
Setting up the one you chose
Use the template button on GitHub to create your repository, then clone it and run it.
git clone https://github.com/you/my-site.git
cd my-site
npm install
npm start
The dev server serves at localhost:8080 and rebuilds on save. Look at three files before writing anything.
- eleventy.config.js. Input and output directories, passthrough copies, filters and plugins. The base blog uses content/ as input and _site/ as output; other starters use src/ and dist/. This is what the deploy step will need to know.
- _data/metadata.js or its equivalent. Site title, URL, author, description. Every starter has one; every deployed starter site with the author’s name still in the footer forgot it.
- The layouts folder. Usually _includes/layouts. The base layout is the one file that touches every page, so it is where the analytics snippet, the favicon and the fonts go.
What to strip out on day one
A starter is faster than a blank project only if you remove what you will not use before it becomes load-bearing.
- The demo posts. Delete them, keep one as a reference for front matter, and rewrite it.
- Plugins you do not need. The base blog ships an image plugin, a navigation plugin, a syntax highlighter and a bundle plugin. A site with no code and no images can drop two of them and the config gets shorter.
- The CSS you will replace. If the starter came with a framework and you are keeping it, fine. If you are not, remove it now rather than fighting it for a month.
- Third-party scripts. Some starters include analytics, comment widgets or font loaders with the author’s account IDs. Remove or replace before the first deploy, or the author gets your traffic.
- The README. It describes the starter, not your site. Replace it with your own build and deploy notes.
Commit after the strip so that the diff between the starter and your site is one readable commit.
Deploying it from the repository
Eleventy produces a folder of HTML. The deploy is: run the build, publish the folder, and do that on every push. The starters stop at the build script and leave the rest to you.
The two values a host needs are the build command and the output directory. For the base blog and most starters:
build command: npx @11ty/eleventy
output directory: _site
Check eleventy.config.js for the output directory if the starter changed it. On RunxBuild, a static site takes those two values in the create form, builds from the repository on each push, and serves the output with a custom domain and certificate handled and 120GB of bandwidth included; see static sites on RunxBuild for the form. Redirects and headers, which a blog usually needs once URLs change, are configured on the site rather than in the generator.
One trap: if the starter uses pathPrefix for a project-pages deploy, remove it before deploying to a real domain, or every link gets a subdirectory it should not have.
When to skip the starter
If you know Eleventy, a starter costs more than it saves. The empty project needs a config file, a layout and a collection, and you will write those in twenty minutes without inheriting anyone’s decisions. Starters are for the first Eleventy site, or for the case where the starter’s specific extra, a design system, a CMS wiring, is the thing you wanted.
And if the site is going to need a backend, forms that store data, accounts, anything that is not a page, then the choice is not which starter but whether a static generator is the right shape. It often still is, with the dynamic parts as a separate service beside it.
How this fits the rest of the stack
A starter is a shortcut through the setup, not a decision about the site. Choose the smallest one that is current, strip what you will not use in the first hour, and put the build command and output directory into a host that builds on push. If the site grows a backend later, the RunxBuild hosting calculator shows the static site and a service side by side so the second half of the project has a number before it starts, and the dashboard is where the repository gets connected.
Useful related references:
- Eleventy on Netlify: A Build Config That Just Works
- Free Next.js Templates: Where the Good Ones Are, How to Tell a Starter From a Trap, and How to Deploy One
- What Is a Static Website? Benefits, Examples, Hosting
- Static sites on RunxBuild
FAQ
What is the best Eleventy starter?
The official eleventy-base-blog, for most people. It tracks the current release, includes a posts collection, RSS, sitemap, syntax highlighting and image optimisation, and adds no CSS framework. Community starters are worth it when you specifically want the design or integration they add.
Can I update a starter after I have built on it?
Not automatically. A starter becomes your project when you clone it; later changes to the starter are a manual merge. Treat the choice as permanent and pick a small one so there is less to diverge from.
What build command and output directory does Eleventy use?
The build command is npx @11ty/eleventy and the default output directory is _site. Starters sometimes change the output to dist; check the dir setting in eleventy.config.js before configuring the host.
Do I need Node to deploy an Eleventy site?
Only to build it. The host runs Node during the build to produce HTML, then serves the HTML with no runtime. A static host that builds from the repository handles both steps on every push.
Should I fork a starter or use it as a template?
Use it as a template. A fork keeps a link to the original repository and its full commit history. The template button on GitHub produces a fresh repository with one initial commit, which is what a new site should start from.