boundary/website/content/docs/installing/high-availability.mdx

---
layout: docs
page_title: High Availability Installation
sidebar_title: High Availability Install
description: |-
  How to install Boundary in a high availability environment
---

# High Availability Installation

Installing Boundary in a high availability setting requires prerequisits for infrastructure. At the most basic level, Boundary operators should run a minimum of 3 controllers and 3 workers. Running 3 of each server type gives a fundamental level of high availability for the control plane (controller), as well as bandwith for number of sessions on the data plane (worker). Both server type should be ran in a fault tolerant setting, that is, in a self-healing environmnet such as an auto-scaling group. The documentation here does not cover self-healing infrastructure and assumes the operator has their preferred scheduling methods for these environments.

## Network Requirements

- Client -> Controller port is :9200
- Controller -> Worker port is :9201
- Client must have access to Controller on :9200
- :9201 must be open between Worker and Controller
- Workers must have a route and port access to the targets which they service

## Architecture

The general architecture for the server infrastructure requires 3 controllers and 3 workers. The documentation here uses virtual machines running on Amazon EC2 as the example environment, but this use
case can be extrapolated to almost any cloud platform to suit operator needs:

![](/img/production.png)

As shown above, Boundary is broken up into its controller and worker server components across 3 [EC2 instances](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/instance), in
3 separate [subnets](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/subnet), in three separate [availability zones](), with the controller API and UI being publically exposed by an [application load balancer (ALB)](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/lb). The worker and controller VM's are in independant [auto-scaling groups](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/autoscaling_group), allowing them to maintain their exact capacity.

The workers must be able to establish a connection to clients which they interact. In the architecture above, we place them in the public subnet so our remote client can establish a session between them and the target VM.

Boundary requires an external [Postgres](https://www.postgresql.org/) and [KMS](https://aws.amazon.com/kms/). In the example above, we're using AWS managed services for these components. For Postgres, we're using [RDS](https://aws.amazon.com/rds/) and for KMS we're using Amazon's [Key Management Service](https://aws.amazon.com/kms/).

## Architecture Breakdown

### API and Console Load Balancer

Load balancing the controller allows operators to secure the ingress to the Boundary system. We recommend placing all Boundary server's in private networks and using load balancing tecniques to expose services such as the API and administrative console to public networks. In the high availability architecture, we recommend load balancing using a layer 7 load balancer and further constraining ingress to that load balancer with layer 4 constraints such as [security groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) or [IP tables](https://wiki.archlinux.org/index.php/Iptables).

For general configuration, we recommend the following:

- HTTPS listener with valid TLS certificate for the domain it's serving or TLS passthrough
- Health check port should use :9200 with TCP protocol

### Controller Configuration

When running Boundary controller as a service we recommend storing the file at `/etc/boundary-controller.hcl`. A `boundary` user and group should exist to manage this configuration file and to further restrict who can read and modify it.

For detailed configuration options, see our [configuration docs](docs/configuration).