Adding in a reference install diagram so users know what to expect

public/docs/img/installation/octopus-install-diagram.png.json

@@ -0,0 +1 @@
+{"width":2145,"height":1419,"updated":"2026-05-07T22:28:53.266Z"}

src/pages/docs/best-practices/self-hosted-octopus/high-availability.mdx

@@ -30,6 +30,10 @@
 One of the benefits of High Availability is the database and file storage is running on a separate infrastructure from the Octopus Server service. For a production instance, we recommend everyone follow the steps below, even if you plan on running a single node instance. If anything were to happen to that single node, you could be back up and running quickly with a minimal amount of effort. In addition, adding a second node later will be much easier.
 :::
 
+:::figure
+![Octopus Deploy Self-Hosted Reference Diagram](/docs/img/installation/octopus-install-diagram.png)
+:::
+
 This implementation guide will help configure High Availability. If you are looking for an in-depth set of recommendations, please refer to our white paper on [Best Practices for Self-Hosted Octopus Deploy HA/DR](https://octopus.com/whitepapers/best-practice-for-self-hosted-octopus-deploy-ha-dr).
 
 ## How High Availability Works
@@ -39,20 +43,20 @@
 1. Tasks (Deployments, runbook runs, health checks, package re-indexing, system integrity checks, etc.)
 2. User Interface via the Web UI and REST API (Users, build server integrations, deployment target registrations, etc.)
 
 Tasks are placed onto a first-in-first-out (FIFO) queue. By default, each Octopus Deploy node is configured to process five (5) tasks concurrently, which [can be updated in the UI](/docs/support/increase-the-octopus-server-task-cap). That is known as the task cap. Once the task cap is reached, the remaining tasks in the queue will wait until one of the other tasks is finished. 
 
 Each Octopus Server node has a separate task cap. High Availability allows you to scale the task cap horizontally. If you have two (2) Octopus Server nodes each with a task cap of 10, you can process 20 concurrent tasks. Each node will pull items from the task queue and process them. 
 
 Learn more about [how High Availability processes tasks in the queue](/docs/administration/high-availability/how-high-availability-works) section.
 
 ## High Availability Limits
 
 Octopus Deploy's High Availability functionality provides many benefits, but it has limits. 
 
 1. All Octopus Server nodes must run the same version of Octopus Deploy. Upgrading to a newer version of Octopus Deploy will require an outage as you upgrade all nodes.
 1. You cannot specify the node a deployment or runbook run to execute on. Octopus Deploy uses a FIFO queue, nodes will pick up any pending tasks.
 1. If a deployment or runbook run fails, it fails. Octopus Deploy will not automatically attempt to re-run that failed deployment or runbook run on a different node. In our experience, changing nodes rarely has been the solution to a failed deployment or runbook run.
 1. All the Octopus Server nodes must connect to the same database. 
 1. Octopus Server nodes have no concept of a "read-only" connection to a database. All online nodes perform write operations to the database. Even if it is not processing tasks.
 1. Octopus Server nodes are sensitive to latency to SQL Server and the file storage. The Octopus Server nodes, SQL Server, and file storage should all be located in the same data center or cloud region. The latency between availability zones within the same cloud region is acceptable. While the latency between cloud regions or data centers is not.
 
@@ -60,17 +64,17 @@
 
 ## Calculating Task Cap
 
 The amount of computing resources required for the Octopus Server nodes and database is dependent on the task cap. The higher the task cap, the more resources you'll need. 
 
 To calculate the task cap we recommend using the number of applications or projects you need to deploy during the production deployment window. 
 
 - Deployments and runbook runs are the most common tasks. 
 - Deployments typically take longer than any other task, including runbook runs. 
 - Production deployments are time-constrained. They are done off-hours during an outage window.
 
 Once you know the number of projects and the duration of the window, you can calculate the task cap using the average deployment duration. If you don't know the average deployment duration, use 30 minutes as the starting point. The formula is:
 
 ```
 (Number of Projects to Deploy * Average Deployment Duration) / Production Deployment Window in Minutes
 ```
 
@@ -130,7 +134,7 @@
 
 #### Octopus Server node compute resources
 
 Below is a baseline for setting compute resources based on the task cap. You are responsible for monitoring the compute resource utilization of your Octopus Server nodes to ensure you aren't over or under-provisioning. 
 
 | Task Cap Per Node | Windows Compute Resources | Container Compute Resources        | 
 | ----------------- | ------------------------- | ---------------------------------- |

src/pages/docs/best-practices/self-hosted-octopus/installation-guidelines.mdx

@@ -21,6 +21,10 @@ There are three components to an Octopus Deploy instance:
 - **SQL Server Database** Most data used by the Octopus Server nodes is stored in this database.
 - **Files or BLOB Storage** Some larger files - like [packages](/docs/packaging-applications/package-repositories), artifacts, and deployment task logs - aren't suitable to be stored in the database and are stored on the file system instead.  This can be a local folder, a network file share, or a cloud provider's storage.  
 
+:::figure
+![Octopus Deploy Self-Hosted Reference Diagram](/docs/img/installation/octopus-install-diagram.png)
+:::
+
 This document will provide you with guidelines and recommendations for self-hosting Octopus Deploy.
 
 <OctopusReleases />

src/pages/docs/installation/index.mdx

@@ -33,6 +33,10 @@ All inbound traffic to Octopus Deploy is via:
 
 For production instances of Octopus Deploy, it is best to configure a [load balancer](/docs/installation/load-balancers) to route traffic to your instance.  Leveraging a load balancer offers numerous benefits, such as redirecting users to a maintenance page while the instance is down for upgrading, as well as making it much easier to configure High Availability later.
 
+:::figure
+![Octopus Deploy Self-Hosted Reference Diagram](/docs/img/installation/octopus-install-diagram.png)
+:::
+
 ## Self-hosted Octopus Server
 
 When installed, the self-hosted Octopus Server: