Puppet Bolt: When You Need Automation Before Full Configuration Management
General Overview
Puppet Bolt is a task runner. It doesn’t care about agents, catalogs, or reports. It connects to machines over SSH or WinRM, executes a command or a script, and exits. No daemon, no persistent setup. If the environment is too early-stage or not under Puppet control yet — Bolt works there.
It was created as a stopgap. But in practice, it handles many of the use cases where admins just need something to happen, right now, across several systems — without deploying anything permanent.
Capabilities
| Functionality | Detail |
| No Agent Required | Uses SSH/WinRM directly; nothing to install on targets |
| Ad-hoc Task Execution | Shell scripts, PowerShell, inline commands — any of them supported |
| Multi-host Support | Can run against dozens of hosts in parallel or sequence |
| Plans in YAML | Define steps, conditionals, and branching logic in `.yaml` files |
| Reuse Puppet Modules | If you have existing content, it can use it — but doesn’t depend on it |
| Output as JSON | Machine-readable result stream, fits CI tools and pipelines |
You write either simple one-liners or structured plans. Either way, results come back as structured data. Not pretty — just usable.
Deployment Notes
– Bolt is packaged as a CLI tool; install it via apt, yum, brew, or MSI
– Supports Windows, Linux, macOS as controller (host machine running Bolt)
– Targets need SSH (Unix) or WinRM (Windows) — no agents, no daemons
– Inventory is optional but helps: define nodes, groups, and variables in YAML
– Can run standalone tasks or more complex logic through modules/plans
There’s no GUI. Everything’s command-line. Logging and error messages are text-first, not polished — but clear enough.
Usage Scenarios
– Rebooting a set of servers after patching
– Pulling logs from 20 machines for diagnostics
– Running quick fix scripts across production without writing Puppet code
– Preparing systems before Puppet applies full config
– Launching scripts remotely as part of a GitHub Actions job
It’s especially useful in mixed environments — where not all machines are managed the same way, or where some systems can’t run agents for policy reasons.
Known Limitations
– Not designed for continuous enforcement — no “state” concept
– No scheduler; external cron/CI needed to trigger runs
– WinRM setup is non-trivial, especially in locked-down Windows domains
– Error handling in YAML plans can get verbose fast
– For larger fleets (hundreds of nodes), performance tuning required
Compared to Other Tools
| Tool | What It Does | Why Bolt Instead |
| Ansible | Declarative playbooks, modules | Bolt is faster to start, smaller footprint |
| Salt SSH | Ad-hoc via salt-ssh | Bolt has no master/minion at all |
| Bash + SSH | Classic approach | Bolt adds structure and inventory handling |
| Puppet Core | Agent-based state management | Bolt runs before or outside that lifecycle |
