--- layout: docs page_title: System requirements description: >- Learn about Boundary system requirements including recommendations for hardware sizing, network connectivity, traffic encryption, databases, and load balancers. --- ⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️ > [!IMPORTANT] > **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com. ⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️ # System requirements This topic contains specific recommendations for system requirements. All specifications outlined in this topic are minimum recommendations without any reservations towards vertical scaling, redundancy, or other site reliability needs. All resource requirements are directly proportional to the operations performed by the Boundary cluster, and the end users' level of usage. To match your requirements and maximize the stability of your Boundary controller and worker instances, perform load tests and monitor resource usage including reported matrices from Boundary's telemetry. Refer to [Monitor Boundary](/boundary/docs/monitor) for more information. ## Hardware sizing for Boundary servers Refer to the tables below for sizing recommendations for controller nodes and worker nodes, as well as small and large use cases based on expected usage. Controller nodes | Size | CPU | Memory | Disk capacity | Network throughput | |-------|------------|----------------|---------------|--------------------| | Small | 2 - 4 core | 8 - 16 GB RAM | 50+ GB | Minimum 5 Gbps | | Large | 4 - 8 core | 32 - 64 GB RAM | 100+ GB | Minimum 10 Gbps | Worker nodes | Size | CPU | Memory | Disk capacity | Network throughput | |-------|------------|----------------|---------------|--------------------| | Small | 2 - 4 core | 8 - 16 GB RAM | 50+ GB | Minimum 10 Gbps | | Large | 4 - 8 core | 32 - 64 GB RAM | 100+ GB | Minimum 10 Gbps | To ensure predictable performance, we recommend that you avoid "burstable" CPU and storage options whose performance may degrade under continuous load. ## Hardware considerations The Boundary controller and worker nodes perform two different tasks. The Boundary controller nodes handle requests for authentication and configuration. The Boundary worker nodes proxy client connections to Boundary targets which may require additional resources. Depending on the number of clients connecting to Boundary targets at any given time, Boundary workers can become memory or file descriptor constrained. As your users create new sessions, the Boundary worker node opens more sockets and ultimately creates additional file descriptors. Monitor both the file descriptor usage and the memory consumption of each Boundary worker node. ## Network considerations The amount of network bandwidth used by the Boundary controllers and workers depends on your specific usage patterns. For the Boundary controller, even a high request volume does not translate to a large amount of network bandwidth consumption. Boundary worker nodes proxy client sessions to Boundary targets. The bandwidth consumption depends on the amount of potential clients, the number of sessions created, and the amount of data transferred between the user and the Boundary targets. It is also important to consider bandwidth requirements to other external systems such as monitoring and logging collectors. It may be necessary to increase the size of the virtual machine to take advantage of additional throughput in certain circumstances. Refer to the following pages for provider-specific virtual machine networking limitations: - [AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html) - [Azure](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-machine-network-throughput/) - [GCP](https://cloud.google.com/compute/docs/network-bandwidth/) ## Network connectivity The following table outlines the default ingress network connectivity requirements for Boundary cluster nodes. If you restrict network egress, ensure you allow outgoing access from: - The Boundary controllers to any external integration providers (for example, OIDC authentication providers) as well as external log handlers, metrics collection, and security and configuration management providers. - The Boundary workers to controllers and any upstream workers. If any of the default port mappings do not meet your organization's requirements, you can update the default listening ports using the resource's [listener](/boundary/docs/monitor/listeners) stanza. ![Boundary network](/img/boundary-network.png) | Source | Destination | Default destination port | protocol | Purpose | | --------------- | --------------------------- | ------------------------ | --------- | -------------------------------------- | | Client machines | Controller load balancer | 443 | tcp | Request distribution | | Load balancer | Controller servers | 9200 | tcp | Boundary API | | Load balancer | Controller servers | 9203 | tcp | Health checks | | Worker servers | Controller load balancer | 9201 | tcp | Session authorization, credentials, etc | | Controllers | PostgreSQL | 5432 | tcp | Storing system state | | Client machines | Worker servers \* | 9202 | tcp | Session proxying | | Worker servers | Boundary targets\* | various | tcp | Session proxying | | Client machines | Ingress worker servers \*\* | 9202 | tcp | Multi-hop session proxying | | Egress workers | Ingress worker servers \*\* | 9202 | tcp | Multi-hop session proxying | | Egress workers | Boundary targets \*\* | various | tcp | Multi-hop session proxying | \* In this scenario, the client connects directly to one worker, which then proxies the connection to the Boundary target. ** Multi-hop sessions start reverse proxy tunnels when the downstream workers start and connect to upstream workers. There are four steps when a client requests to connect to a target that requires a multi-hop path: 1. The client connects to an ingress worker. 1. The ingress worker connects with the next-downstream or egress worker through that worker's established reverse-proxy tunnel. This step may be repeated multiple times if there are multiple worker connections in the middle of the tunnel chain. 1. The final downstream egress worker connects to the Boundary target. 1. The client can now send data through the tunnel chain. A multi-hop worker that acts as a downstream can start a tunnel to one or more upstream workers, specified in the `initial_upstreams` list in the worker configuration. ## Network traffic encryption You should encrypt connections to the Boundary control plane at the controller nodes using standard PKI HTTPS TLS. You can use either a layer 4 load balancer to pass through traffic to the Boundary controllers, or a layer 7 load balancer with no configured TLS termination. ## Database recommendations Boundary clusters depend on a PostgreSQL database for managing state and configuration. Ensure you are using a version of PostgreSQL covered under [Boundary's supported version policy](https://developer.hashicorp.com/boundary/docs/enterprise/supported-versions#postgresql-support-policy). Each major cloud provider offers a managed PostgreSQL database service: | Cloud provider | Managed database service | |----------------|-----------------------------------------------------------------------------------------| | AWS | [Amazon RDS for PostgreSQL](https://aws.amazon.com/rds/postgresql/) | | Azure | [Azure database for PostgreSQL](https://azure.microsoft.com/en-us/products/postgresql/) | | GCP | [Cloud SQL for PostgreSQL](https://cloud.google.com/sql/postgresql) | ### Database network requirements Boundary controllers must be able to reach the PostgreSQL database. Worker nodes do not need access to the database. ### Database users and roles Database initialization requires elevated privileges. When you initialize the database with the `boundary database init` command, the Boundary database user requires the `superuser` role plus `all privileges` on the Boundary database. Once the database initialization is complete, the database user for a Boundary controller requires permissions for [data manipulation](https://www.postgresql.org/docs/current/dml.html) operations (select, insert, update, and delete). ### Required PostgreSQL modules Boundary has a dependency on the PostgreSQL [pgcrypto](https://www.postgresql.org/docs/11/pgcrypto.html) module and [citext](https://www.postgresql.org/docs/11/citext.html), which are part of the standard modules supplied with PostgreSQL. Refer to the PostgreSQL documentation for more information. ## Load balancer recommendations For the highest levels of reliability and stability, we recommend that you use some load balancing technology to distribute requests to your Boundary controller nodes. Boundary workers do not require any load balancing. The Boundary controller manages load balancing for the Boundary workers when clients initiate sessions to Boundary targets. To monitor the health of Boundary controller nodes, configure the load balancer to poll the `/health` API endpoint to detect the status of the node and direct traffic accordingly. Each major cloud provider offers one or more managed load balancing services: | Cloud | Layer | Layer | Managing load balancing service | |-------|---------------------|-------|----------------------------------------------------------------------------------------------------------------| | AWS | Network | 4 | [Network load balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) | | AWS | Application | 7 | [Application load balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) | | Azure | Network | 4 | [Azure load balancer](https://learn.microsoft.com/en-us/azure/load-balancer/) | | Azure | Application | 7 | [Azure application gateway](https://learn.microsoft.com/en-us/azure/application-gateway/) | | GCP | Network/Application | 4/7 | [Cloud load balancing](https://cloud.google.com/load-balancing/docs/load-balancing-overview) | There are also a number of self-hosted options, as well as service discovery systems like Consul. Refer to the [listener stanza documentation](/boundary/docs/monitor/listeners/) for more information.