Why Ferdium eats memory, and what to do

Activity Monitor sorted by memory usually tells the same story on a Mac running Ferdium. One process named Ferdium sits near the top, and underneath it a column of Ferdium Helper entries, each holding a share of the total. The number at the bottom of that column is larger than the app feels like it should cost, and it grows every time another service goes into the sidebar.

Nothing is broken. The number is the direct consequence of what the app is doing, and it is largely predictable from a count of services. What follows covers where the memory actually goes, how to read the figures without drawing the wrong conclusion, which settings genuinely reclaim memory, and where the ceiling sits regardless of settings.

Where the memory actually goes

Ferdium is an Electron application. Electron bundles a Chromium browser engine and a Node runtime into one app, which is why the category exists at all. Building a tool that hosts Gmail, Slack, Notion, and a dozen internal dashboards means embedding something capable of running them, and that something is a browser.

Each service in the sidebar is a live web page held inside that engine, in its own isolated container so sessions do not leak between entries. Chromium runs those containers as separate processes, which is what the Helper entries in Activity Monitor are. The isolation that makes two Gmail accounts possible is the same isolation that produces the process list.

That produces two layers of cost stacked on each other.

The first layer is fixed per service. Every isolated container carries its own share of engine overhead before a single pixel of the actual web app is drawn. Ten services means ten copies of that overhead, no matter how light the pages themselves are.

The second layer is the web apps, and this is usually the larger of the two. Modern workplace web apps are substantial applications. A chat client holds message history, search indexes, and an open connection. A document tool holds a rendering tree for every page opened during the session. These are the same costs those apps impose in a normal browser tab, and they do not shrink because the tab now lives in a sidebar.

The app is not adding memory on top of a browser, it is holding open what would otherwise be tabs. A useful mental check is to compare against the browser it replaced. Fifteen services in the sidebar cost roughly what fifteen permanently open tabs of the same sites cost, plus the per container overhead, minus whatever tabs used to get closed by accident.

There is a third contributor that is easy to overlook. A browser closes tabs. A sidebar does not. Tabs get culled by accident throughout a normal day, either deliberately or because a window was closed, while a service added to a sidebar stays there until somebody removes it on purpose. Over a few months that difference alone accounts for a noticeable share of the total, and it is the part that responds to a two minute cleanup rather than to a setting.

Custom services added by URL behave the same way as the ones with built in recipes, because a recipe changes how icons and notification hooks are handled rather than how the page is loaded. An internal dashboard pasted in as a custom entry costs whatever that dashboard costs in a browser tab.

Reading Activity Monitor without being misled

Two habits produce wrong conclusions here, and both are common.

The first is reading the top line of the process list and treating it as the app total. The main Ferdium process is the shell. The services are in the Helper processes, which are listed separately and sorted apart from it. The real figure is the sum of the family, and macOS shows this correctly if the process list is expanded to view child processes rather than read line by line.

The second is treating memory used as a problem in itself. macOS is designed to fill memory, because unused memory does no work. The number that indicates trouble is the memory pressure graph, and specifically whether it stays green under normal load. Green with high usage is a machine doing its job. Yellow or red, with swap used climbing during ordinary work, is a machine short of memory.

Signs the number matters

Trouble looks like this. Switching to a service that has been idle for an hour shows a blank pane while it reloads. The whole machine stutters when a build or a video call starts. Swap used grows through the day and does not come back down. Fans run during work that involves no computation.

Signs it does not

A large total with green memory pressure, instant switching, and no swap growth is not a problem to solve. Reclaiming memory from an app that has it available costs reload delays and delivers nothing back.

It is also worth checking which service is responsible before changing anything global. Activity Monitor does not label helper processes by service name, but sorting the family by memory and then quitting one service at a time in the app identifies the heavy entry quickly. In most sidebars a single service accounts for a disproportionate share, and the answer is a setting inside that web app rather than a setting in the wrapper around it. Turning off animations, reducing how much history a chat client preloads, or signing out of a workspace that is no longer active often does more than any hibernation timer.

Hibernation, the setting that does the work

Hibernation is the single largest lever in this app. It unloads services that have been idle past a configurable timeout, releasing what those containers held. Waking a service reloads it, which is why the setting is a trade rather than a free win.

The default behaviour and the per service overrides are both worth setting deliberately.

Services that must never hibernate are the ones where a delayed notification causes a real problem. Chat where someone is waiting counts. A support queue counts. On call tooling counts. These belong on the exclusion list even though they are usually the heaviest entries in the sidebar, because a notification that arrives when the service wakes up is not a notification.

Everything else is a candidate. Dashboards checked twice a day, issue trackers, wikis, admin panels, and any service kept in the list purely so its URL is not lost. Unloading those costs a two second reload at the moment of use and returns memory for the rest of the day.

The timeout deserves a thought rather than a default. A short timeout reclaims more and reloads more often, which shows up as waiting. A long timeout reclaims less and almost never interrupts. Anyone whose memory pressure is green does not need a short timeout at all.

Workspaces change what stays loaded

Workspaces group services and hide the rest of the sidebar, and there is a setting governing whether services outside the active workspace stay in memory. This is the second lever, and it interacts with the first.

With everything kept loaded, workspaces are purely visual. The sidebar gets shorter, the memory total does not move, and switching between workspaces is instant. With that behaviour turned off, leaving a workspace releases what its services held, and returning to it pays a reload for each one.

The choice follows the shape of the work. Someone who moves between three clients several times an hour wants everything loaded, because the reload cost is paid repeatedly. Someone who spends a whole morning in one context and a whole afternoon in another pays the reload twice a day and gets the memory back in between.

A workspace built for a project that ended is worth deleting rather than leaving in the list. Dormant workspaces are the most common source of services nobody has thought about in months, and those are exactly the ones holding memory for no return.

What each lever actually costs

Lever	What it reclaims	What it costs	Worth doing when
Hibernation on idle services	The largest single amount	Reload delay on wake, late notifications	Memory pressure is yellow or red
Excluding chat from hibernation	Nothing, it spends memory	Keeps the heaviest services loaded	Notification timing matters
Unloading inactive workspaces	Proportional to services hidden	Reload when switching back	Contexts change a few times a day
Removing unused services	Permanent, no trade	Losing the bookmark	A service has not been opened in a month
Using the Apple Silicon build	Avoids translation overhead	Nothing	The Mac is an M series machine
Restarting the app	Temporary, from accumulated state	Reloading everything at once	Uptime is measured in weeks

The row worth acting on first is the one with no trade attached. Sidebars accumulate. A list of twenty services usually contains four or five that were added for a specific week and never removed. Deleting those costs nothing and does not come back.

The Apple Silicon row matters more than it looks. An Intel build running under translation on an M series Mac carries overhead in every process, and in an app with a dozen processes that adds up. Checking which build is installed takes a moment and is worth doing before changing any setting.

Restarting is the weakest of the levers and the one most often recommended. Long running browser engines accumulate state, so a restart does reclaim something, but it returns to the same level within a day. A restart that fixes the problem for a week was fixing something else.

Where the ceiling sits

Settings can move the number substantially. What they cannot move is the shape of the arrangement, and that shape sets a floor.

Every service still lives in one window behind one icon. That is the design, and it is why the app is a single line in Activity Monitor's application list. It also means the whole set shares a fate. A crash takes everything down together, and one misbehaving web app can make the entire window feel slow while the other services are fine.

It also means the memory question and the attention question are two different questions with one answer between them. Reclaiming memory by unloading services makes the machine faster and makes reaching those services slower. There is no setting that gives both.

The alternative arrangement is to give each app a persistent window with its own session, so a project is a layout rather than a list to scan, and switching goes to a specific app rather than to the container holding all of them. That does not make web apps lighter. It changes which costs are paid at the moment of switching. The Workspaces page covers how a set of apps is grouped and moved between together, and Compared with Ferdium sets out where the two arrangements differ on sessions, windows, and platform support.

What to change first

Open Activity Monitor and check the memory pressure graph before changing any setting, because a green graph means there is nothing to reclaim. If it is yellow or red, delete the services nobody has opened in a month, turn hibernation on with a generous timeout, and put chat on the exclusion list. If the number is fine and the friction is finding the right service rather than the machine slowing down, that is a different problem, and SpaceDeck approaches it by giving each app its own window instead of a row in a list.