Lume builds a site from a CDN URL with every permission granted

The whole install is one deno run line pointed at jsDelivr

There is no package to add to a manifest. The quick start assumes you have Deno installed, then asks you to run the CLI straight from a CDN URL:

deno run -A https://cdn.jsdelivr.net/gh/lumeland/lume/cli.ts

That single line is the install, the build and the update path in one. Output lands in a directory named _site, and the badge in the README tracks the gh/lumeland/lume package on that CDN. Because the URL points at the gh/lumeland/lume package on jsDelivr, and a badge in the README tracks that package, the version you build with is whatever the CDN is serving rather than a pin you wrote down. That is the whole trade: no dependency file to commit, and no lockfile pinning the generator itself. The -A flag is the part to notice first, since it grants the process every permission Deno offers, file writes and network access included, and the script at the other end of that URL is fetched at run time. The README does not walk back that choice, and it does not document a narrower invocation that would build the same site.

The security claim sits next to the unrestricted flag

The feature list argues that because this is Deno you can "Forget about managing thousands of packages in node_modules or complex bundlers," ending with "Clean, fast and secure." Then the very next section runs the generator with -A. Those two statements are in tension and a careful reader will notice. Permission isolation is the argument Deno makes over Node, and -A switches it off for the build step: the process can write anywhere the user can write and read anywhere the user can read. The secure framing holds for the dependency tree, in the sense that Lume installs only what a site imports, but it does not hold for the CLI invocation. One concrete number makes the permission point sharper: -A grants the process every permission Deno offers, while a narrower invocation would grant one. The repository layout backs up the dependency argument instead: there is no vendor directory and no package manifest of the Node kind, and the code splits into core/, plugins/, middlewares/, deps/, cli/ and mod.ts, with types.ts and lint.ts at the root. If your threat model includes a build step running with ambient authority, that is a decision to make deliberately rather than inherit from the README.

Formats are handled by processors, not by one templating engine

Lume's distinguishing feature is that a site is not tied to a single template language. Seven file formats are named as supported: Markdown, YAML, JavaScript, TypeScript, JSX, Vento and Nunjucks, and extending the set is presented as easy. The mechanism behind that claim is visible in the directory names rather than in prose: plugins/ is where format support lives, middlewares/ is where the processing pipeline hooks in, and deps/ holds the external code the default setup pulls in. The same idea covers assets rather than pages: any processor can be hooked to transform them, with Terser named for JavaScript and PostCSS for CSS. That is the architectural point worth taking away. A site that adds a format or an asset step is adding a plugin, not reconfiguring a single engine, and the same sentence covers both page formats and binary pipelines. The design overview for that mechanism lives in the documentation at https://lume.land rather than in the README, so the plugin contract itself is not visible from the repository root.

The first page is a Vento file with a YAML front matter block

The quick start creates a file called index.vto rather than index.html or index.md, which shows the default template choice immediately. The file is a Vento template with a front matter block at the top carrying a single title key, and the body interpolates that title twice, once into the document head and once into an h1:

---
title: Welcome to my page
---
<html>
  <head>
    <title>{{ title }}</title>
  </head>
  <body>
    <h1>{{ title }}</h1>
  </body>
</html>

Two details are worth naming. The interpolation syntax is {{ title }}, which is the Vento style rather than the {{ }} double-brace-plus-hyphen form used by other template engines, so a template ported from another generator usually needs its delimiters adjusted. And the example is a full HTML document, not a layout plus a content slot, so the structure of a real site has to come from conventions the README does not spell out. The .vto extension is what binds the file to the Vento processor, which is the concrete form of the plugin idea above.

lint.ts, serve.ts and archetypes are the parts the README skips

Three top-level entries say more about day-to-day use than the feature list does. serve.ts sits at the root, next to cli.ts, which means the project ships a serving entry point of its own rather than leaving local preview to an external tool. lint.ts is another root-level entry and has its own dedicated file, so formatting and lint rules are part of the project rather than a matter of which editor plugin you install. archetypes/ is a directory of templates for scaffolding new content, which is the generator equivalent of a cookiecutter and the mechanism behind starting a post from a predefined shape. cli/ and cli.ts together mean the command-line surface is split across a directory and an entry file rather than being one script. None of this is described in the README, which stops after the quick start. If you want to know what commands exist, you read cli/.

The Jekyll and Eleventy comparison has no numbers attached

Lume is positioned against Jekyll and Eleventy by name and then makes three claims: faster, simpler, easier to use and configure, and flexible. No measurement supports the first one. There is no benchmark directory in the top-level listing, no table, and no link to a comparison page in the README itself. Every concrete number the project gives you is an implementation detail: the _site output directory, the .vto extension, the -A permission flag. The flexibility claim is the one that is easiest to check, and the plugin, middleware and processor structure described above is the evidence for it. The speed claim is the one to treat as an untested premise. The repository does include a tests/ directory and a CHANGELOG.md that the README points to for recent changes, which is where you would look to understand behavior differences between versions, but neither is a substitute for a benchmark.

Where Lume is the wrong tool

The binding constraint is the runtime. Lume targets Deno, and the whole quick start assumes it: the CLI is a TypeScript file executed by deno run, and the repository is organized as Deno modules with deps/ rather than as a Node package with a package.json. A team that cannot run Deno in CI or on its build images has no path here that the README documents. The second constraint is the execution model. Running the build from a CDN URL means the code that builds your site is fetched at the moment you run it, and -A means it runs with your full authority. Pinning a versioned URL rather than the unversioned path is the obvious mitigation, but the README does not discuss it, and there is no lockfile in the repository listing that would record what a previous build used. The third is scope, and the last push was on 2026-09-23. Incremental builds, a content collection model and a plugin API are all absent from the front page, so anyone whose site depends on those has to read the docs before committing. The community entry points are a Discord invite and an Open Collective organization, with no issue tracker guidance for larger features.

Editorial conclusion

Lume fits a writer or a small team already inside Deno who wants templating and asset processing without a node_modules tree. It does not fit a team that has to stay on Node.js, and it does not suit anyone who needs the Jekyll or Eleventy comparison taken at face value, because no figure is attached to that claim anywhere in the README. Before adopting, read exactly what -A grants the CLI process, then open cli.ts and serve.ts at the repository root to see what you would be executing straight from a CDN URL.

Frequently asked questions

Official sources

1. License: MIT
2. lumeland/lume on GitHub
3. Project website
4. README
5. Releases