Repository navigation
MARKET_POSITION
This document describes where Playbook Scheduler fits among tools that schedule, run, and report on Ansible playbooks. It is meant to help decide whether Playbook Scheduler is the right tool for a given environment, and to make clear what it deliberately does not do.
Statements about other products reflect their publicly documented state as of 2026 and may change; check the vendors' documentation before relying on them.
Playbook Scheduler is a single-process, file-based scheduler and reporter for
ansible-playbook. It sits between a plain cron job and a full automation
platform such as Ansible Automation Platform or AWX:
- Compared with cron plus
ansible-playbook, it adds configuration validation, overlap protection, timeouts, a clean shutdown, a structured record of every run, per-host results, and an HTML report. - Compared with AWX, Ansible Automation Platform, Semaphore UI, or Rundeck,
it has no web application, database, user management, credential store, or
API. In exchange, it installs with
pip, runs as one systemd service, and keeps all state in plain files that can be read, backed up, and audited without special tools.
The target user is an operations team or individual administrator who already maintains Ansible playbooks in Git, runs them from a Linux host, and wants reliable unattended scheduling with a run history — without operating a platform.
Ansible Tower was renamed automation controller and is part of the commercial, subscription-based Red Hat Ansible Automation Platform (AAP). AAP bundles the controller with a web UI and REST API, role-based access control, an encrypted credential store, inventories synchronised from cloud providers and CMDBs, workflows that chain job templates, surveys, notifications, execution environments (container images), distributed execution through automation mesh, Event-Driven Ansible, a private automation hub, and vendor support.
It requires PostgreSQL and is typically deployed on RHEL or OpenShift. Operating it is a project of its own: sizing, upgrades, backups, and licensing.
Relation to Playbook Scheduler: AAP is the choice for organisations that need self-service for many teams, delegated permissions, central credential management, audit requirements backed by support contracts, or large fleets. Playbook Scheduler covers only the "run this playbook on a schedule and show me what happened" part of that feature set, at a fraction of the operating effort.
AWX is the open-source upstream project of the automation controller. It offers largely the same functionality as AAP's controller — web UI, API, RBAC, credentials, workflows, schedules — without a subscription or vendor support.
It is deployed on Kubernetes with the AWX Operator and needs PostgreSQL. Upgrades between releases are not guaranteed to be smooth, and the project has been undergoing a larger restructuring with a reduced release cadence, which makes it a less predictable foundation for production than it once was.
Relation to Playbook Scheduler: AWX is attractive when a team wants AAP-like features without license costs and already runs Kubernetes. Where Kubernetes is not available or the team only needs scheduled runs and a history, AWX is a large dependency for a small requirement; Playbook Scheduler needs only Python and Ansible.
Semaphore UI is an open-source web interface for Ansible, written in Go, which also supports Terraform/OpenTofu, PowerShell, and shell scripts. It provides projects, task templates, schedules, inventories, key store, users and teams, and run logs. It runs as a single binary or container with BoltDB, MySQL, or PostgreSQL; a commercial edition adds further enterprise features.
Relation to Playbook Scheduler: Semaphore is the closest "lightweight UI" alternative. It is the better choice when several people need to start playbooks through a browser or manage credentials centrally. Playbook Scheduler is smaller still, is configured entirely in a version-controlled YAML file instead of through a UI, and captures per-host task counters through its own callback plugin.
Rundeck is a general-purpose runbook automation and job scheduler with an Ansible integration. The open-source Community edition and the commercial PagerDuty Process Automation offer a web UI, ACLs, job scheduling, node inventories, and self-service operations. It runs on the JVM and needs a database for production use.
Relation to Playbook Scheduler: Rundeck suits organisations that automate with many tools besides Ansible and want one runbook portal. It is not specialised in Ansible results; Playbook Scheduler is, but offers nothing beyond Ansible.
ARA records playbook runs through an Ansible callback plugin and makes them available through a web UI, a CLI, and a REST API, backed by SQLite, MySQL, or PostgreSQL. It does not schedule or start playbooks.
Relation to Playbook Scheduler: ARA and Playbook Scheduler overlap in reporting, not in
execution. ARA records far more detail (every task, every result, files,
variables); Playbook Scheduler records the run, its output, and per-host counters, and
needs no server to view the report. They can be combined: Playbook Scheduler schedules
the run, and ARA, enabled through extra_args or the Ansible configuration,
records it in depth.
Many teams run playbooks from CI pipelines, either on commit or on a schedule. These systems provide schedules, logs, secrets, and access control, and are often already in place.
Relation to Playbook Scheduler: CI is a good fit for change-driven deployments. For recurring operational jobs (patching, compliance checks, backups) it is less natural: CI runners are often ephemeral or shared, have no network access to production hosts, keep logs only for a limited time, and do not summarise Ansible results per host. Playbook Scheduler runs on a dedicated host close to the managed systems and keeps a long-term, Ansible-aware history.
The simplest approach is a crontab entry that calls ansible-playbook and
redirects output to a log file, or ansible-pull on each managed node.
Relation to Playbook Scheduler: This is what Playbook Scheduler replaces most directly.
Cron alone provides no overlap protection, no timeouts, no structured result,
no report, and no validation of paths and executables before the first run;
failures are easy to miss. Playbook Scheduler keeps cron's simplicity — a text file and
a long-running process — and adds these missing parts. ansible-pull follows a
different, decentralised model and has no central history at all.
- Foreman / Red Hat Satellite run Ansible roles as part of host lifecycle management. They make sense where Foreman or Satellite already manages the hosts.
- Infrastructure-as-code platforms such as Spacelift, env0, or Scalr support Ansible stacks next to Terraform. They target cloud provisioning workflows and are offered mainly as SaaS.
- Workflow orchestrators such as Kestra or Apache Airflow can call Ansible through plugins or operators. They are useful when Ansible is one step in a larger data or business process.
| Capability | Playbook Scheduler | AAP (Tower) | AWX | Semaphore UI | Rundeck | Cron + ansible-playbook |
|---|---|---|---|---|---|---|
| License | Open source | Commercial subscription | Open source | Open source, commercial edition | Open source, commercial edition | Open source |
| Vendor support | No | Yes | No | Commercial edition | Commercial edition | No |
| Runtime requirements | Python, Ansible | RHEL or OpenShift, PostgreSQL | Kubernetes, PostgreSQL | Binary or container, database | JVM, database | None |
| Configuration | YAML file in Git | UI / API | UI / API | UI / API | UI / API / job files | crontab |
| Cron schedules | Yes | Yes | Yes | Yes | Yes | Yes |
| Overlap protection | Yes, also across processes | Configurable | Configurable | Limited | Configurable | No |
| Timeout handling | Yes, graceful stop then kill | Yes | Yes | Limited | Yes | Manual (timeout) |
| Per-project Python venv | Yes (ansible_venv) |
Execution environments | Execution environments | Yes | Manual | Manual |
| Run history | JSON files | Database | Database | Database | Database | Log files |
| Per-host result counters | Yes | Yes | Yes | Partly | No | No |
| Report / UI | Static HTML report | Web UI | Web UI | Web UI | Web UI | None |
| Start runs from a browser | No | Yes | Yes | Yes | Yes | No |
| Users, teams, RBAC | No (OS permissions) | Yes | Yes | Yes | Yes | No (OS permissions) |
| Credential store | No (Ansible Vault, OS) | Yes | Yes | Yes | Yes | No |
| Workflows across playbooks | No | Yes | Yes | Limited | Yes | No |
| REST API | No | Yes | Yes | Yes | Yes | No |
| Dynamic inventory sync | Through Ansible plugins | Yes, managed | Yes, managed | Through Ansible plugins | Yes | Through Ansible plugins |
| Distributed execution | No, single host | Yes (automation mesh) | Yes | Runners | Yes | No |
| Logging to journald with severity | Yes | n/a | n/a | n/a | n/a | No |
| Operating effort | Very low | High | High | Low to medium | Medium | Very low |
"Limited" and "Partly" mean the feature exists in a reduced form or depends on the edition or configuration.
- Minimal footprint. One Python package, three dependencies (APScheduler, Jinja2, PyYAML), and one systemd service. No database, web server, container runtime, or Kubernetes.
-
Configuration as code. All jobs are defined in one YAML file that can be
reviewed, versioned, and deployed like the playbooks themselves;
validatechecks it, including theansible-playbookexecutable per job, before anything runs. Changes are picked up without a restart. - Transparent, durable records. Every run is one JSON file with timestamps, command, exit code, full output, and per-host counters. The records can be processed with standard tools, archived, or forwarded, and outlive Playbook Scheduler itself.
- Operationally safe execution. A job never runs twice at once, even across processes; timeouts and shutdowns let Ansible end its tasks before it is killed; interrupted and skipped runs are recorded rather than lost.
- Integration with the host. Logs go to journald with syslog priorities, so existing log monitoring and alerting can pick up failed runs.
- Separate Ansible environments. Each job can use its project's own virtual environment and collection versions.
These are deliberate scope decisions, not missing features to be added later:
- No web UI for starting runs or editing jobs, and no REST API.
- No user management or role-based access control; access is controlled by file and service-account permissions.
- No credential store; credentials come from Ansible Vault, SSH agents, or files readable by the service account.
- No workflows, approvals, or surveys.
- Runs on one host; no distribution of jobs across workers and no high availability.
- No built-in notifications; alerting relies on the journal or on Ansible itself.
- The HTML report is static and regenerated on change; it is not designed for
very large histories, which
retention_dayskeeps in check. - Run records and the report may contain sensitive output and must be protected through file permissions.
| Situation | Recommendation |
|---|---|
| A single team or administrator runs recurring playbooks from one Linux host and wants a reliable history | Playbook Scheduler |
Existing crontab entries call ansible-playbook and failures go unnoticed |
Playbook Scheduler |
| Several people need to start playbooks from a browser, with a shared credential store | Semaphore UI |
| Many teams, delegated permissions, audit requirements, vendor support | Ansible Automation Platform |
| AAP-like features without a subscription, and Kubernetes is already operated | AWX |
| Runbooks across many tools, not only Ansible, in one portal | Rundeck / PagerDuty Process Automation |
| Detailed analysis of every task result across runs | ARA, optionally together with Playbook Scheduler |
| Deployments triggered by commits or merge requests | CI/CD pipeline |
A typical path is to start with Playbook Scheduler when scheduled Ansible jobs need to become reliable, and to move to Semaphore, AWX, or AAP when self-service, RBAC, or central credential management become requirements. Because jobs are defined by playbook, inventory, and arguments, they translate directly into job templates in those platforms.
The project was originally called Ansible Runner. It was renamed to Playbook Scheduler because Red Hat publishes a different project named ansible-runner on PyPI: the Python library and CLI that AWX and AAP use internally to execute playbooks. Sharing its distribution, import package, and command names meant the two could not be installed in the same Python environment, and searches or documentation links led to the wrong project. The new name also describes what the tool does and avoids using the Ansible trademark as the first word of the product name.