Runs are scrollback
A Semaphore run is a text stream. SwitchTender paints every host and task live as a matrix, with the failed host highlighted, per-task timing, and drill-down. Six hundred hosts stay readable.
Semaphore's simplicity.
A control plane on top.
Semaphore proved a one-binary Ansible UI is the right shape. SwitchTender keeps that shape and adds what teams go looking for next. Every run paints as a live host-by-task matrix instead of scrollback. Go joins the tool list, and every tool gets a uniform dry run. RBAC, teams, and enforced approvals are in the core. External secret managers plug in, from HashiCorp Vault to 1Password, where Semaphore stores only an SSH key or a password. And there's an audit trail you can prove offline. Your Semaphore backup imports in one command.
Where Semaphore stops
Semaphore is a fine task runner. These are the walls teams hit as the fleet grows.
Governance stops at the basics
Semaphore ships teams and four fixed project roles in its free build, and reserves custom per-template roles for its enterprise tier and single sign-on for its paid tier. It has no approval gates and no provable audit. SwitchTender ships organizations, teams, per-object grants, single sign-on, policy-enforced approvals, and a tamper-evident hash-chained audit trail in the core.
The fleet has no memory
Semaphore forgets a run the moment it ends. SwitchTender tracks every host across runs: flaky hosts flagged, durations trended, drift detected from a dry run, and big jobs split across shards balanced by measured host cost.
Feature for feature
The full three-way table including AWX is on the comparison page.
| Capability | SwitchTender | Semaphore |
|---|---|---|
| Deploy without Kubernetes | ||
| Live host-by-task matrix | ||
| Tools | Ansible, Terraform, OpenTofu, Bash, PowerShell, Python, Go, each with a dry run | No Go, no uniform dry run |
| Per-object grants | Four fixed roles free, custom roles enterprise | |
| External secret managers: Vault, AWS, Azure, GCP, CyberArk, 1Password | Vault, OpenBao, AWS, Azure | |
| Enforced approval policies | ||
| Tamper-evident, signed audit | ||
| Duration-balanced job splitting | ||
| Fleet memory: flaky hosts, trends | ||
| Drift detection from a dry run | ||
| Drag-and-drop workflow editor | On the roadmap | |
| Distributed workers in the core | Paid tier | |
| Active-active HA on PostgreSQL | ||
| Advisory AI triage and fleet answers | ||
| Drop-in Go plugins: tools, secrets, AI, notifiers | ||
| Import from the other side | One command |
Where Semaphore is still ahead
Semaphore has years of production use, a large installed base, and packaged distributions everywhere. SwitchTender is newer and doesn't have that history. If the features above matter more to you than the track record, the import brings your projects across in one command and you can see for yourself.
Move in one command
Export a Semaphore backup, import it into SwitchTender. Projects, inventories, templates, and schedules come across, with a dry run first so you see the plan before anything is written.
-
1
Preview the import
switchtender import semaphore backup.json --db switchtender.db -
2
Apply it
switchtender import semaphore backup.json --db switchtender.db --apply
The migration reference maps every Semaphore concept to its SwitchTender equivalent.
Common questions
The three asked most often when somebody is comparing this against what they already run.
Does it need an agent on each host?
No. It reaches the machines it manages over SSH, the same way Ansible does, and installs nothing on them. There is no per-host daemon to deploy, patch, or account for. You run the one server binary, and optionally a few more worker processes against the same store for throughput, which are pool members rather than agents belonging to a host.
Can it read secrets from AWS Secrets Manager, Azure Key Vault, or Vault?
All three, resolved at launch rather than copied into this database. Vault dynamic secrets go further: a short-lived credential is minted for each run and revoked when the run ends. AWS and Azure both authenticate from an instance role or managed identity with no stored key, and anything else resolves through a command whose output is the secret.
Can I run a Terraform plan, hold it for approval, then run Ansible?
Yes, and it is what pipelines are for here. Steps mix tools freely on a dependency graph with parallel branches, built on a drag-and-drop canvas. The approval is not a convention somebody can skip: a policy decides which runs are held, the core enforces the hold, and the approval binds to the exact plan reviewed, so a run cannot be approved as one thing and executed as another.