Semaphore UI documentation
Instead of ssh-ing into a box to run a playbook, you point Semaphore at a Git repository, describe the run once as a task template, and give the people who need it a button, a schedule, or an API call.
Docker, package manager, binary or Helm, in a few minutes
From an empty install to a playbook running on real hosts
config.json, environment variables and the options that matter first
Server, database and runners, and where your automation actually executes
The unit of separation for teams, environments and applications
Reusable run definitions, and the runs themselves
Which hosts to touch, and what to pass them
SSH keys, tokens and vault passwords, encrypted at rest
Playbooks, vaults, tags, limits and verbosity
Workspaces, variables and the built-in HTTP backend
Run scripts from your repository
Windows automation from a Windows runner
Scripts, dependencies and requirements.txt
Execute tasks on separate, isolated servers
Encryption, isolation, TLS and hardening
LDAP, Active Directory and OpenID Connect SSO
Active-active nodes behind a load balancer
Audit trail, syslog, SIEM and Prometheus
Move to a new version safely
Setup, users, projects, vaults, migrations
Turn on Pro and Enterprise features
What Semaphore is not#
It is not a hosted service. Every plan — Community, Pro and Enterprise — runs in your own environment, and your credentials never leave it. It is also not a replacement for Ansible or Terraform: it runs the tools you already use, and adds history, access control, scheduling and an API on top.
Getting help#
- Something is broken: start with Troubleshooting.
- Community: Discord.
- Bugs and feature requests: GitHub Issues.
- Source: semaphoreui/semaphore — MIT licensed.
Community is free forever. Pro adds isolated project runners, Vault-backed secrets, SSO and a support SLA.