System requirements

This topic contains specific recommendations for system requirements.

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

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

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.

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

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

Each major cloud provider offers a managed PostgreSQL database service:

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 operations (select, insert, update, and delete).

Required PostgreSQL modules

Boundary has a dependency on the PostgreSQL pgcrypto module and citext, 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:

There are also a number of self-hosted options, as well as service discovery systems like Consul.

Refer to the listener stanza documentation for more information.