System requirements

This topic contains specific recommendations for system requirements. Since every hosting environment is different, and every customer's Boundary usage profile is different, the following recommendations should only serve as a starting point from which your operations staff may observe and adjust to meet the unique needs of each deployment.

To match your requirements and maximize the stability of your Boundary controller and worker instances, it's important to ensure that you perform load tests and continue to monitor resource usage as well as all reported matrices from Boundary's telemetry.

Refer to Maintaining and operating Boundary 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

Worker nodes

For each cluster size, the following table gives recommended hardware specifications for each major cloud infrastructure provider.

To help ensure predictable performance on cloud providers, we recommend that you avoid "burstable" CPU and storage options (such as AWS t2 and t3 instance types) whose performance may degrade rapidly under continuous load.

Hardware considerations

The Boundary controller and worker nodes perform two very different tasks. The Boundary controller nodes handle requests for authentication and configuration, among other tasks. The Boundary worker nodes are used to proxy client connections to Boundary targets and thus may require additional resources.

Depending on the number of clients connecting to Boundary targets at any given time, Boundary workers could become memory or file descriptor constrained. As new sessions are created on the Boundary worker node, additional sockets and ultimately file descriptors are created. It is imperative to 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. With regards to Boundary controllers, even a high request volume does not necessarily translate to a large amount of network bandwidth consumption. However, Boundary worker nodes proxy client sessions to Boundary targets, so the bandwidth consumption is highly dependent on the amount of potential clients, the number of sessions being created, and the amount of data being transferred in either direction to and from the Boundary targets.

It is also important to consider bandwidth requirements to other external systems such as monitoring and logging collectors. It is imperative to monitor the networking metrics of the Boundary workers, to avoid situations where the Boundary workers can no longer initiate session connections.

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
• Azure
• GCP

Network connectivity

The following table outlines the default ingress network connectivity requirements for Boundary cluster nodes. If general network egress is restricted, you must pay particular attention to granting 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.

* In this scenario, the client connects directly to one worker, which then proxies the connection to the Boundary target.

** Multi-hop sessions use reverse proxy tunnels that are initiated 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.

2. 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.

3. The final downstream egress worker connects to the Boundary target.

4. The client can now send data through the tunnel chain.

A multi-hop worker that acts as a downstream can initiate a tunnel to one or multiple 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. This also means that you can use a simple 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.

Each major cloud provider offers a managed PostgreSQL database service:

Database network requirements

Boundary controllers must be able to reach the PostgreSQL database. If you use a high availability (HA) configuration, then the controllers must have access to the PostgreSQL server infrastructure. In non-HA configurations, the Boundary servers must have access. Worker nodes never need access to the database.

Database users and roles

After the database has been initialized, the database user for a Boundary controller requires only permissions for data manipulation operations (select, insert, update, and delete).

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.

Required PostgreSQL modules

Boundary has a dependency on the PostgreSQL pgcrypto module and citext, which are part of the standard modules that are 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. Each major cloud platform provides good options for managed load balancer services. There are also a number of self-hosted options, as well as service discovery systems like Consul.

To monitor the health of Boundary controller nodes, you should configure the load balancer to poll the /health API endpoint to detect the status of the node and direct traffic accordingly.

Refer to the listener stanza documentation for more information.

Each major cloud provider offers one or more managed load balancing services:

Boundary workers do not require any load balancing. Load balancing for the Boundary workers is handled by the Boundary controllers when clients initiate sessions to Boundary targets.