The SystemD CI/CD Pattern: Beyond Multimedia

I built a multimedia site, but the real story is the deployment pattern that runs it. Systemd, git, and a sprinkle of shell form a tiny deployment DSL that scales surprisingly well.

Building a Deployment DSL

Level 0: systemctl, journalctl, git, rsync
Level 1: deploy-*.service wrappers
Level 2: aliases like da, st, logs
Level 3: health-check, rollback, and friends

da is the manual override that triggers all deployments when patience runs out.

Why SystemD

It already handles processes, logging, dependencies, and scheduling. Containers solve similar problems with more ceremony.

SystemD's Vanilla JS Moment

We thought we needed Docker for everything; turns out plain systemd works fine once it grew up. It's the jQuery-to-vanilla moment for deployments.

Timers vs Cron

[Timer]
OnCalendar=hourly
Persistent=true

Timers show up in logs, respect dependencies, and catch up after reboots. Cron is fine; timers are nicer.

Webhooks Eventually

Right now timers poll every hour. The dream is a webhook trigger, but pressing da manually still wins for impatience.

Scaling the Pattern

Simplicity Over Complexity

Modern CI/CD often feels like reading a novel in YAML. This pattern keeps things small, understandable, and debuggable from a phone at 2 AM.

AI-Friendly

Because everything is text and command-line driven, an LLM can actually help debug it. Can't say that for most vendor dashboards.

Our Example Stack

Getting Started

  1. Write a deploy script.
  2. Wrap it in a systemd service.
  3. Add a timer if you like automation.
  4. Configure logging and handy aliases.

The Point

You don't need massive platforms for small projects. The pattern is universal, the implementation is specific, and the only YAML involved is the one you didn't write.

"The best CI/CD system uses tools you already understand and runs on hardware you own. Bonus points if it fits in a terminal window."