Forel: a GPLv3, on-device Hazel alternative for macOS folder automation

What Forel solves, and who it is actually for

Forel is a macOS menu bar app that watches folders and applies rules to files as they appear. The README frames it as "The Hazel alternative for macOS. Open source and privacy-focused." Its stated scope is narrow and concrete: match by filename, extension, kind, size, date, tags, or Finder color label, then move, copy, rename, tag, trash, delete, or run a custom script. The README's own example shows a Downloads folder split into Work/Invoices/2026, Photos/2026/March, Work/Legal/Pending and Finance/2026.

The audience is macOS users who already know what they want their folders to look like and are willing to encode that as conditions. It is not a search tool, not a syncing tool, and not a document management system. The README repeats one constraint twice: "100% on-device, local-first, no account, no telemetry" and "Your files never leave your Mac." For anyone who has avoided Hazel-style automation because it felt like a black box, that sentence is the pitch. It is also a hard boundary: anything that requires a server, an API key or a cloud OCR service is out of scope by design.

How the rule engine, FSEvents watcher and SQLite store fit together

The README documents the execution pipeline in stages. Input arrives from three places: FSEvents for real-time watching, Run Now for a manual pass over a whole folder, and Dry Run / Preview, also manual and whole-folder. From there the rule engine runs per file, sorted by cost. That ordering detail matters: cheap checks such as extension or name run before expensive ones, and the Contents condition, which reads text inside files, sits at the end of the condition list.

The engine does three things in sequence. It checks scope, which the README describes as recursion depth. It matches conditions across name, extension, kind, size, date, tags, color label and contents. Then it plans actions with conflict awareness before the action executor touches anything. Actions are Move, Copy, Rename, Tag and color label, Trash and Delete, Run Script and Shortcut. Every action lands in a History / Undo table backed by SQLite.

The repository layout matches that description. Sources/ForelCore holds the rule engine, watcher, SQLite persistence and models, while Sources/ForelApp holds the SwiftUI app, menu bar, settings, editor and views. Tests live in Tests/ForelCoreTests. The technology table lists SwiftUI plus AppKit for the shell, Swift 6 for the backend, a "Native FSEvents wrapper" for watching, and SQLite behind a "Custom Swift database wrapper" that the README says gives direct control over transactions, migrations and rule round-trips. The roadmap marks action history and undo, activity logs, and automatic database cleaning as done, which suggests the history table is expected to grow and be pruned.

Installing Forel with Homebrew and running a first rule

The README gives two install paths. Homebrew is the short one, and it uses the project's own tap:

brew install --cask lab421/tap/forel

The equivalent two-step form taps first and then installs the cask by name:

brew tap lab421/tap
brew install --cask forel

After either command the app is installed as a cask. The README also offers a manual route: download the latest release .dmg from the Releases page, open it, and drag Forel to the Applications folder. macOS 13 Ventura or later is required. If you prefer to build, the prerequisites are Swift 6 and macOS 13 or later:

git clone https://github.com/lab421/forel.git
cd forel
swift build
swift test
swift run

For a first real use, follow the Quick Start. Launch Forel and the icon appears in the menu bar. Click it to see active rules, or open the main window. Click New Rule and choose a folder to watch. Define conditions by name, extension, kind, size, date, tags or color label. Set an action such as move, rename, tag, copy or run a script. Enable the rule. The README states that Forel keeps working "even when the window is closed." Before enabling anything destructive, use Dry Run / Preview, which the README describes as a manual whole-folder pass. The Content matching section adds that when a file's text cannot be read, the Dry Run tells you why.

Where the on-device design and the rule model get in the way

The Contents condition is the most interesting and the most fragile part of the engine. It reads text inside files, entirely locally, and the README says OCR runs on-device. That is a real capability, but it also means matching depends on whether a given file's text can be extracted at all. The README acknowledges this: when text cannot be read, Dry Run reports the reason. A rule that silently matches nothing because a PDF is image-only is a plausible failure mode, and the only mitigation the documentation offers is to run the preview first.

The roadmap is the second limitation. Export / Import rules is unchecked, and so are Compress, Sync and Upload actions. If you maintain the same automation on a laptop and a desktop, the README does not describe a supported way to move rules between them; the SQLite database is bundled and local. Sync and upload actions are also absent, which is consistent with the privacy stance but rules out workflows that end with a file leaving the machine. AI features are listed unchecked as well.

Updating is a third constraint. The README's technology table says updates use a "GitHub Releases check" and that "ad-hoc signed builds are updated by manual reinstall, not in-place patching." So an update notification does not mean the app patches itself. You reinstall. Anyone expecting a silent background upgrade should plan for that step. None of these are bugs in the code; they are boundaries of the current design, and they are the reason to read the roadmap before committing to Forel as the only automation layer on a machine.

Hazel and the difference in approach

The README positions Forel directly against Hazel, calling it "The Hazel alternative for macOS." The meaningful difference is not the feature list, which overlaps heavily at the level of conditions and actions, but the distribution and data model. Forel is GPLv3, its source is on GitHub, and the README states there is no account and no telemetry, with all processing on the Mac. Hazel is the commercial, closed-source option that has been the default answer for this kind of automation on macOS for years.

If your reason for looking at Forel is licence or auditability, the comparison ends there: you can read Forel's rule engine in Sources/ForelCore, and you cannot read Hazel's. If your reason is capability, the two are closer than the framing suggests, and Forel's unchecked roadmap items (export/import, sync, upload, compress) are exactly the areas where a long-established commercial product tends to have more surface. The honest read is that Forel is the choice for people who want local-only processing and source access, and Hazel remains the choice for people who want the mature feature set and are willing to pay for it. Forel does not argue otherwise.

Licence, maintenance and the cost of upgrades

Forel is licensed GPL-3.0, and the README lists "Open source (GPLv3)" as a highlight. For end users running the Homebrew cask or the .dmg, the practical effect is that the source must remain available and that redistributed modified versions carry the same licence. If you plan to bundle Forel inside a product you ship, or to modify and redistribute it, the GPL-3.0 terms apply and you should read the LICENSE file and TRADEMARKS.md in the repository rather than rely on a summary. This is a description of the licence, not legal advice.

On maintenance: the repository is not archived, and the last push was on 2026-09-02. The most recent tagged release is v1.0.8 from 2026-07-24, with v1.0.7 on the same day and v1.0.6 on 2026-07-15. The README says the project "is built and maintained on my personal time," which is worth taking literally when you judge how quickly an issue will be answered. Upgrade cost is the manual reinstall described above, plus the database migrations the README attributes to the custom persistence wrapper. The CHANGELOG.md and TODO.md files at the repository root are the places to check what changed between v1.0.6 and v1.0.8.

Editorial conclusion

Adopt Forel if you want folder automation that stays on the Mac, you are comfortable with a GPLv3 app, and your rules are file-metadata based. Do not adopt it if you need to sync rules across machines or if your workflow depends on cloud OCR or remote uploads: export/import, compress, sync and upload actions are still unchecked on the roadmap, and the README documents ad-hoc signed builds updated by manual reinstall rather than in-place patching. Before committing, verify the Contents condition against your own file types with Dry Run, and confirm that your macOS version is 13 or later.

Frequently asked questions

Official sources

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