Keep Semaphore available when an app node stops

The documented active-active architecture uses multiple Semaphore application nodes, a shared PostgreSQL or MySQL database, Redis coordination, and a load balancer that supports HTTP and WebSocket traffic. Each node needs the appropriate shared settings and a unique HA identifier. Plan the availability of those dependencies alongside the application nodes. A second process alone does not provide the shared state and coordination required for the full topology.

The architecture described here is active-active, with equal application nodes participating in the service. It does not depend on a dedicated primary application node and a passive standby. Use the current HA guide to configure the supported design and avoid inferring a separate active-passive reference architecture from general availability language. If your infrastructure requires a different topology, resolve its state and failover behaviour before deployment.

No. The documented HA design requires a shared PostgreSQL or MySQL database together with Redis. The database is the common source of application state for the participating nodes. If you are moving from a single-node setup with another storage option, plan migration, backups, and validation as separate work. Adding application nodes should not be the first time you test that the intended shared database contains and serves the required data.

Those components need their own resilience strategy. Semaphore's multi-node application design does not automatically create database failover, redundant load balancing, or an available Redis service. Identify each dependency's failure domain, recovery process, and capacity requirements. Test the complete path from a client request to a task result so your availability plan covers the service people use, rather than only the number of application nodes running.

Do not assume uninterrupted in-flight execution from the presence of multiple application nodes. Behaviour depends on the execution path, the failed component, and the release being operated. Test the task lifecycle you rely on, including status reporting and any runner involvement. Likewise, plan upgrade compatibility and migrations deliberately instead of treating every version change as a guaranteed zero-downtime rolling operation. UI availability and task continuity are different requirements.

High availability is an Enterprise capability. Start with your required operating hours, maintenance process, recovery objectives, and existing database and load-balancer services. Use the documented topology to identify gaps, then test node removal, dependency recovery, and backups in a representative environment. An architecture discussion is useful when those requirements are business-critical because the complete deployment, rather than a single feature switch, determines the result.

That is the purpose of putting active app nodes behind one load-balanced service address. The load balancer must stop sending requests to the unavailable node and support both HTTP and WebSocket traffic. The surviving node still needs access to the shared database, Redis and matching application configuration to serve the project.

No. Multiple execution locations are handled by runners. High availability concerns the Semaphore application layer, while runners concern where tasks execute and which systems they can reach. A production deployment can use both: HA app nodes for the shared UI and API, and project runners near private infrastructure.