Ferdium on a Mac, set up from scratch

Most tools that gather web apps into one window ask for an account before showing anything, then put the useful half behind a plan. Ferdium does neither. It is Apache 2.0 licensed, funded by donations, and every feature it has is available on the first launch with no sign in. That combination is rare enough that people searching for it on a Mac are usually checking whether the catch is hiding somewhere.

There is no catch in the pricing. There are real limits in what the design can do, and they are worth understanding before moving a working setup into it. What follows covers the install on macOS, the parts of the setup that decide whether it holds up, and the specific situations where it stops being the right answer.

What Ferdium actually is

Ferdium is a hard fork of Franz, by way of Ferdi. Franz was the original commercial version of this idea, with a free tier that gradually narrowed. Ferdi forked it to unlock what had moved behind the paywall. Ferdium forked Ferdi again after that project stalled, and is now maintained by a community rather than a company.

That history explains the shape of the app. Every feature that Franz charged for, including workspaces and multiple accounts of the same service, is simply on. There is no plan page because there are no plans. Development runs through GitHub, releases are published there, and the project takes donations rather than subscriptions.

Two consequences follow. The good one is that nothing will move behind a paywall later, because there is no commercial entity with a reason to move it. The less good one is that the roadmap follows contributor interest, so a specific fix arrives when somebody wants it enough to write it, not when a support ticket escalates.

The account is optional, not required. An account exists for syncing the service list between machines, using either the project's server or a self hosted one, and the app is fully usable without ever creating one.

Installing it on macOS

Builds come from the project's download page, which points at GitHub releases. Take the Apple Silicon build on an M series Mac rather than the Intel one, since the wrong architecture runs through translation and costs memory in an app that is already an Electron app.

If macOS declines to open the download on the first attempt, the standard route is System Settings, Privacy and Security, then the button offering to open it anyway. This is normal handling for anything obtained outside the App Store and says nothing about the app itself.

Three things are worth doing in the first ten minutes.

Grant notifications once, at the system level

Ferdium relays every service's alerts through one macOS notification stream. If the system permission is off, every service goes silent at the same moment and the app looks broken. Approve it in System Settings, Notifications, then decide service by service inside the app.

Understand hibernation before turning it up

Idle services can be unloaded to save memory, which is the single largest lever available in an Electron app hosting a dozen web pages. The cost is that an unloaded service is disconnected, so its notifications arrive on wake rather than on time. Chat belongs on the exclusion list. Dashboards and issue trackers rarely do.

Add services by URL when the recipe is missing

Ferdium ships recipes for common services, which are small definitions that handle icons and notification hooks. Anything without a recipe can still be added as a custom service by pasting its URL. Internal dashboards and self hosted tools all work this way, which is the reason the app tends to fit engineering setups better than the recipe list alone suggests.

Sessions, workspaces, and what is actually separated

The reason to use this category of tool at all is session isolation, so it is worth being precise about what Ferdium isolates.

Each service in the sidebar keeps its own session. Adding Gmail twice produces two entries that can be signed into two different Google accounts at the same time, with no plan to buy and no browser profile to create. The same applies to two Slack workspaces on different email addresses, two Notion accounts, or three of anything. This is the feature people arrive for, and it is free here.

Workspaces are named groups of services. A workspace called Client A can show five services and hide the rest, which turns a sidebar of twenty entries into a sidebar of five for as long as that work lasts. Switching workspaces does not sign anything out, it changes what is visible.

Custom CSS is supported through a custom.css file in the Ferdium configuration directory, which on macOS lives under ~/Library/Application Support/Ferdium. Per service styling is also possible, which is how people hide a sidebar inside a web app that duplicates the one Ferdium already provides. This is a text file and a restart, not a settings panel, which fits some people and not others.

What is not separated is the window. Everything lives in one window with one sidebar, by design.

Moving an existing setup in without losing a day

The failure mode when adopting any tool like this is doing it all at once on a Monday, hitting one service that behaves oddly, and abandoning the whole thing by Wednesday. A staged move avoids that, and it takes about a week of low effort.

Start with the services that are open all day and have exactly one account each. Those are the least likely to surprise anyone and they immediately remove the most tabs. Leave the browser open alongside during this phase. Nothing is being deleted, and running both for a few days is how the gaps get found.

Add duplicate accounts second, one pair at a time. This is where the app earns its place, and it is also where a wrong assumption is most expensive, since a service that handles multiple sessions badly is better discovered against a second Gmail than against a client account in the middle of a deadline.

Add internal tools and self hosted dashboards last, as custom services by URL. These have no recipe, which means no icon and weaker notification handling, so decide per tool whether it is worth a sidebar slot at all. A dashboard checked twice a week is usually better as a bookmark.

Only then create workspaces. Building them on day one is a common mistake, because the groups people imagine before the move rarely match the groups they need after it. A week of actual use makes the right grouping obvious, and it is normally two or three workspaces rather than one per project.

Finally, leave the todo panel and the styling alone until everything else is settled. Both are useful, both are configuration, and configuration added before the shape is stable tends to be configuration done twice.

Where Ferdium stops helping

Four limits show up in daily use, and none of them are defects.

The first is switching. Twenty services in a sidebar is denser than forty tabs, and the act of switching is identical: scan a list, click the right icon. Command Tab reaches the app, never the service. For anyone crossing between services dozens of times a day, this is the bottleneck that remains after everything else is fixed.

The second is link routing. A link arriving in Mail or Calendar opens in the macOS default browser, under whichever account is signed in there. macOS holds exactly one default browser and has no way to say that a particular link belongs to a particular signed in session. Every tool in this category inherits this, so the copy, switch, paste cycle survives the move.

The third is polish variance. Recipes are community maintained, so a service whose web app changed can behave oddly until somebody updates its recipe. Custom services added by URL avoid this by having no recipe to break, at the cost of weaker notification handling.

The fourth is the absence of a support channel. Issues go to GitHub. For a personal setup that is fine. For a machine that a business depends on, the honest question is who fixes it on a bad Tuesday.

How it compares on the things that cost money elsewhere

Prices below come from each vendor's own pricing page and were correct in September 2026. The full side by side treatment is kept on Compared with Ferdium, and the equivalent for the closest paid product is on Compared with Rambox.

Capability	Ferdium	Rambox Basic	Rambox Pro
Price	Free, Apache 2.0	Free	$7 per month, $70 per year
Account required to start	No	Yes	Yes
Two logins of one service	Yes	No	Yes
Workspaces	Yes	No	Yes
Own CSS	Yes, via a config file	No	Yes
Support	Community, on GitHub	Vendor	Vendor, priority

The column that matters is the second row of the table read against the third. Two things that cost seventy dollars a year in the nearest paid product are free here, which is the entire argument for Ferdium and a strong one. The things it does not offer are not on the table at all, because they are not features anyone sells in this category: a way to reach a service without scanning a list, and a way to route an incoming link to the right session.

Who it fits, and who it does not

It fits someone with several accounts of the same service, comfort with a text file for configuration, and a preference for software that cannot change its terms later. It fits people who were on Franz or Ferdi and want the same shape without a plan page. It fits anyone whose objection to the paid products is philosophical rather than budgetary, since the cost difference is a few dollars a month and the licence difference is permanent.

It fits less well where the pain is speed rather than separation. A person crossing between six services all day, in a fixed rhythm, is not slowed by logins. They are slowed by the half second of finding the icon, repeated until the day is over. A sidebar cannot fix that, whether it is free or paid, because the sidebar is the thing being scanned.

It also fits less well in a team that needs someone accountable for the tool. Not because community software is unreliable, but because the escalation path is a public issue tracker, and that has to be an acceptable answer in advance.

What to change first

Install it, add every service including duplicate accounts, and use it for a week without adding a single workspace. If the friction that remains is logins, this is the end of the search and it costs nothing. If what remains is the scan down the sidebar and links opening in the wrong place, that is a different problem, and a per app layout such as SpaceDeck is the shape worth comparing next, alongside the features that address routing rather than isolation.