Plenti: a static site generator that ships a Git CMS with it

One binary, no toolchain, and the requirement that was deleted

Plenti is a Build-Time Render Engine, which the project describes as a Static Site Generator, with a Go backend and a Svelte frontend, and it ships with a fully integrated Git-CMS that you can host for cheap or free right with your static site.

The requirements line is the most interesting thing in the readme, because it is a requirement with a strikethrough through it. You must have NodeJS version 13 or newer, and then the crossed-out version, followed by the note that as of v0.2.0 you no longer need NodeJS, Go, or any dependency other than Plenti itself.

That is the whole pitch in one edit. A static site generator that needs a JavaScript toolchain to install is a static site generator for JavaScript developers. One that ships as a single binary is a static site generator for anyone.

The Dockerfile shows how that binary is put together, and it is about as small as a Go image gets. A first stage based on `alpine:latest` installs the ca-certificates, and the second stage is `FROM scratch` with only the certificate bundle and the `plenti` binary copied in, with `ENTRYPOINT ["/plenti"]`. There is no shell, no package manager and no libc in the final image, because a statically linked Go binary does not need them.

That matters for more than download size. A scratch image is about as small as a container gets, it has no shell for anyone to drop into, and it cannot be compromised through a package update, because there are no packages. The `.goreleaser.yml` at the root is what produces the release artefacts for all the platforms the binary is distributed to.

Four install routes and one explicit platform gap

The installation section lists four routes, and one of them carries a warning that is easy to skim past.

Homebrew is two steps: add the tap with `brew tap plentico/homebrew-plenti` and install with `brew install plenti`.

Snap is a single command, `snap install plenti`.

Scoop is two steps as well, adding the bucket with `scoop bucket add plenti https://github.com/plentico/scoop-plenti` and then `scoop install plenti`. But the Scoop entry is marked with a warning that Windows is not supported yet, with a link to the details in an issue comment. So the Windows package manager route exists in the documentation, and the documentation also says it does not work on Windows yet. That is an unusual thing to publish and worth taking at face value: the Scoop bucket is there for a future Windows release rather than a current one.

The manual route is the most direct: download the latest release and move it somewhere in your `PATH`, most likely `/usr/local/bin`.

The fact that all four routes exist tells you something about the audience. Homebrew, Snap and Scoop are the three package managers people reach for when they want a tool to be a normal part of their machine, and each one puts the binary in a different place and manages upgrades differently. The manual route exists for the case where a user has none of them, and it puts the responsibility for upgrades on the user.

The site is at plentico.co, and the documentation is at plentico.co/docs with a YouTube playlist for the basics.

Four commands, and a dev server on port 3000

The getting started section is four steps, and they are the whole quick start.

plenti new site my-new-site
cd my-new-site
plenti serve

The first command creates a site, the second moves into the directory it created, and the third starts the development server, which you then open at localhost:3000.

That is a deliberately small surface. A generator that requires you to write a config file before the first render, or that needs a dependency install inside the project, adds a step that a new user has to get past before they see anything. Here the first output of `plenti new site` is a site you can serve.

The command structure comes from cobra, and the `cmd/` directory at the root of the repository is where the commands live, with `main.go` as the entry point.

The project is a Go module named `github.com/plentico/plenti`, requiring Go 1.23.0 with a toolchain directive for go1.23.7, and the dependency list is worth reading for what the tool actually does. `github.com/evanw/esbuild` is the JavaScript bundler, so the Svelte frontend is compiled by esbuild rather than by a Node toolchain, which is the mechanism behind the no-Node requirement. `tdewolff/minify/v2` handles the minification of the output. `go-git/go-git/v5` is the pure Go git implementation, and that is the mechanism behind the Git CMS: the CMS does not shell out to the git binary, it drives a git library directly, so a static site editor can commit without a git executable on the machine.

The rest of the list is the usual Go command line furniture: `spf13/cobra` and `spf13/afero` for commands and the filesystem abstraction, `manifoldco/promptui` for the interactive prompts, `briandowns/spinner` for progress, `fsnotify` for watching files during development, `go-playground/validator` for validating configuration, and `MakeNowJust/heredoc` for the embedded text in the help output.

Readers, writers and defaults, which is the whole architecture

The top-level directory listing is a description of the pipeline.

There are `readers/` and `writers/` directories, and the names describe the two halves of a static site generator's data flow. Readers take content and data from somewhere and turn it into a common representation, and writers take that representation and emit output. A site has content, and a site has pages, and those are usually different sources, which is why the two are separated.

There is a `defaults/` directory, which holds the default configuration and default content, and a `scripts/` directory, and a `docs/` directory.

The dependency list adds two things that explain the Git CMS more precisely. `livebud/npm` is a tool for running npm packages, and `rogchap.com/v8go` is a JavaScript runtime for Go, which is how a Svelte component is executed during the build. That is the mechanism for a Svelte frontend in a Go tool: the components run in a JavaScript engine embedded in the Go binary, so there is no separate Node process, no `node_modules` in the project and no Node to install.

`github.com/gerald1248/httpscerts` and `golang.org/x/net` are the certificate and networking pieces, and `dario.cat/mergo` and `Masterminds/semver` are for merging configuration and comparing versions, with semver being the relevant one for a generator that deals with dependency versions in a site's package configuration.

So the architecture is: Go reads your content and your data, executes Svelte components through an embedded JavaScript runtime, bundles the frontend with esbuild, and writes static output. The Git CMS is a mode of the same binary rather than a separate service.

The Git CMS is the part that changes the audience

Most static site generators solve the writing problem badly. You either write markdown in a text editor, which is fine if you are comfortable with git and terrible if you are not, or you use a hosted CMS and pay for it, or you build your own admin interface.

Plenti's answer is to ship one. The description says it ships with a fully integrated Git-CMS that you can host for cheap or free right with your static site, and the topic tags include `git-cms` and `jamstack`.

The mechanism follows from the go-git dependency. If the CMS is a git client, then a non-technical editor can write content through a web interface and the result is a commit in the same repository the site is built from. There is no database to host and no separate admin application to secure, because the editor interface and the static site can be the same deployment.

That is a real answer to the cost problem the readme mentions, hosting cheaply or for free, and it is a genuine architectural constraint too. A CMS that commits to git has a different shape from one that writes rows: every edit is a version, every publish is a commit, and the editorial workflow becomes a branch and a merge.

The contribution section sets expectations about the project's stage honestly. Plenti is still new but constantly improving, and the API might change from time to time before we hit a stable v1.0.x release. It asks for issues rather than assuming questions will be answered, and it asks for donations with the reasoning spelled out, so that the maintainers can spend more time on improvements and the project stays free of commercial interests.

The release history is consistent with that framing. The versions are 0.7.x, with v0.7.26 from 2026-10-14, v0.7.25 from 2025-07-23 and v0.7.21 from 2025-06-28, and the last push was on 2026-10-14.

Where Plenti is the wrong choice

The first case is a project that needs a stable API. The project says it directly: the API might change from time to time before a stable v1.0.x release. The version line is 0.7.x, which is the last series before a 1.0, so a team adopting it should expect to absorb breaking changes at some point, or to pin a version and live with it.

The second case is a large content operation. A git-based CMS is a good fit for one author, a handful of authors, or a team that reviews changes anyway. It is a poor fit for a newsroom with a dozen editors, a scheduled publishing workflow, an approval queue and a need to know who changed what without reading a diff.

The third case is a project with heavy frontend requirements. The Svelte components run inside an embedded JavaScript runtime in the Go binary. That is an elegant way to avoid a Node toolchain, and it is a constraint on what you can use, because the component build is esbuild through a Go wrapper rather than the full Svelte toolchain with its own plugins and loaders. A site that needs the wider npm ecosystem of frontend tooling is looking at a different generator.

The fourth is Windows, for now. The Scoop route exists and the documentation marks Windows as not supported yet, so a Windows-only team has to fall back to the manual binary download and manage upgrades themselves.

One more observation about the shape of the dependency list. The tool embeds a JavaScript runtime, a bundler, a git implementation, a minifier and a certificate store in one binary. That is a large amount of machinery in one executable, and it is the direct consequence of the requirement to be dependency-free. It works, and it is genuinely convenient, but it also means the binary carries two JavaScript toolchains, esbuild and the v8 runtime, and both of them move independently of the project.

Editorial conclusion

Plenti fits a writer or small team that wants a static site with an editorial interface on the same repository, where the CMS is a git commit rather than a separate database and admin panel. It does not fit a project that needs a large content workflow, a component library, or a stable API, since the project states the API may change before a stable v1.0.x. Before you adopt it, run `plenti new site` and look at what the generated Svelte project gives you, and read the Windows support note, because Windows is explicitly not supported yet in the Scoop route.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. plentico/plenti on GitHub
3. Project website
4. README
5. Releases