> For the complete documentation index, see [llms.txt](https://docs.devolutions.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devolutions.net/powershell-universal/config/hosting/high-availability.md). # High Availability Configure PowerShell Universal high availability using SQL persistence, load balancers, one-way git sync, and status health checks across clustered nodes. PowerShell Universal can be configured for high availability (HA) by combining SQL Server or PostgreSQL persistence with a load balancer. This keeps front-end tools, such as apps, accessible and allows back-end tools, such as jobs, to continue running when a node is unavailable. In this topology, a load balancer distributes traffic to each PSU node over ports 443/80. Each node independently reads and writes to the shared SQL Server (or PostgreSQL) database on port 1433, and pulls its configuration from the shared Git repository over ports 443/80. ## Persistence configuration Use SQL persistence, or PostgreSQL persistence, so every node in the cluster shares job queues, app tokens, identities, and other persisted data. Configure each node with the same database connection string. As jobs run and users sign in, PowerShell Universal stores the related data in the shared database so it is available to other nodes. ## Source control configuration Use Git synchronization to store and version-control the PowerShell configuration scripts that manage PowerShell Universal nodes. One-way Git sync is often preferred because nodes are read-only and pull configuration after it is merged into the production branch. Each node pulls configuration on a configurable interval, which defaults to one minute. Storing Git configuration settings in the database reduces per-node configuration. ## Load balancing PowerShell Universal supports load balancers such as F5 and nginx. Load balancers must provide: * Persistent (sticky) sessions for the admin console and apps. * WebSocket support for the admin console and apps. Configure the load balancer to use the status API for health checks. A `200` response means the target is healthy and can receive traffic; a `5xx` response means it should not receive traffic. ## Status APIs ### `/api/v1/status` `/api/v1/status` reports the health of the current node. Put a node in maintenance mode from **Manage > Computers & Groups > Computers** to make this endpoint return `503` and remove the node from load-balancer traffic during maintenance. It returns a 5xx response when any of the following applies: * The computer is in a startup-error state. * The computer is in maintenance mode. * A critical app failed to start. * The endpoint configuration is non-empty but no API endpoints are running properly. * An endpoint runspace pool is exhausted. The response is `503` with `One or more endpoint runspace pools are exhausted.` An empty `.universal/endpoints.ps1` file is healthy and does not cause a failure response. ### `/api/v2/status` `/api/v2/status` is the cluster health endpoint. In addition to the endpoint checks above, it returns `503` when: * Any computer in the cluster is offline and is not in maintenance mode. * Git sync is not successful on a node. * The endpoint configuration is non-empty but no API endpoints are running properly. * An endpoint runspace pool is exhausted. The response body is `One or more endpoint runspace pools are exhausted.` Use `/api/v2/status` for a load-balancer health probe when a target should be removed from service if the cluster is unhealthy or an endpoint environment has no capacity. For example, when an endpoint environment has a maximum runspace count of one and its only runspace is busy, the endpoint returns `503`; it returns `200` again when capacity is available. An empty `.universal/endpoints.ps1` file is healthy and does not cause a failure response. ## Limitations Highly available PowerShell Universal clusters have the following limitations. ### Multi-node caching Caching with `$Cache` is limited to a single process on a single node. For example, each app running outside the integrated environment has its own cache. `Set-PSUCache` does not share data across nodes unless `-Persist` is specified. Include this switch when all nodes require the same cache data. ### Multi-node app broadcast Multi-node app broadcast messages are not supported. Cmdlets such as `Show-UDToast -Broadcast` display a toast to connected users of the current node only; they do not broadcast to apps on other nodes. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.devolutions.net/powershell-universal/config/hosting/high-availability.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.