Publii: a desktop static site CMS for people who do not want a terminal

The gap Publii fills: a CMS interface on top of a static build

Static site generators produce fast, cheap-to-host HTML, but most of them expect you to author content in plain text files and run a build command. That is fine for developers and hostile to everyone else. Publii takes the opposite position: the authoring surface is a graphical desktop application, and the static output is a consequence of pressing a button rather than a step you orchestrate.

The README frames the comparison directly, describing Publii as an alternative to generators that are "often unwieldy and difficult to use" and positioning its UI alongside server-based systems such as WordPress or Joomla!. The audience is therefore not the engineer who already has a Hugo or Eleventy setup. It is the person who wants the output of a static site and the editing experience of a traditional CMS, on a single machine, without a database on the server.

That framing also sets the boundary. Publii is a desktop program, not a service. There is no hosted backend, no multi-user login, and no server-side admin panel to expose to the internet. The site that reaches your hosting is HTML and assets only.

How Publii works: local app, local content, uploaded HTML

The architecture follows from the repository layout. The Electron entry point is app/main.js, declared as "main" in package.json, with the interface built from Vue and the templates rendered through Handlebars, both of which appear in the repository topics. The application is packaged per platform, which is why the download page offers .exe, .dmg, .deb, .rpm and .AppImage artifacts.

The data flow is local-first. You create a site inside the app, write posts, pick a theme and adjust its options, and the app renders the site on your machine. Because nothing depends on a remote server during authoring, the README notes that you can create, update and modify your site offline and upload changes later. Publishing is a separate step: the generated files are pushed to your chosen destination. The README lists standard HTTP/HTTPS servers, Netlify, Amazon S3, GitHub Pages, Google Cloud and SFTP as upload options.

Two consequences are worth stating plainly. First, the content lives in the app's local storage, so the machine holding it is the source of truth; there is no server-side copy to fall back on. Second, anything that requires runtime logic, such as comments, search or form handling, cannot be served by the static output itself and needs an external service. The README does not describe a built-in mechanism for those.

Installing Publii and publishing a first site

Publii is not installed from a package registry. The README points to the download page, which offers installers for Mac, Windows and Linux in .exe, .dmg, .deb, .rpm and .AppImage formats. Pick the artifact for your platform and run it as you would any desktop application. There is no npm install step for end users; the npm scripts in package.json belong to the app build process described in the project wiki, not to normal use.

Once the app is open, the workflow is a site creation wizard followed by a publish action. The exact screen labels are covered in the user documentation rather than the README, so treat the steps below as the shape of the flow, not a literal transcript.

If you are building Publii from source rather than downloading it, the repository defines these scripts. The wiki page linked from the README, App build process, is the authority on prerequisites and order.

npm run dev
npm run prod
npm run build

The dev script runs webpack in development mode with a watcher, prod builds a production bundle, and build updates the build number and launches Electron against the app directory. After the site is generated in the app, choose an upload destination. The destinations the README names are a standard HTTP/HTTPS server, Netlify, Amazon S3, GitHub Pages, Google Cloud and SFTP; you supply the credentials for whichever you pick, then trigger the upload. What you should see afterwards is the same set of HTML files and assets on the remote host that the app rendered locally.

Themes and plugins are the real extension surface, and it is a marketplace-shaped one

Publii's customisation model is themes plus plugins, configured through the app rather than through code you write. The README states that users style their site using built-in themes and options. That is a deliberate ceiling: a theme with a rich options panel can take you far without touching a template, but the moment you need behaviour the theme does not expose, your choices narrow to editing the theme itself or finding a plugin.

The related searches around Publii themes, free Publii themes and installing a Publii theme suggest this is where most users spend their attention. The README does not document the theme installation procedure itself; it directs readers to the user documentation at getpublii.com/docs and the developer documentation at getpublii.com/dev. Anyone evaluating Publii should read those two sites before deciding, because the README is essentially a landing page plus a build reference, not a manual.

One practical point follows from the version numbers. The releases listed are patch-level builds of 0.47.x, with v.0.47.9-build-17481 dated 2026-07-23. A theme or plugin that has not been touched in a long time may not match the current build's template variables or option schema. The README does not promise backward compatibility for third-party themes across versions, and it does not describe a deprecation policy.

Where Publii is the wrong tool

The strongest limitation is collaboration. Because the editor is a desktop application and the content is local, there is no shared drafting space. Two people cannot edit the same site concurrently through Publii's interface, and there is no browser-based admin panel for a contributor who cannot install software. If your publishing process involves a writer, an editor and a reviewer on different machines, Publii adds a handoff problem rather than removing one.

A second limitation is programmatic access. Nothing in the README or package.json describes a content API, a GraphQL endpoint or a headless mode. If you want to reuse the same content in a mobile app, a separate front end or an automated pipeline, Publii is not built for that; the output it produces is a finished site, not a queryable content store.

A third is the single-machine dependency. Offline editing is presented as an advantage, and it is, but it also means the working copy of your site lives on one disk. The README does not document a sync, export or rollback mechanism for that local store. Whether the app's internal backups are sufficient is something you have to establish yourself before you trust it with content you cannot regenerate.

Finally, the tool assumes a graphical desktop session. On a headless build server or in a container-based CI pipeline, Publii has no role; you would be running a static generator instead.

Publii against a command-line static site generator

The obvious alternative is a generator such as Hugo, Jekyll or Eleventy. The difference is not the output, which is HTML either way, but where the complexity sits. A generator puts it in your repository: content as files, configuration as a config file, templates as templates, and publishing as a command you run in CI. That arrangement is scriptable, diffable and reviewable, and it scales to a team because everything is text under version control.

Publii moves that complexity into the application. You get a familiar editing interface and no build configuration to learn, at the cost of the properties above. There is no pull request that shows what changed in a post before it goes live, no CI job that reproduces the build, and no way to run the whole thing on a server.

A fair way to decide: if your site is authored by one person on one computer and the content is not consumed anywhere else, the generator's advantages are mostly theoretical and Publii's interface is the better fit. If the content needs to be reviewed, reproduced or reused, the generator's file-based model is doing real work that Publii does not attempt. The README's own comparison is with server-based CMSs like WordPress, which is telling: Publii is competing for the WordPress user who wants static output, not for the developer who already has a build pipeline.

Licence, maintenance and what an upgrade costs you

Publii is licensed GPL-3.0, with the copyright line in the README reading Copyright (c) 2026 TidyCustoms. For normal use this changes nothing: you download the app, build a site, and host the output. The licence matters if you intend to redistribute the application or a modified version of it, because GPL-3.0 carries obligations about source availability for derivative works. The README points to getpublii.com/license.html for the details. That is a question for a lawyer if your plans involve redistribution, not something to settle from a README.

On maintenance, the repository is not archived, and the last push was on 2026-09-21. Releases are frequent patch builds: v.0.47.9-build-17481 on 2026-07-23, v.0.47.8-build-17475 the day before, and v.0.47.7-build-17468 on 2026-07-02. That cadence is visible in the release list and is the only maintenance signal available here.

The upgrade cost falls on themes and plugins rather than on the core. The app updates as a desktop application, but a third-party theme built against an older 0.47.x build may need attention when template variables or options change. The README does not describe a migration path for third-party themes, so the practical check before upgrading is whether the theme's maintainer has shipped a build for the current version. Content itself is not described as version-sensitive, but the local-only storage means an upgrade you cannot reverse is a risk you should think about before running it.

Editorial conclusion

Adopt Publii if you want a static site, you work mostly from one machine, and you would rather click through a theme's options than write a build pipeline. Do not adopt it if you need a browser-based editor for several contributors, a plugin API you can extend in code, or a headless content API for a separate front end. Before committing, verify three things on your own machine: that your chosen theme is still updated for version 0.47.9, that your hosting target is one of the supported upload options, and that your site's content fits in a repository you are willing to carry between computers. The repository's last push was on 2026-09-21 and the latest release listed is v.0.47.9-build-17481 from 2026-07-23.

Frequently asked questions

Official sources

1. GetPublii/Publii on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases