Before starting this Raspberry Pi project, I had never worked with systemd directly. The closest thing I could mentally compare it to was a cron job. They solve very different problems, but both automate work without requiring someone to manually execute commands. Once I started reading about systemd, I realized it is responsible for far more than scheduling. It is effectively the service manager for much of a Linux system.
One thing I found particularly interesting is that services can define dependencies on one another. Instead of writing a shell script that starts everything in a specific order, you describe those relationships in the service files and let systemd determine when each service should start. For example, my frontend waits for the backend service before launching, ensuring it isn't trying to communicate with an API that hasn't started yet.
I also came away with a much greater appreciation for how powerful service files are. They control which user executes a program, what environment variables are available, where the program runs from, whether it should automatically restart after a failure, and what other services it depends on before launching. It is easy to see why systemd is such an important part of Linux.
That power also means service files should be treated carefully. Since they can be configured to automatically start programs during boot, a malicious or incorrectly configured service could continue running every time the machine starts. Simply rebooting the computer would not necessarily stop it if the service is configured to restart automatically. While Linux permissions help protect against unauthorized changes, it reinforced for me why configuration under /etc should always be treated with care.
My Current Setup
At the moment my homelab only has two service files:
homelab-dashboard-api.servicehomelab-dashboard-web.service
The API service launches my FastAPI backend using Uvicorn, while the web service starts the production Next.js application using npm run start.
Both service files live under:
/etc/systemd/system
and are enabled so they automatically start whenever the Raspberry Pi boots. This became especially useful once I added a reboot button to the dashboard. Pressing reboot restarts the Pi, and once it finishes booting both services automatically come back online without requiring me to SSH into the machine and manually start anything.
One thing I also learned from reviewing the service files was how the startup order is defined.
The backend waits until networking is available before starting. The frontend then explicitly waits for the backend service. This creates a simple startup sequence:
Network
↓
FastAPI Backend
↓
Next.js Frontend
Rather than relying on timing or startup scripts, systemd handles those dependencies automatically.
Useful Commands
The commands I expect to use most often are:
sudo systemctl status <service>
Shows whether a service is loaded, active, and displays recent log output.
sudo systemctl start <service>
Starts a service.
sudo systemctl stop <service>
Stops a service.
sudo systemctl restart <service>
Restarts a running service.
I also found it interesting that these commands can behave differently depending on how the service file is written. A service can define what happens during startup, shutdown, or restart, making systemd much more flexible than simply running a shell command.
Viewing Logs
Another useful command is:
journalctl -u <service-name>
This displays logs for a specific service. My homelab is still relatively small, so there isn't much output yet, but I can already see how valuable this will become as more services are added. Instead of searching through large system logs, I can inspect exactly what a single service has been doing.
Final Thoughts
Overall, I learned a lot about systemd. I definitely wouldn't be able to write a complex service file completely from scratch yet, but I now understand what each section is responsible for and how the different pieces fit together.
More importantly, I feel like I now have a solid baseline. When I start working with other software like Nginx, Grafana, or any future service that relies on systemd, I won't just be copying configuration from documentation, I should be able to understand what those service files are doing and why they're configured that way.
I also feel much more confident creating my own service files for future projects. Being able to have an application automatically start on boot, recover from failures, and run independently of an active SSH session is something I can already see myself using over and over again as this homelab continues to grow.
Reference
This YouTube playlist was by far the most helpful resource I found while learning about systemd:
https://www.youtube.com/playlist?list=PLtK75qxsQaMKPbuVpGuqUQYRiTwTAmqeI
The videos start with the fundamentals and gradually build up, making them a great introduction if you've never worked with systemd before.