Systemd has all sorts of options. If a service has certain sandbox settings applied such as private /tmp, private /proc, restricting access to certain folders or devices, restricting available system calls or whatever, then systemd creates a chroot in /proc/PID for that process with all your settings applied and the process runs inside that chroot.
I’ve found it a little easier than managing a full blown container or VM, at least for the things I host for myself.
If a piece of software provides its own service file that isn’t as restricted as you’d like, you can use systemctl edit to add additional options of your choosing to a “drop-in” file that gets loaded and applied at runtime so you don’t have to worry about a package update overwriting any changes you make.
And you can even get ideas for settings to apply to a service to increase security with:
systemd-analyze security SERVICENAME




Is the code good? Are you prepared to make any potential fork viable and useful in ways that Lemmy isn’t so people have a tangible, non-ideological reason to choose your software over Lemmy? Do you have a long term goal for funding and maintaining a fork?
That said, Piefed is already a thing, and it federates with Lemmy. It’s where I’m commenting from right now. It has a better on boarding process and does a better job surfacing things I care about.