What you’ll accomplish: Understand what Rundeck does for your home lab, why the official docs leave you stranded, and exactly what you’ll have when you finish this guide.
The Problem With a Pile of Playbooks
If you’ve been running a home lab for any length of time, you’ve accumulated things. Ansible playbooks for spinning up VMs. Shell scripts for backups. A cron job that updates packages on Tuesdays. Maybe a wiki page that documents which commands to run when the NAS misbehaves.
It works — until it doesn’t. Someone (you, six months from now) needs to restart a service across three hosts and can’t remember which playbook does it, what flags it needs, or whether it’s safe to run against production. There’s no execution history, no audit trail, and no way to let a less-technical household member trigger a routine task without SSH access and a prayer.
Rundeck solves this. It’s an open-source runbook automation platform that wraps your existing Ansible playbooks, scripts, and commands in a web UI. You define jobs — with parameters, schedules, access controls, and logging — and execute them from a browser. Every run is recorded: who triggered it, what happened, whether it succeeded. Your pile of automation becomes a self-service operations platform.
Why the Official Docs Aren’t Enough
The Rundeck documentation will get you to “installed.” It won’t get you to “production-ready on Rocky Linux with a real database, a reverse proxy, SELinux enforcing, and Ansible integration.” Here’s what’s missing:
The H2 database trap. Rundeck’s default installation uses H2, an embedded Java database. The docs don’t warn you loudly enough: H2 corrupts on unclean shutdown. Power outage, OOM kill, even a systemctl stop during heavy writes — your job history, project configuration, and metadata are gone. This isn’t theoretical. GitHub issues #6003, #7764, #3044, and #3868 are full of users who learned this the hard way. The fix is to use a real database like MariaDB from the start, but the official docs treat that as an “advanced” configuration instead of a prerequisite.
Rocky Linux gaps. The docs lean toward Ubuntu and generic RHEL. If you’re running Rocky Linux 9 — the natural choice for a home lab hypervisor environment — you’ll hit SELinux issues, firewall specifics, and package naming differences that the docs don’t cover. The single most common deployment failure on Rocky is an SELinux boolean that the docs never mention.
No Ansible integration walkthrough. Rundeck has an Ansible plugin. The docs tell you it exists. They don’t walk you through installing Ansible on the Rundeck host, configuring the plugin, importing your inventory as Rundeck nodes, setting up SSH keys for the rundeck service user, and running your first playbook through the web UI. That’s the entire point of using Rundeck in a home lab, and you’re left to piece it together from scattered GitHub READMEs.
No end-to-end automation. The docs are manual steps. This guide gives you Ansible playbooks that deploy the whole stack. You can rebuild your Rundeck server from scratch in minutes, not hours.
What You’ll Have at the End
By the time you finish this guide, you’ll have:
- A Rundeck instance on Rocky Linux 9, installed from the official RPM repository
- MariaDB as the persistent backend — no H2, no corruption risk
- An Apache reverse proxy with SSL termination on port 443
- Ansible installed and integrated — your existing inventory imported as Rundeck nodes, playbooks executable from the web UI
- SSH key-based authentication from Rundeck to your managed hosts
- Firewall and SELinux configured correctly — not disabled, not permissive, actually enforcing
- A set of Ansible playbooks that deploy and configure all of the above, so you can tear it down and rebuild it at will
Everything is deployed via Ansible. Everything is documented. Everything uses sanitized, vault-encrypted credentials.
Who This Guide Is For
You’re an intermediate sysadmin or home lab hobbyist. You’re comfortable with SSH, package managers, and editing config files. You’ve used Ansible at least a little — you know what a playbook is and have run ansible-playbook before. You don’t need hand-holding on Linux basics, but you do need someone to tell you “use MariaDB, not H2” and “set this SELinux boolean or you’ll waste two hours.”
This guide is not for enterprise teams that need high-availability clustering, SAML/OIDC single sign-on, or multi-region deployments. Those require Rundeck Enterprise (the paid version) and an architecture that’s overkill for a home lab. We’re building something that runs on a single VM with 4 GB of RAM and handles 10-20 managed nodes comfortably.
Prerequisites
Before you start Chapter 2, make sure you have:
- A Rocky Linux 9 host (VM or bare metal) with at least 4 GB RAM, 2 CPU cores, and 20 GB disk. A fresh minimal install is ideal.
- SSH access to that host with a user that has sudo privileges.
- Ansible installed on your workstation (the machine you’ll run the deployment playbooks from — not the Rundeck host itself).
- One or more managed nodes (Rocky Linux VMs, Raspberry Pis, anything with SSH) that you want Rundeck to manage. Even one node is enough to prove the setup works.
- A DNS record or IP address for your Rundeck server. If you have internal DNS, point
rundeck.example.comat the host. If not, the IP address works fine — just adjust the configuration accordingly. - An SSL certificate for the Rundeck hostname, or willingness to use a self-signed certificate for your home lab.
That’s it. Let’s look at the architecture.