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
moonpiedumplings@programming.dev 2 weeks ago
I don’t know what the commenter you replied to is talking about, but systemd has it’s own firewalling and sandboxing capabilities. They probably mean that they don’t use docker for deployment of services at all.
Here is a blogpost about systemd’s firewall capabilities: ctrl.blog/…/systemd-application-firewall.html
Here is a blogpost about systemd’s sandboxing: www.redhat.com/en/blog/mastering-systemd