Exploring Syncthing on Fedora Silverblue: rpm-ostree, Distrobox (Arch), or Podman with systemd?

Hello,

I have experience with Linux and have been using Fedora Silverblue for a while, but I’m still wrapping my head around the new ways of doing things—specifically, the use of podman, rpm-ostree, and containers in general. I’m currently considering how to best set up Syncthing on Silverblue, and I’m wondering what the community thinks about the best approach.

I’m not necessarily looking for a direct “pick this” answer, but more for an explanation of the advantages and disadvantages of the following options:

  1. rpm-ostree – I’m curious about the potential limitations or concerns of using it in this case, especially in terms of Silverblue’s immutability and update/rollback workflows.

  2. Distrobox (Arch) – What are the benefits and potential drawbacks of using Distrobox? How does it compare to the native Silverblue environment?

  3. Podman with systemd – How this compares to the other options in terms of performance, security, and maintainability.

I’m looking for some clarification on the trade-offs between these methods, as well as any pointers to relevant discussions or posts on this topic.

Thanks in advance for your time and insights!

I’m on Silverblue, and Syncthing is actually one of the rather few packages I have layered on top of the OSTree image. I see no drawbacks of using rpm-ostree to install such packages. Update performance shouldn’t be affected by this one package layered, and there are no issues with rollbacks, and neither with upgrades to newer Fedora versions.

If I were using Kinoite instead of Silverblue, I would probably use one of the available Syncthing community provided Flatpaks, such as Syncthingy.

You missed one option: Creating a sysext for it: syncthing & syncthing-tools: Add initial sysexts by travier · Pull Request #235 · fedora-sysexts/fedora · GitHub

Edit: I’ve merged that, it should be ready for testing.

More seriously, here is my breakdown:

  1. rpm-ostree: Will be updated alongside the rest of the system but will make updates slower to install and you may have package conflicts (also unlikely with syncthing). This is also not supported with bootc yet.
  2. Distrobox/toolbox: Should work fine but you need to setup the service unit to run it automatically and remember to update the container. It will only have access to user files.
  3. podman: Similar to toolbox but less heavy if there is already a container made by the project. Easy to keep updated.
  4. sysext: Still “unofficial” for now. Quick to enable/disable and update.

I used the Syncthingy Flatpak for about six months, and it ran like a champ. It’s the easiest way to do Syncthing on an atomic/immutable system.

Syncthings also work great in a container ! Here is how I have been running it, rootless, for years now :

cat ~/.config/containers/systemd/syncthing.container
[Unit]
Description=Podman container-syncthing.service
Documentation=man:podman-generate-systemd(1)
Wants=network-online.target
After=network-online.target

[Container]
Image=docker.io/syncthing/syncthing:latest
Environment=STGUIADDRESS=127.0.0.1:8384 
Volume=%h/Sync/:/home/user/Sync:Z
Volume=%h/keepass/:/home/user/keepass:Z
Volume=%h/.config/syncthing/:/var/syncthing/config:Z
ContainerName=syncthing 
Network=host 
HostName=syncthing
AutoUpdate=registry
UserNS=keep-id
HealthCmd=curl -fkLsS -m 2 127.0.0.1:8384/rest/noauth/health | grep -o --color=never OK || exit 1
HealthInterval=2m 
HealthTimeout=10s

[Service]
Restart=always

[Install]
WantedBy=default.target