Freeter: one place to keep the setup for every project you work on

The problem is reconstructing a setup, not storing files

Freeter is described as a free and open-source organizer for people who work on their computer, and the description of what it does is narrower than that phrase suggests.

It lets you gather everything you need for work in one place, organized by projects and workflows. So the unit is a project, and within a project there are workflows, and each of those holds the things you need: the applications to open, the files to reach, the links to visit, the commands to run.

The access mechanism is what makes it usable rather than merely tidy. You reach your setup with `Ctrl or Cmd`+`Shift`+`F`, or from the tray icon. That is the whole interaction model. You do not browse a folder tree to find a launch script, you press a shortcut and get the thing you were going to assemble by hand.

The stated benefit is about attention rather than storage. Switch effortlessly between workflows, stay focused on what matters now, and reduce context-switching. That framing is the honest description of what the app does, because it is not a file manager and it is not a launcher in the sense of an application launcher. It is a saved set of per-project intentions, brought back with one keystroke.

The project also publishes a longer introduction as a blog post linked from the README, and the site has separate pages for downloads, the community forum, donations, a roadmap, feature requests and bug reports. That last set of pages is a small signal about how the project is run: the roadmap and feature request categories live in the project's community forum, so the direction of the project is decided in a place you can read.

An Electron app with three webpack bundles and a preload script

The repository layout shows how the application is put together, and the answer is a conventional modern Electron project with a few specific choices.

There are three webpack configuration files, `webpack.main.config.js` for the main process, `webpack.preload.config.js` for the preload script and `webpack.renderer.config.js` for the renderer, which is the three-part split that Electron projects use to keep the privileged code separate from the untrusted one. The `package.json` scripts confirm the same structure, with separate `prod:renderer`, `prod:main` and `prod:preload` steps and matching development ones.

The main process bundle is the one that matters for security, and the fact that a preload script exists at all is the point. A preload script is the only bridge between the renderer and Node's APIs, and a project that ships one is making the choice to expose a controlled, minimal surface rather than enabling `nodeIntegration` in the window. For an app that launches applications and reads files on your behalf, that distinction is not academic.

Packaging is handled by `electron-builder.config.js`, and the `resources/` directory holds per-platform assets, with the Linux icons visible in the README pointing into `resources/linux/freeter-icons/`. The build output is a `dist` folder.

The rest of the tooling is standard but worth noting for a project people install rather than publish: `jest.config.js` for tests, `eslint.config.mjs` for linting in the flat config format, `tsconfig.json` for TypeScript, and `.vscode/` for editor settings. The `backers.json` file at the root is a list of the project's backers.

Building from source is three npm commands and a dist folder

The build instructions are short, and the prerequisite is deliberately minimal.

The only requirement for building is NodeJS, and the documentation notes explicitly that this is for building the app and is not needed for running it, since the installers bundle everything. The steps are to download the source from the download page or the GitHub releases page, unpack it, and then run three commands:

npm install
npm run prod
npm run package

The first installs the dependencies, the second compiles the code, and the third packages the app. The built package then appears in the `./dist` folder.

Looking at what `npm run prod` actually does in the manifest explains the second step better than the one-line description does. It removes the `build` directory, copies the assets, and then runs the three webpack builds concurrently, with the renderer, main and preload bundles built in parallel and each tagged in the output so you can see which one failed. The asset step uses `copyfiles --up 1 src/assets/**/* build/`, which flattens the asset tree one level, and the packaging step then runs electron-builder.

The development scripts are a separate set, and they are more elaborate than the production ones. `npm run dev` starts react-devtools alongside the app, and the `dev:no-react-devtools` script clears the build directory, copies the assets, builds the preload, and then runs the renderer dev server, the main process watcher and the app itself concurrently, again with named and coloured output. A nodemon script watches the built main file and relaunches Electron when it changes.

Platform support is specific, and macOS has two architectures

The supported operating systems are listed precisely, and the list has one entry that narrows the reach.

Linux is supported on most distros, Intel 64-bit. Windows 10 and later is supported, Intel 64-bit. Mac OS 10.15 and later is supported, on both Intel and Apple Silicon.

So the Apple Silicon build exists, and the app runs on current macOS. What is not listed is 32-bit anything, and there is no ARM Linux build, which leaves a 32-bit Linux user or an ARM Linux user without an installer. That is a normal constraint for a small desktop project, but it is worth checking against your own machine before you plan around it.

The platform differences show up in the repository as separate resource directories, with `resources/linux/freeter-icons/` being one of them, and electron-builder handles the rest. The tray icon that the README mentions as an alternative to the keyboard shortcut is a per-platform concern too, and a Linux desktop with an unusual status area is the case most likely to behave differently from the others.

Ready-to-use installers for all supported systems are on the download page, and the GitHub releases page carries the same builds, which is also where you get the source archive for a from-source build.

The release line is on 2.x, and every tag is a beta

The version history is worth reading carefully, because it tells you what kind of software this is.

The three most recent tags are all betas. v2.8.0-beta was published on 2026-05-19, v2.7.1-beta on 2025-06-24 and v2.7.0-beta on 2025-06-17. The `package.json` version matches the newest one, 2.8.0-beta, and the package description is the short phrase Organizer For Those Who Do.

A project that tags every release as a beta is signalling something specific. This is software that is stable enough to use every day and is distributed as a beta because the maintainer has not committed to a compatibility promise for the 2.x line. That is a reasonable stance for a desktop utility whose state format might change, but it means the version number in a bug report tells you less than it would in a project with stable tags.

The licence is GPL-3.0-or-later, and the README states it plainly: Freeter is free software and may be redistributed under the terms specified in the license, which is a COPYING file at the root of the repository. The GPL is a strong copyleft licence, and it is a reasonable choice for a project that is funded by donations and wants to stay free, though it does put a constraint on anyone who wanted to build a closed-source product on top of it.

The last push to the repository was on 2026-05-27, and the repository is not archived.

Where Freeter is the wrong tool

The first case is a team that wants a shared, version-controlled configuration. Freeter's state is the state of a desktop application, which means it lives in the user's profile rather than in a repository you can commit, review and share. A team onboarding a new colleague has to describe their setup in a document rather than handing over a file. If what you want is a dotfiles repository of per-project launch commands, a plain directory of shell scripts or an editor workspace file is a better fit, and it will not need an Electron application in the middle of it.

The second case is a single-project workflow. The value of the tool scales with the number of contexts you move between. If you work on one project, the setup is one directory, and the overhead of launching an application to reach it is larger than the time it saves.

The third case is a workflow that needs real automation rather than a launcher. Freeter opens applications, files, links and commands. If the thing you want is a script that runs on a schedule, watches a directory and acts, then a launcher is the wrong abstraction, and the fact that it launches commands does not make it a scheduler.

There is one practical caveat about running it from source rather than installing it. The development flow is a multi-process affair with a webpack dev server, a main process watcher, nodemon relaunching Electron and react-devtools attached, and the production build is a separate parallel path. That is normal for Electron and it works, but it is more moving parts than a typical Node project, so a team that wants to patch Freeter itself should budget for a working Electron toolchain rather than a Node one.

Editorial conclusion

Freeter fits a person who juggles several projects or several roles and repeatedly loses the same ten minutes reconstructing a workspace, and it does not fit someone who wants a shared, version-controlled configuration, because the state lives in a desktop app rather than in files you can commit. Before installing, check the download page for a build matching your platform, since the supported systems are listed as Linux on most distros, Windows 10 and later, and Mac OS 10.15 and later, and read the roadmap page before expecting a particular feature, because the project tracks planned features in its own community forum.

Frequently asked questions

Official sources

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