profile-sync-daemon, a browser profile that lives in RAM

Why the profile belongs in tmpfs

The problem is one of storage behaviour rather than speed in the abstract. A browser profile is a directory of small files that the browser reads and rewrites constantly, and on a hard disk or a slower solid state drive that churn is where the waiting comes from, both at start up and during ordinary use. profile-sync-daemon, abbreviated psd, is described as a tiny pseudo-daemon that manages the browser profile in tmpfs and periodically syncs it back to the physical disc. The README names the two mechanisms it uses, a symlinking step and what it calls an innovative use of rsync to maintain backup and synchronization between the two locations. The design goal is stated as a completely transparent user experience, which is the hard part of the idea, because a user who has to think about where their profile lives will find ways to break it. The audience is a Linux desktop user, and the tooling around it, systemd user units, a zsh completion and per browser configuration files, all assume that.

Symlink one way, rsync the other

The mechanism is a two part arrangement, and each part does a different job. The symlink is what makes the browser see the fast location, since the profile path the browser opens becomes a link into tmpfs, and every read and write the browser performs lands in memory. The rsync side is the safety net, since the copy on the physical disk is refreshed on a schedule, and it is also the backup, because the disk copy survives a reboot that would otherwise empty the tmpfs. The repository layout shows how the pieces are packaged. The common/ directory holds the main script, the psd.conf configuration file, the per browser configuration files in common/browsers/, a suspend helper named psd-suspend-sync, and the zsh completion. The init/ directory holds the systemd user units, and the logcheck patterns in the README refer to a psd service, a psd-resync service and the timer that triggers the resync, so the resync is a separate scheduled unit rather than a loop inside the daemon.

Twenty browsers and two profile layouts

The supported browser list is long and the reason for that is that every browser stores its profile somewhere slightly different. Chromium and Google Chrome in its stable, beta and dev flavours are there, along with Vivaldi and its snapshot build, and the four Opera channels, stable, beta, developer and legacy. The Firefox family is covered in several shapes, including Icecat, Iceweasel, Palemoon, Midori, Luakit, Rekonq, Seamonkey, Surf, Qutebrowser, QupZilla, Otter browser, Epiphany, Conkeror, Inox and Aurora. Two details in the list are worth reading closely. For Firefox the entry says that version 147 and above use the freedesktop.org XDG base directory specification while others use the legacy ~/.mozilla location, so the tool has to handle both layouts. And the flatpak entry carries a one time command, flatpak override --user org.mozilla.firefox --filesystem=/run/user/$UID/psd, which grants the sandboxed browser access to the directory psd uses in the runtime directory, without which the sandbox simply cannot see the profile.

Packaged by most of the big distributions

Installing psd is a distribution matter rather than a build exercise, and the README lists the official packages. It is in the extra repository of Arch Linux, in the official repositories of Debian, in the official repositories of Exherbo and Gentoo, in the official repository of NixOS, and in the Ubuntu Universe repository. Slackware users have a user package on slackbuilds, and the author invites offers to package it for other distributions. Building from source is also documented, with an INSTALL text document included in the tree for that purpose. The wiki page linked from the README, on the Arch wiki, is where the fuller documentation lives, and the man page is the other reference. The distribution list is a real signal about the shape of the tool, because a package in six official repositories is a package with maintainers who expect it to keep working across upgrades, and that is a different promise from a script in a personal dotfiles repository.

Two warnings that decide whether you should use it

The README opens with advice rather than marketing, and both warnings are load bearing. The first is simple and absolute. Always back up your browser profile before using psd for the first time. That is not a formality, because the tool moves your live profile into a location that disappears on reboot, and the window between the last sync and an unclean shutdown is exactly the window in which unsaved browser state, sessions and passwords can be lost. The second warning is narrower and has a tracking issue. Users of eCryptFS are encouraged not to use psd unless they are willing to help troubleshoot suspected browser corruption, and the README links issue 158 for that discussion. The reason is structural rather than superstitious, since an encrypted home directory decrypts on mount and re-encrypts on unmount, and a symlink pointing into a tmpfs that is remounted underneath it can leave the browser writing to a path that no longer matches what the encryption layer expects. The two warnings together draw a clear line, and a user who reads them will know within a minute whether psd belongs on their machine.

What the install actually puts on the system

The Makefile is small and explicit, and it shows the shape of the tool. The version is set in one place, 7.04, and the main script is generated from a template, with common/profile-sync-daemon.in rewritten to common/profile-sync-daemon by substituting the version string. The install target then places the main script in the binary directory, installs psd-suspend-sync alongside it, and creates a symlink so that the shorter name psd resolves to the script. A zsh completion is installed as _psd, the configuration file psd.conf goes to the shared data directory, and the per browser configuration files are installed into a browsers/ subdirectory of the same place, with the contrib/ files next to them. The man page comes from doc/psd.1 and is installed with a matching symlink, and the systemd units, including psd.service and psd-resync.service, are installed into the systemd user directory rather than the system one, which is why the whole thing runs under the logged in user without root.

Log lines that survive logcheck

The last section of the README is for system administrators who run logcheck, and it publishes a set of regular expressions that filter the lines psd and its units produce. The patterns match a syslog timestamp, the process name and the pid, and then the message.

^\w{3} [ :0-9]{11} [._[:alnum:]-]+ profile-sync-daemon\[[0-9]+]: .*(google-chrome|firefox) (re|un)sync successful
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ profile-sync-daemon\[[0-9]+\]: psd startup check successful$

One catches the resync success lines for google-chrome and firefox, one matches the startup check success line, and the remaining three match systemd's own output, the timer being started, the CPU time consumed by the psd or psd-resync service, and the timer succeeding. The reason to publish these is that psd is chatty on a schedule, and an unmanaged log fills with lines that look like failures. Two more facts about the project's state are worth noting before you adopt it. The repository has no GitHub releases, so versions are tracked by the Makefile value and by the distribution packages, and the last push was on 2026-07-03, so the tree moves in step with the distributions rather than on its own release cadence. The tree carries both a LICENSE file and a file named MIT, while the project licence field is one that GitHub could not classify, so read the files before you redistribute anything.

Editorial conclusion

profile-sync-daemon fits a Linux desktop user on a spinning disk or a slow SSD who spends their day in one browser and wants the profile cached in memory instead of on the device, and it fits a user of one of the listed browsers who can accept a periodic sync and the risk of a crash between syncs. It does not fit a user whose home directory is encrypted with eCryptFS, since the project asks those users to stay away, and it does not fit a browser profile that must be consistent at every instant, because the copy on disk is only as fresh as the last sync. Verify three things first: that you have a working backup of the profile, since the project asks for one before the first run, that the browser you use is in the supported list and that its profile path is the one the tool expects, and where the sync interval is configured, because the window of loss is the interval.

Frequently asked questions

Official sources

1. graysky2/profile-sync-daemon on GitHub
2. Issues
3. Project website
4. README