Semaphore: Ansible UI When the Team Grows
Updated: 2026-07-07
Semaphore is the open-source Ansible web UI that solves the four scaling problems: audit trails, role-based permissions, execution history, and centralised secrets. It consumes ~500 MB versus AWX at ~4 GB. The pragmatic choice for mid-size teams that have outgrown running playbooks from a shared terminal.
Semaphore[1] is the open-source web interface for running Ansible playbooks: simple, lightweight, self-hostable. Born as a pragmatic alternative to AWX (upstream open-source of Ansible Tower / Red Hat Ansible Automation Platform) — fewer features, but dramatically simpler to operate. For mid-size teams that have outgrown "run from laptop" but don’t need AWX complexity, it’s the sensible choice.
Key takeaways
-
Semaphore solves the four Ansible scale problems: audit, permissions, execution history, and centralised secrets.
-
The architecture is minimal: one Go binary, PostgreSQL, and Ansible available on the server or container.
-
RBAC covers five well-defined roles (admin, project owner, manager, task runner, guest).
-
Semaphore consumes ~500 MB RAM; AWX typically needs ~4 GB.
-
For teams of fewer than 50 with moderate needs, Semaphore is the right choice. AWX for large teams with complex workflows.
What Semaphore solves
Problems arising as teams grow:
-
Audit: who ran which playbook when against which hosts?
-
Permissions: which users can run which playbooks against which inventory?
-
History: what output did that execution a week ago produce?
-
Schedules: periodic playbooks without dedicating a cron host.
-
Centralised secrets: vault keys, SSH keys, without distributing across laptops.
Architecture
Minimum components:
-
Semaphore server (Go, single binary).
-
Database: MySQL/MariaDB, PostgreSQL, or embedded BoltDB.
-
Ansible available on the server or container.
No distributed workers or complex queues. For teams with fewer than 100 simultaneous runs, sufficient.
Docker Install
version: "3.8"
services:
semaphore:
image: semaphoreui/semaphore:latest
ports:
- "3000:3000"
environment:
SEMAPHORE_DB_DIALECT: postgres
SEMAPHORE_DB_HOST: postgres
SEMAPHORE_DB_USER: semaphore
SEMAPHORE_DB_PASS: ${DB_PASS}
SEMAPHORE_DB: semaphore
SEMAPHORE_PLAYBOOK_PATH: /tmp/semaphore
SEMAPHORE_ADMIN_PASSWORD: ${ADMIN_PASS}
SEMAPHORE_ADMIN_NAME: admin
SEMAPHORE_ADMIN_EMAIL: admin@example.com
volumes:
- semaphore_data:/etc/semaphore
- semaphore_tmp:/tmp/semaphore
depends_on:
- postgres
Start and log into http://localhost:3000 as admin.
Key Concepts
-
Project: isolated space with its inventory, keys, templates.
-
Inventory: list of hosts — static or dynamic (script, AWS, etc).
-
Key Store: SSH keys, passwords, vault passwords.
-
Repository: Git repo where your playbooks live. Semaphore pulls and executes.
-
Task Template: associates a playbook + inventory + keys. This is what runs.
-
Schedule: a template that runs on cron.
Semaphore vs AWX
| Aspect | Semaphore | AWX |
|---|---|---|
| Deploy complexity | Simple (Docker) | Complex (Kubernetes recommended) |
| RBAC | Basic-medium | Advanced |
| Workflows | Limited | Advanced (graph) |
| Commercial support | No | Yes (Red Hat) |
| Resource consumption | ~500 MB RAM | ~4 GB RAM |
| Learning curve | Low | Medium-high |
Semaphore for teams of fewer than 50 with moderate needs. AWX for large teams with complex requirements.
Typical flow
The team maintains a Git repo with Ansible playbooks. In Semaphore you create a project pointing to that repo, define inventories (production, staging), upload the SSH key that reaches the target hosts, and create task templates: deploy web service, rotate certs, restart postgres. Team members run templates from the UI, watching live output. Permissions apply throughout: admins can do everything; others only what they are assigned.
Permissions and RBAC
Five clearly defined roles:
-
Global admin: manages users and global settings.
-
Project owner: manages their project.
-
Manager: can run and edit templates.
-
Task runner: runs existing templates only.
-
Guest: read-only.
For teams with a clear dev/ops split this covers the common cases well. For complex multi-tenancy, AWX offers more granularity.
CI/CD integration
Semaphore exposes a REST API, which enables several common patterns: Gitea or GitHub Actions can call the Semaphore API after a PR merges; repo webhooks can trigger dynamic inventory rebuilds; ChatOps bots can run templates via API; monitoring alerts can trigger remediation templates automatically.
Operational security
A short checklist for production deployments:
-
HTTPS mandatory via reverse proxy (Traefik or Nginx).
-
Integrated auth with OIDC or LDAP.
-
SSH keys with passphrase or Vault for secrets.
-
Regular backups of the data volume and DB dump.
-
Monitor failed login attempts.
Conclusion
Semaphore is the pragmatic option for mid-size teams wanting an Ansible UI without AWX complexity. Its simplicity focus is its strength: install in minutes, operate painlessly, covers real cases. For large organisations with complex workflow requirements, enterprise SSO, and multi-tenancy, AWX remains the reference. Choice should be based on team size and needs sophistication. Often, simple is right.