Semaphore

Why it's ranked here

The unusual thing here is how much of the commercial product actually sits in the open repository: the same services that run the hosted platform, not a stripped-down teaser, ship under a permissive license, with only the enterprise pieces walled off in their own directory under different terms. Governance keeps the roadmap and merge decisions with the vendor, not a neutral foundation, so calling it fully community-run would overstate things. What is verifiable, though, is that self-hosting gets you the real thing, not a crippled trial.

What's good

The project is split into narrow, single-purpose services instead of one large application: a dedicated log-archiving service, a separate artifact store with its own object-cleanup worker, and a standalone envelope-encryption service that keeps secret handling isolated from everything else. Version control extends to the client side too. The authentication service checks a connecting command-line client's reported version and rejects anything too old outright, rather than leaving compatibility to chance. Docker-based build and test targets are consistent across the Elixir, Go, and JavaScript pieces of the codebase, which matters in a project built from this many separate services.

Tradeoffs

The public API surface is deliberately narrow: a single gateway service forwards a fixed set of internal calls outward, so a capability that isn't already wired through it stays out of reach for anyone outside the project, regardless of what the internal services can already do. The paid extension lives in its own directory under a different license, and the repository gives no account of what has been moved there instead of the free edition, so evaluating the free tier alone means evaluating a deliberately incomplete picture of the product.

How to use it well

This fits a team that wants to run its own pipelines on infrastructure it controls, and that is comfortable operating several independent services together rather than one deployable binary: a message queue, an object store, and a cache all need to be stood up and kept running. Start with the single-machine install to evaluate it, move to the Kubernetes path once you need the workers split apart, and expect to write pipelines by hand in YAML rather than through a hosted no-code builder. It is not the choice for a team that wants CI it never has to operate.

Observed

License

Apache License 2.0 for the repository outside the ee directory; a separate commercial license governs the ee directory

Language / stack

Polyglot monorepo: Elixir for core services, Go for infrastructure services, TypeScript/React for the frontend, Ruby for webhook processing

Packaging

Ships as a multi-service monorepo built into per-service Docker images rather than one distributable binary

Install surface

Documented install paths for a single machine or a Kubernetes cluster, with a Minikube path for local development

Interfaces

A public HTTP/JSON gateway in front of internal gRPC services, plus a dedicated command-line client with server-checked version compatibility

Messaging

Inter-service coordination over RabbitMQ (AMQP) for job, pipeline, and workflow deletion workers

Structural observation

Enterprise-only code is isolated in a single ee directory rather than mixed throughout the rest of the codebase