Astroplate is an Astro starter that ships a full site, not a skeleton

What the template is, and who made it

Astroplate is a starter template built with Astro, Tailwind CSS and TypeScript, published by Zeon Studio. The pitch in the repository description is that it provides everything needed to jumpstart an Astro project and save hours of work, and the README makes the same claim in its own words.

The distinction between a skeleton and a finished site is the whole product decision here. A bare Astro project gives you the framework and nothing else. Astroplate gives you designed pages: a homepage, about, contact, authors and a single author page, a blog and a single blog post, a custom 404, an elements page, a privacy policy, tag and category listings with their single item pages, and a search page. The README counts them as fifteen or more pre-designed pages.

The feature list adds the parts that a content site usually needs and that a template can therefore demonstrate: multiple authors, a multilingual demo, a similar posts suggestion, search, dark mode, tags and categories, a contact form, Google Tag Manager, Disqus comments, syntax highlighting, and fully responsive layouts. Content is written in Markdown or MDX.

Two live demos are linked, the standard one and a multilang one, and the README links a PageSpeed report for the standard demo. The repository also has an unusual amount of tooling around it, a Sitepins configuration directory, an AGENTS.md and a CLAUDE.md for assistant tooling, a skills-lock file, an MCP configuration and a .codex directory, which tells you that the project is maintained as much for automated agents as for humans.

The build chain: three Node scripts run around astro build

The package scripts are the clearest description of how the template works, and they are not a single astro build. The build script runs a theme generator, a JSON generator, the Astro build and then an llms generator:

"dev": "concurrently \"node scripts/themeGenerator.js --watch\" \"node scripts/jsonGenerator.js && astro dev\"",
"build": "node scripts/themeGenerator.js && node scripts/jsonGenerator.js && astro build && node scripts/llmsGenerator.js",
"preview": "astro preview",
"check": "astro check"

The development command is the interesting one, because it runs two things at once with concurrently. The theme generator watches for changes, and the JSON generator runs once and then hands over to astro dev. So a fresh clone is not a plain Astro project, it is an Astro project with two build steps in front of it, and the generated files are what the Astro pages import.

The dependency set explains the weight of this. Alongside Astro itself and the Tailwind Vite plugin there is React 19 with react-dom and react-icons, the Astro React integration, astro-swiper, the lite-youtube component, remark plugins for collapsing and for a table of contents, marked, gray-matter, date-fns, github-slugger, sharp for image processing, Disqus, and the Google Tag Manager integration. The sitemap integration is there too. A React runtime inside a mostly static Astro project is a deliberate choice for interactive islands, and it is also the dependency you inherit whether or not you use it.

There is also a remove-darkmode script, which runs a script that strips the dark mode support and then reformats the source, and a format script that runs Prettier over the src directory. The template is meant to be edited, and the tooling assumes you will cut pieces out of it.

Generating llms.txt from the build output

One feature is unusual enough to be worth its own section, because it is the kind of thing a template can add cheaply and a hand rolled site rarely has.

After the build, the project can generate LLM friendly files from the dist HTML: llms.txt as an index of pages, llms-full.txt as the full combined content, and optionally a Markdown file per page. The README says the generation is included in the build, and that you can also run it on its own:

# included in build
pnpm run build

# or run manually after build
pnpm run generate-llms

The configuration lives in a JSON file, src/config/config.json, under an llms key, and the options are specific enough to be useful. generate_llms_txt controls the index, generate_llms_full_txt the combined file, and generate_individual_md the per page Markdown. The include option takes routes or globs and selects what goes in, with an empty value meaning all files, and the examples given are /about and /blog/** for everything in the blog folder. The exclude option removes routes on top of the defaults, with /blog/index.html given as an example.

That is a real advantage for a site that wants to be readable by tools, since the whole thing is a build step over the output you already produce rather than a separate content pipeline. It is also the kind of feature that ages: the naming convention of llms.txt is still settling, and a template that ships it will need to follow whatever shape it takes next.

Three deployment paths: Netlify, Cloudflare Workers and Docker

The template is pre-configured for more than one target, which is unusual for a starter and is a direct consequence of being static output.

Netlify is the pre-configured path, with a netlify.toml at the root and a settings entry in the feature list. Cloudflare Workers is the second, with a wrangler.jsonc file and two scripts:

pnpm run preview:cf-workers

pnpm run deploy:cf-workers

The deploy script runs the build and then wrangler deploy, and the preview variant runs the build and then wrangler dev, so both work from a local checkout against your own account. The Cloudflare integration is described as optional deployment in the integrations list.

The third path is Docker, and the Dockerfile in the repository is a conventional multi-stage build. The base is node:22.20.0-alpine, a deps stage installs the dependencies with the package manager you choose, a builder stage copies the source and runs the build, and the final stage is nginx:alpine with the built dist copied into the served directory and the repository's own nginx configuration mounted. The INSTALLER build argument selects yarn, npm or pnpm:

docker build -t astroplate .
# or
# docker build --build-arg INSTALLER=npm -t astroplate .
# or
# docker build --build-arg INSTALLER=pnpm -t astroplate .

docker run -p 3000:80 astroplate

The argument is passed to both stages, so the same image name can be built with whichever package manager you prefer, and the deps stage uses corepack to activate pnpm in that case. Serving the site from nginx on port 80 inside the container and mapping it to 3000 on the host is the usual way to run a static site in a container, and the README also shows how to get a shell inside it with ash, the Alpine shell.

Editing content with Sitepins, and the file layout

The template ships with a CMS integration, Sitepins, described as a Git-based headless CMS for content management. The README's position is that you can update text, images and configuration without touching code, and it points at an Edit with Sitepins button in the README itself, which links to a clone action that takes the GitHub repository.

The mechanism is worth understanding because it explains a directory in the repository. Sitepins stores its own configuration in the .sitepins/ directory, and because the CMS commits to the same Git repository, the content lives in version control alongside the code. That is the appeal for a team that wants non technical editing without a separate database, and it is also the constraint: every content change is a commit, so the workflow depends on how the repository handles branches and reviews.

The rest of the layout is a normal Astro project: src/ for the site source, public/ for static assets, config/ for the site configuration including the nginx configuration used by the Docker image, scripts/ for the three generator scripts, plus a .github directory for workflows, .vscode for editor settings, and a pnpm-workspace.yaml with a pnpm-lock.yaml, which matches the declared package manager pnpm 11.17.0.

The README's own notes on scope are worth repeating. The image licence is separate from the code licence: the code is MIT, while the images are only for demonstration purposes and are not being shared with permission, so a shipped site needs its own images. The README also links the studio's custom development services, and the Sitepins button carries an affiliate parameter, which is a fact about how the template earns its keep and worth knowing before you publish a site built on it.

Maintenance, requirements and where a template is the wrong answer

The requirements are stated in the README: Astro 7.0.0, Node 22.12.0 or newer, and Tailwind 4 or newer. The package manifest pins astro 7.1.4 and Vite 8, and the Dockerfile uses a newer Node patch release, 22.20.0, which is a small difference but one to watch when the two disagree.

The maintenance record is mixed. The last push was on 2026-08-16, and the package version is 6.2.1, so the project is active. But the repository publishes no GitHub releases, and the versioning that does exist is the package version inside a template that people copy rather than install. A template has no upgrade path in the ordinary sense, so the number that matters is not the version but how closely the template tracks the Astro release it claims to support. The manifest pins astro 7.1.4, ahead of the 7.0.0 the README asks for, so the template currently tracks the Astro release it claims to support.

That is the general case for using a template at all, and Astroplate makes it concrete. You are inheriting a theme system, fifteen designed pages, a search implementation, a Disqus integration, a tag manager snippet, a comment system, a multilingual demo and a set of generator scripts, and every one of them is a decision somebody else made. The remove-darkmode script exists precisely because the template is edited rather than configured, which is the right expectation to have of it.

The alternative is to start from a bare Astro project and add the pieces you need, which is a few more hours and gives you a codebase you can reason about end to end. The template wins when you want a complete site quickly and can accept that you now maintain a fork. It loses when your site is long lived, when the design needs to be distinctive anyway, or when the dependency surface matters, since React 19, sharp, several remark plugins and a Swiper integration come along whether or not you use them.

Editorial conclusion

Adopt Astroplate if you want a complete, good looking Astro site in an afternoon and are willing to delete the parts you do not need, since fifteen designed pages and a theme system are already wired. Do not adopt it as a long lived product base without checking the dependency surface, because the template carries React, several remark plugins and sharp, and none of them are optional. Verify first by running the development command and the build command on a clean clone with pnpm, then by generating the llms.txt output and checking the routes it lists, and by reading the image licensing note, since the pictures in the repository are for demonstration and are not licensed for reuse.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. zeon-studio/astroplate on GitHub