An approval binds the run the approver saw: its inventory snapshot, its image digest, its commit, and for a Terraform or OpenTofu apply, the saved plan. People, pipelines, and AI agents go through the same gate, an AI agent's run waits for a person by default, and an agent can never approve. Every change leaves a signed receipt anyone can verify offline.
Source-available. BSL 1.1. Go SDK with drop-in plugins. One binary and one database.
Already on AWX? Drop your export here and see what moves, what does not, and how many of your templates run today with nobody required to approve them. It is read in your browser and never uploaded. The same report comes from switchtender assess awx export.json, and switchtender import awx then brings projects, inventories, templates, surveys, and schedules over in one command.
Worth knowing if that is where you are: AWX has not shipped a release in over two years, it carries an unpatched CVSS 9.6 whose fix ships only in the paid product, and the supported way off it is priced per managed node.
Would rather not do it yourself? The Migration Program is $25,000 fixed price, four milestones, about six weeks, first year of Team at the 500-host band included. It covers the part that actually goes wrong: cutting over without a window where neither system is authoritative.
Multi-tool execution is common now. The difference sits above execution: a control plane that proves what happened and enforces what's allowed.
terraform destroy holds for an admin's sign-off, automatically.A run painted live as a host-by-task matrix, not a wall of scrollback. The colors speak Ansible: green means ok, amber means the task changed the host, red means failed, gray means skipped.
Most controllers keep an activity log: rows in their own database, editable by whoever holds the database. SwitchTender writes every change into a hash chain, then gives you six ways to carry the proof out of the building. What changed, who asked, and who approved it become things you show, not things you say. Every claim on this page is defended adversary by adversary, limits included, in the threat model.
Don't take the receipts on faith. Pull the live demo's signed history with curl and check it with LoomSeal: Apache-2.0, a published format with conformance vectors, and a second implementation in Python. We publish LoomSeal too, so what you are trusting is the format and the vectors, not our word.
Or make it prove itself the hard way: scripts/prove.sh in the repository starts a server, gives an AI agent a token of its own, writes no approval policy, has the agent propose a real deletion, watches the built-in hold on agent runs stop it, refuses the agent's attempt to approve itself, lets a person with their own token release it, performs the deletion for real, then verifies the signed record against the server's published key and requires verification to fail after the script rewrites who asked. About a minute, and every step is a real request the server decides. The supertest does the same and more against a fresh Kubernetes cluster on every push to main.
Every mutation through the API other than signing in or out returns an Audit-Receipt header naming its place in the chain. Keep it. Months later, switchtender audit receipt proves the chain still holds that entry at that position, and a server that dropped it can't answer.
The Evidence button on any run, or switchtender audit run, emits one self-contained file: the spec, the risk grade, who approved it, what happened on each host, and the receipts and anchors behind all of it. An auditor's sample request is answered in one export.
switchtender audit report renders a period's changes, up to five thousand, and says on its face when the period held more, the sample that SOC 2 CC8.1 and ISO/IEC 27001 A.8.32 reviews ask for. The control mapping and a sample pack show exactly what an assessor gets. Point --evidence-dir at an archive and registers write themselves on a cadence, so the evidence exists before anyone asks. The register needs Team. The receipts, dossiers, and signed bundles beside it are free.
switchtender witness watches the chain's public feed from a second machine, keeps a signed checkpoint of what it saw, and raises a finding when history shrinks or a beat goes missing. The hosted witness countersigns an enrolled install's chain as it grows, and switchtender verify holds an export to the witness's signed statement, so history it has seen cannot be rewritten without the check failing.
Stream every audit entry into your SIEM as NDJSON or RFC 5424 syslog, each event carrying its chain receipt. Delivery is at-least-once behind a durable cursor, so an outage delays events instead of dropping them, and any sampled event redeems against the live chain.
Export the chain as a signed LoomSeal bundle and check it on a machine with no network, using a verifier that is not this binary, or in your browser with nothing uploaded. LoomSeal is an open Apache-2.0 format anyone can reimplement. Pin the install's key from /.well-known/loomseal.json, and the bundle never vouches for itself.
These run against demo.switchtender.com, a live instance that wipes and reseeds its history every night. It runs the Community build, the same one you download. That makes the last command a live-fire exercise: become its witness today, run it again tomorrow, and the witness will refuse the rebuilt history with a finding. That alarm is the product working. A nightly reseed is exactly what a rewritten chain looks like from outside, and nothing the server says can talk your witness out of what it saw.
# 1. the server re-verifies its whole chain, entry by entry
curl -s https://demo.switchtender.com/v1/audit/verify
# 2. pull the whole chain as a signed bundle, yours to keep and verify anywhere
curl -s https://demo.switchtender.com/v1/audit/bundle > demo-bundle.json
# 3. verify that bundle offline against the key the demo publishes,
# with LoomSeal, a verifier that is not this binary (install: loomseal.com,
# or skip the install and drop the file on switchtender.com/verify)
fp=$(curl -fsS https://demo.switchtender.com/.well-known/loomseal.json | jq -er .key_id) &&
loomseal verify demo-bundle.json --fingerprint "$fp"
# 4. become its witness: keep a signed checkpoint of the head you saw.
# Run it again after tonight's reseed and watch it catch the rewrite.
switchtender witness --server https://demo.switchtender.com --onceMoving the objects is an import, not a rebuild. AWX, Semaphore, Chef, Puppet, Rundeck, and Jenkins each have an importer, and Ansible Automation Platform, Tower, and Ascender export through the same awxkit command with the same top-level keys, so the AWX importer reads them too. Even a crontab imports, line by line, into governed schedules. Export, preview exactly what will land, then apply. Projects, inventories with their hosts and groups, smart and constructed inventories, dynamic inventory sources, job templates, workflows with their approval steps, surveys with their secret fields, schedules with their recurrence rules, custom credential types, notification templates, and credential shells all come across in one pass. A malformed asset is skipped with a warning instead of failing the import, so even a partial export migrates everything it can. What an importer moves is structure: the behavior around it, the variable somebody set once, the boot script still pointing at the old server, the habit nobody wrote down, is the part that takes a person. switchtender assess reads an AWX, Semaphore, Chef, or Puppet export and tells you how much of that there is before you start, and names every field it does not read.
# 1. preview: read the AWX export, print the plan, write nothing
switchtender import awx awx-export.json --db switchtender.db
# 2. set the encryption pair the server will run with, and keep both values:
# the server must start with this same pair
export SWITCHTENDER_ENCRYPTION_KEY=$(openssl rand -hex 32)
export SWITCHTENDER_ENCRYPTION_SALT=$(openssl rand -hex 16)
# then apply: create every project, inventory, template, survey, and schedule
switchtender import awx awx-export.json --db switchtender.db --apply
# on Semaphore instead? swap one word:
switchtender import semaphore export.json --db switchtender.db --applyCredentials arrive as named shells, since these exports omit secret material by design. Re-enter each secret once and every template that references it works. A template that took provisioning callbacks keeps its old AWX address only when the import knows its AWX id, and awx export strips ids, so save GET /api/v2/job_templates/ as JSON and pass it with --awx-template-ids. The switching guide maps every AWX concept to its SwitchTender equivalent, and the AWX alternative page makes the full case.
Everything on this page without a Team line ships in the binary you already deployed: no host caps, no seat caps, no run caps, no time limit. Nothing that is free today will ever move behind a paywall. Five cards carry a Team line, and each says so where it applies. Those run on the paid build, a separate download.
Every change links into a tamper-evident SHA-256 hash chain, and a change that can't be recorded is refused rather than made quietly. Export the chain as a signed LoomSeal bundle and verify it offline with an open, independent verifier, without trusting the server. From LoomSeal 1.7.0 on, the verifier also checks what a run's receipt discloses, its spec, its outcome, and each approval decision, against what the chain committed, so a receipt edited and signed again fails.
Read a run like a dashboard instead of a scrollback. Every host and task paints itself live as the run happens, and each cell opens to its own output and exit code.
Ansible, Terraform, OpenTofu, Bash, PowerShell, Python, and Go. One engine, one UI, one audit trail, on the host or in a pinned container image. Ansible check mode and a Terraform or OpenTofu plan preview a change before it runs. Need an eighth? Write it in Go and plug it in.
A change made around the gate, over SSH or in a cloud console, still leaves a mark. A scheduled dry run shows exactly what has drifted across Ansible hosts and Terraform directories, and one click builds the fix, held for approval, so it goes back through the gate. None of the controllers in our comparison document it, and the Terraform control planes that do detect drift do not govern your Ansible fleet beside it. Detection is free. The one-click reconcile needs Team.
Hold risky runs for sign-off, gated by policy on tool, command, or target, and an agent token's runs are held with no policy written. Operators request, admins release. No skipping the gate. An approval binds what will run: a static, smart, or constructed inventory as snapshotted at submission, the container image by the digest its registry serves, or by its tag, said plainly, when the registry does not answer, and for a Terraform or OpenTofu apply the saved plan the apply carries out, however it came to be held. Community holds plain rules of your own, as many as you need: require-approval policies and exemptions. Deny rules and risk and reversibility floors are Pro. The full engine, with actor scoping and distinct-approver separation of duties, is Team.
A worker dials out to the control node with a token and opens no inbound port, so it runs jobs inside an air-gapped segment, a DMZ, or a customer network the control node can't reach. One binary, one outbound connection. A pool that registers a delivery key receives each run's secrets sealed to that key, opened in memory and removed when the run ends, so the worker holds no database and no encryption key. Running any worker process needs Team.
Risk says how bad a change is. It never says whether you can take it back, and the two come apart constantly: restarting a fleet is high risk and undoes itself, while deleting a backup set reads quietly and is permanent. Every run is graded reversible, costly, or irreversible, on every tier. A rule that holds a run on that grade is a reversibility floor, which is Pro. An Ansible run is graded from what it actually runs, every role and include read from the project at the commit that executes, not guessed from a file name.
One gather per host per day is kept rather than overwritten, about four hundred days deep by default, so you can ask what was running on the date of your last audit, and what has moved since: host by host, fact by fact, with the value at each end. Most tools answer only what is true now, because reconstructing the past needs an ordered history nobody can quietly edit.
Nobody means a run. They mean "we rolled out the fix", which was four runs, a rollback and a fix-forward, across three days. Label them and read the whole arc as one thing, with its span, everyone who acted, and an outcome worked out from the runs rather than typed in by whoever closed it. Make the label a ServiceNow change number or a Jira issue key, and the official plugin, a separate binary, records each run on that ticket.
Shard a big job across hosts, balanced by each host's measured duration. Retry only the shards that failed, not the whole run.
It flags flaky hosts, trends how long each task takes, and keeps every host's history across runs. Most controllers keep each run's history but never flag a flaky host or trend a task's duration.
Drag steps from all seven tools into one graph. Fan out, fan in, retry any step, run the whole pipeline. No YAML by hand.
Type a cron expression, or an RFC 5545 recurrence rule for what cron cannot say, such as the last Friday of each quarter, and see its next firings before you save it. A scheduled launch carries its template's approvals, notifications, and timeout, and every run records which schedule started it. A server that stops mid-fire hands the occurrence back, and the occurrence's key keeps it from running twice. Where several servers share a PostgreSQL database, another takes it up.
Global roles, teams, organizations, and per-object read, use, and manage grants. Delegate view of one credential without a global viewer, or a whole org inherits a project at once. All of it ships in the core, not a paid tier.
Off by default. Switch it on to triage a failure, answer a fleet question, or draft a run from a sentence. It proposes, never executes. Bring your own model: local Ollama, Claude, or any OpenAI-compatible API.
One click verifies every registered reference: templates to inventories, projects, and credentials, schedules to templates, every cron expression. Broken links surface with a fix button before they break a run.
Rerun any finished run with its exact spec, credentials included, one click. Or launch a template with overrides: host limit, inventory, credential picks, extra vars, dry run. Every override is authorized like a fresh launch.
Every list exports to CSV or JSON, filtered exactly as you see it. Every run exports its events, log, and per-host results. Copy a link to any run, in any of the three themes.
Each run records what fired it, the template, schedule, rerun, or drift fix behind it, and who asked. Add labels like env=prod, then search with fielded terms: status:failed host:web01 label:env=prod, resolved across your whole history.
A finished run, or one held for approval, reaches Slack, Teams, Discord, Mattermost, Rocket.Chat, ntfy, email, or a webhook. A failure pages PagerDuty or texts through Twilio, and every run lands on your Grafana dashboards as an annotation. Eleven channels, server-wide or per template, so each team pages its own people. A named target's deliveries are queued in the database in the same write as the event, sent in the run's order, retried, and made by the next server to start if one stops.
Sealed at rest, sourced live from Vault, AWS, Google, Azure, CyberArk, or 1Password, and kept off the command line so nothing shows in the process table. A tool that prints a secret shows ***, even when it re-encodes it as base64, hex, or an escaped string. Typed cloud credentials inject the exact variables each tool expects.
Static INI, YAML, and JSON inventories, and the smart inventories filtered over them, resolve inside the binary with Ansible's own quirks, from value typing to host ranges, so the server needs no Ansible to read them. CI holds that reading to every ansible-core minor from 2.16 to 2.21, and before an Ansible run the executor's own ansible-inventory reads the same inputs, so any difference refuses the run.
A new machine posts the template's callback key to its callback URL at boot, and the template runs against that host alone. It is AWX's provisioning callback, matched to the caller by AWX's rules and gated like any launch. A template imported from AWX answers at its old AWX address too, when the import knows its AWX id, so boot scripts keep working once the hostname points here.
A federated credential holds no secret. Each run that uses one gets a short-lived identity token, signed here and naming the run, its project, template, environment, and who launched it, which AWS, Google Cloud, or Azure exchanges for credentials that expire on their own. The signing key rotates on a fixed schedule that gives each cloud a day to fetch the new key, or at once in an emergency.
Write approval policy in the Open Policy Agent language, so an OPA or Conftest rule you already have ports without a rewrite. Evaluation never leaves the process: network, clock, and random builtins are removed, so a run gets the same answer on every server, and the decision records the digest of the exact bundle. Rego policies are Team.
A rule that lets dry runs through first reads each one for the known ways a check or a plan acts: tasks that set check_mode: false, pipe lookups that run a command on the controller, and the external, aws_lambda_invocation, and writing http data sources a plan would call, in the configuration and every module it calls. A dry run that could act for real is held like the real run, with a note naming what was found. The scan cannot prove a preview harmless, since lookups, plugins, and providers run code too, so the rule trusts the code it lets through, and an agent's dry run waits for a person either way, unless an exemption covers it.
A review trigger plans a GitHub or GitLab pull request at its head commit in the tool's no-change mode and posts the result on the pull request as one comment per template, updated in place on every push, with a commit status beside it. A person whose GitHub or GitLab account is linked can comment /switchtender apply to approve and apply the reported plan, with the same role, grants, and separation of duties as the approval queue. How it works.
Wire Ansible, Terraform, OpenTofu, Bash, PowerShell, Python, and Go steps into a graph, plus any tool you plug in. Fan out, fan in, and run the whole thing as one pipeline with per-step retries. It runs in the same binary as everything else.
An agent's token is minted as an agent's, naming the human it acts for, and capped below admin so it can never approve its own work or touch identity, access, or secrets. Agents can propose changes. Only authorized humans can approve them. An agent's run waits for a person's approval with no policy written, unless a rule with effect: exempt covers it, and the receipt then proves who approved exactly the change that ran, or which rule exempted it. Its dry runs wait too, and its Terraform or OpenTofu apply waits twice, once before it plans and again carrying the saved plan. On Pro, rules can also refuse outright, and on Team they can require an approver other than the human the agent acts for. Every agent run lands in the chain as the agent's, on behalf of its human. We govern what agents are allowed to do.
Everything above runs with no model anywhere near it: the live matrix, the balanced splits, the governance, the audit chain. Advisory AI is an add-on, and nothing else depends on it.
Switch it on and it proposes a diagnosis for a failed run, answers a plain-English question about your fleet, or drafts a run from a single sentence. That's all it does. It can't execute anything. Every draft waits at the same approval gate you do, and it never sits in the execution path. Bring your own model: Ollama on your hardware, Claude with your Anthropic key, or any OpenAI-compatible endpoint. Secrets are masked before a model sees a byte.
AI advises. SwitchTender enforces.
Ansible, Terraform, OpenTofu, Bash, PowerShell, Python, and Go are all built in, no plugins required: put the tool on the host, or run it in a container image, and it goes through the same gate. That is the point: a boundary that only Ansible respects is one somebody leaves by writing a shell script. When you need an eighth tool, a custom secret backend, a new AI provider, or your own notification channel, you write it in Go against a stable SDK. Compile it into the binary, or build it once and drop it into --plugins-dir, where a stock release loads it at startup over gRPC with mutual TLS and treats it as its own. A plugged-in tool submits, validates, and audits like a built-in. A plugged-in channel gets every terminal run with secret-carrying vars already redacted. The SDK guide walks both paths and carries a complete extension you can build and drop in.
// build once, drop into --plugins-dir, no recompile of switchtender
import (
"github.com/kordloom/switchtender/sdk"
"github.com/kordloom/switchtender/sdk/plugin"
)
func main() {
plugin.Serve(&plugin.Extension{
Tools: map[string]sdk.ToolRunner{"packer": sdk.ToolRunnerFunc(runPacker)},
Notifiers: map[string]sdk.Notifier{"pagerduty": sdk.NotifierFunc(page)},
})
}Every product in this table runs jobs and schedules them, and most of them pause a workflow for a click. SwitchTender starts one layer above that. An approval here commits a digest of the inventory snapshot, the resolved container image, the pinned commit, and the saved plan, and the executor recomputes that digest before it runs anything. An AI agent gets one credential and a ceiling below admin, so it can propose a change and never approve one. The audit trail is a signed hash chain that an Apache-2.0 verifier checks offline, without an account on this server or trust in it. No product in this table documents an approval whose digest is recomputed at run time, an agent that cannot approve its own run, or evidence verified without the server. The nearest things are documented in the comparison doc: Ansible Automation Platform checks signed project files and an OPA policy at launch, separately from its approval node, and Rundeck limits its MCP server with an ACL policy that the operator writes. The rest of the table is controller work, and all of it but the Team row is free. The comparison doc says row by row where that is ahead, even, or behind, with a source for each cell. Go deeper on any one: AWX, Ansible Automation Platform, Ascender, and Semaphore. How runs execute under load covers the engine underneath.
| Capability | SwitchTender | AWX | AAP / Tower | Semaphore | Rundeck |
|---|---|---|---|---|---|
| Approval bound to the content that runs: inventory, image, commit, plan | a digest recomputed before execution | workflow node records a decision, not a digest | workflow node and orchestrator step record a decision, not a digest; project signing and OPA policy check files, image, branch, and inventory at launch, separately from the approval | workflow approval node; docs say Pro, pricing lists it in every tier; binding not documented | no native approval step; ServiceNow steps can check a change request's state |
| Hard ceiling on AI agents: cannot approve its own run or touch identity or secrets | agents are principals capped below admin | no AI feature | task agents with tool access set to All, Selected, or None, credentials by reference; approval step needs approval:decide; whether an agent can hold it is not documented | MCP server inspects and updates projects, templates, inventories, repositories, schedules; no ceiling documented | ceiling set by the operator in an ACL policy on a dedicated user's token; docs recommend starting read-only with no job execution |
| Evidence a third party verifies offline, without trusting the server | signed hash chain, Apache-2.0 verifier | no; Red Hat directs user activity logs to external providers for non-repudiation | |||
| Deploy without Kubernetes | VM installer | ||||
| Live host-by-task matrix | per-host summary | per-host summary | log stream; per-host OK and failed counts for Ansible, Pro | per-node, per-step | |
| Ansible, Terraform, OpenTofu, Bash, PowerShell, Python, Go | Ansible only | Ansible playbooks and rulebooks; REST and AI agent steps in automation orchestrator, a separately installed component | Terragrunt too; Go through a custom app only | scripts, no native IaC | |
| Duration-balanced job splitting | round-robin | round-robin | |||
| Fleet memory: flaky hosts, trends | |||||
| Tamper-evident, signed audit | activity log | activity stream; Red Hat directs copies to external providers | activity log; syslog over TLS and Splunk HEC webhook in paid tiers | activity log in all editions; audit trail commercial; nothing hashed or signed | |
| Secret values auto-masked in logs | opt-in | opt-in | not documented | secure options | |
| Enforced approval policies | basic | workflow node; orchestrator step with a 1-day default window; neither records a digest | workflow node, manual, binding not documented; docs say Pro, pricing lists every tier | no native step; ServiceNow change-state check | |
| One-command migration in | its own project export only | ||||
| Drift detection from a dry run | |||||
| Drag-and-drop workflow editor | shipped in 2.19 as beta; docs say Pro, pricing lists every tier | linear steps | |||
| AI that cannot execute: triage, answers, drafts, every draft held at the gate | RAG assistant; task agents call tools through MCP | MCP server, reads and writes | MCP server creates jobs and calls the API under a scoped token; AI-generated runbooks commercial | ||
| Drop-in Go plugins: tools, secrets, AI, notifiers | Java plugins | ||||
| Container execution for every built-in tool | Ansible only | Ansible only | Docker Pro, Kubernetes Enterprise | ||
| Typed cloud credentials, pluggable types | custom types and plugins | custom types and plugins | per-task JWT to Vault, AWS, GCP, Azure; key store holds SSH or password, syncs from Vault and OpenBao on Pro, AWS Secrets Manager and Devolutions on Enterprise | ||
| Organizations, teams, per-object grants | teams, four fixed roles | policy files, no GUI editor | |||
| Instance groups: pin work to worker pools | Team | Pro | enterprise | ||
| Active-active HA on PostgreSQL | on every tier | via Kubernetes | via Kubernetes | enterprise | enterprise |
Every row was checked against each vendor's own documentation on 8 October 2026, at AWX 24.6.1, Ansible Automation Platform 2.7-9 with automation orchestrator 2026.8, Semaphore 2.19.16, Ascender 25.6.2, and Rundeck 6.2.1. All five keep shipping, so a table like this starts going stale the day it is written. If a row is wrong, open an issue and we'll fix it.
One binary, one SQLite file. No control plane to stand up first.
# install (or grab a release binary)
go install github.com/kordloom/switchtender@latest
# Ansible runs need ansible-core: skip this if it is on your PATH,
# or install a pinned, hash-checked one beside the database
switchtender ansible install
# serve: SQLite by default, PostgreSQL optional
switchtender serve --addr :8080 --db switchtender.db
# open the UI
open http://localhost:8080/ui/Structured data end to end: what fired each run, who asked for it, which hosts it touched, and where it broke. Every column sorts and filters.
KordLoom, a small company, builds and supports SwitchTender. Community support is the public issue tracker. Pro adds email support with an engineer's first response within two business days, and on Team a Severity 1 report gets one within one business day or each miss adds a month to the license term, on clocks the terms define.
Nothing you run depends on us staying around. There is no license server and no phone-home, so an install keeps running as it is, a paid license keeps verifying offline through its term, and your data and receipts stay yours, checked by an open verifier that does not depend on us. Every release of the public core converts to Apache 2.0 two years after it ships, and at once if KordLoom ceases business, as the pricing page sets out.
Who asked, who approved it when a person had to, what changed on every host, and proof that none of it was edited after the fact. Human or AI agent, the record is the same, and once the chain is anchored, anyone can check it offline without trusting your server or ours.
Self-hosted, nothing phones home, and a lapsed license takes nothing with it. You never bet your operations on our survival.
Occasional notes on releases and what changed. No noise.