Electron Forge: one toolchain from create-electron-app to a packaged build

The problem Electron Forge solves for desktop app teams

An Electron app is three build problems wearing one trench coat. You have to scaffold a main process, a renderer and a preload script. You have to rebuild any native Node module against the Electron ABI rather than the Node ABI, which is the step that breaks most first attempts at shipping. And you have to turn the result into a distributable artifact per platform: a dmg, an installer, a package. Each of those has an established tool, and each tool has its own configuration surface.

Electron Forge's stated goal is to unify those tools behind one dependency. The README frames it as making Electron start "as simple as a single command" and sparing developers from setting up build tooling and native module rebuilding. The audience is therefore not people who enjoy configuring build pipelines. It is app developers who want the pipeline to be somebody else's job, and teams who want every Electron project in the org to be packaged the same way.

The repository is a Yarn workspace monorepo: packages/ holds the CLI and the plugin and maker packages, tools/ holds internal scripts, and the root package.json is private with version 0.0.0-development, which is the standard marker for a repo that versions its published packages individually rather than as a single artifact. That structure tells you what you are adopting: a collection of versioned packages, not one monolithic binary.

How the Forge pipeline moves from source to installer

The mechanism is a plugin and maker model. Plugins handle how the app is built and bundled during development and packaging; makers handle the final artifact for a target platform. The core does not implement either itself. The README names two dependencies it builds on: @electron/rebuild, which recompiles native Node modules against the correct Electron version, and @electron/packager, which customizes and bundles the app for distribution. Forge is the orchestration layer over those.

The practical consequence is that the interesting configuration lives in the plugin and maker you choose, not in Forge itself. A webpack-based setup and a Vite-based setup are different plugins with different config keys, and the artifact you get depends on which maker you register. The website hosts a configuration reference, and the README points there rather than reproducing it, so the README alone is not a sufficient configuration guide. If you are evaluating Forge, read the configuration docs for the specific plugin and maker pair you intend to use, because that pair is your actual build system.

The monorepo layout reinforces this. Because plugins and makers are separate packages under packages/, they version and release independently of the CLI. A change in a maker does not require a CLI release, which keeps the surface small but also means your effective toolchain is a set of package versions you should pin deliberately.

Installing Electron Forge and running your first app

The README states two pre-requisites: Node 22.17.0 or higher, and Git. The root package.json engines field agrees, declaring node >= 22.17.0. If your CI image or local Node is older, stop there; nothing else will work.

Scaffolding goes through the create-electron-app CLI, which the README describes as the way to initialize a project. This is the only install path the README documents:

npx create-electron-app@latest my-new-app

That command creates a directory named my-new-app containing a template project. The README then gives two more commands to move into it and start it:

cd my-new-app
npm start

What you should see is an Electron window launched from the template, running from source rather than from a packaged build. That is the development loop. Packaging is a separate step driven by the makers configured in the generated project, and the README does not spell out those commands; it defers to the CLI documentation on electronforge.io. Before you trust the template, open its configuration file and read which plugin and which makers were generated, because that file is what determines the artifact you will eventually ship.

One detail worth noticing during setup: the monorepo's own scripts use xvfb-maybe to wrap vitest runs, which is how the project handles headless test environments on Linux. That is internal tooling, not something you configure, but it signals that CI on Linux without a display is a case the maintainers actively handle.

Where Electron Forge is the wrong tool

Forge assumes it owns the build. If you already have a working pipeline, adopting Forge means replacing it, not augmenting it, and the migration cost is the cost of re-expressing your packaging logic as a Forge maker. Teams with unusual artifact requirements, such as a custom signing and notarization sequence or an installer format no existing maker covers, will spend their time writing a maker rather than shipping, and at that point the value of the unified toolchain is mostly gone.

The second boundary is version currency. The releases listed for the repository show v7.11.2 as the stable line and v8.0.0-alpha.10 as an alpha published on 2026-07-02. If your project needs behaviour that only exists on the v8 line, you are building on an alpha, and the repository does not present it as anything else. Pinning to v7.11.2 is the conservative choice, but it also means you are not on the newest plugin and maker APIs.

The third boundary is transparency. The README is a short pointer document: it links to the website for documentation and usage and does not document packaging commands, maker configuration, or rollback behaviour. If your team needs a tool whose full behaviour is legible from the repository alone, Forge will send you to a separate site for the parts that matter most. That is a deliberate documentation split, not an oversight, but it changes where you look when something breaks.

Electron Forge compared with assembling the tools yourself

The real alternative is not a different framework. It is using the same underlying tools directly: @electron/packager for bundling and @electron/rebuild for native modules, wired together by your own scripts. That is precisely what Forge does internally, so the comparison is honest about what you gain and lose.

Going direct gives you full control over the sequence. You decide when the rebuild runs relative to the bundle, how the artifact is named, and what happens when a step fails. You also own every upgrade: when packager changes an option, you change your script. Forge's difference is that the sequence is defined by the plugin and maker you select, so upgrades arrive as package version bumps with the wiring already adjusted. The trade is control for maintenance surface.

A second alternative is a general-purpose bundler plus a separate packaging step, where the bundler handles renderer code and something else handles the distributable. That splits the concern Forge tries to merge, and it is a reasonable choice if your renderer build is already sophisticated and you do not want Forge's plugin sitting in the middle of it. The decision rule is simple: if your build is standard, Forge removes work; if your build is unusual, Forge adds a layer between you and the tools you would otherwise call directly.

Maintenance, release channels and what the MIT licence means here

The repository is not archived, and the last push was on 2026-09-21, so the codebase is being touched. That is a statement about repository activity, not a promise about any individual package. Because the project is a monorepo with per-package publishing, the maintenance question you should ask is not whether Forge is alive but whether the specific plugin and maker packages you depend on are receiving releases. Check those package versions, not the repository as a whole.

Upgrade cost has two axes. The first is the Forge major line: v7.11.2 is stable and v8.0.0-alpha.10 is an alpha, so moving to v8 means accepting alpha status on your build toolchain. The second is the underlying tools. When @electron/packager or @electron/rebuild change behaviour, Forge's packages must follow, and your app inherits that change on the next bump. Neither axis is expensive if you pin versions and upgrade deliberately; both are expensive if you float on latest.

The licence is MIT, declared in both the README badge and the root package.json. That is a permissive licence, which generally means you can use and redistribute the tool in commercial and closed-source projects with the licence and copyright notice preserved. This is a description of what MIT typically permits, not legal advice; if your organisation has specific compliance requirements around bundled build tooling, have your own counsel review it rather than treating this paragraph as clearance.

Editorial conclusion

Adopt Electron Forge if you are starting a new Electron desktop app and want scaffolding, native module rebuilds and packaging handled by one dependency instead of a hand-assembled pipeline; the create-electron-app template plus npm start is the shortest path to a running window. Do not adopt it if your build is already a working custom pipeline you understand, or if you need to target an Electron version the current makers do not cover. Before committing, verify that your native modules rebuild cleanly under @electron/rebuild, that the maker for each target platform produces an installer you are willing to ship, and which release channel you are pinning: v7.11.2 is the stable line while v8.0.0-alpha.10 is an alpha published on 2026-07-02. The deciding factor is your native module surface, not the CLI ergonomics.

Frequently asked questions

Official sources

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