Outside of development mode, Boundary controllers and workers are configured using a file. The format of this file is HCL. In this section you'll find configuration block examples for Boundary controllers and workers.
After the configuration is written, use the
-config flag to specify a local path to the file.
controller: Controller specific configuration. If present,
boundary serverwill start a Controller subprocess.
worker: Worker specific configuration. If present,
boundary serverwill start a Worker subprocess.
listener: Configures the listeners on which Boundary serves traffic (API, cluster, and proxy).
Controllers must have at least two listener blocks defined: one marked for
apipurpose and the other marked for
Workers will have only one listener, marked for
opspurpose listener block serves as a higher-level listener where Boundary's operational endpoints live (eg: /health).
plugins: Configures options for plugins.
(bool: false)– Disables the server from executing the
mlocksyscall, which prevents memory from being swapped to disk. This is fine for local development and testing; in production, it is not recommended unless the systems running Boundary only use encrypted swap or do not use swap at all. Boundary only supports memory locking on UNIX-like systems that support the mlock() syscall (Linux, FreeBSD, etc).
On Linux, to give the Boundary executable the ability to use the
mlocksyscall without running the process as root, run:
sudo setcap cap_ipc_lock=+ep $(readlink -f $(which boundary))
If you use a Linux distribution with a modern version of systemd, you can add the following directive to the "[Service]" configuration section:
(string: "info")– Specifies the log level to use; overridden by CLI and env var parameters. Supported log levels: Trace, Debug, Error, Warn, Info.
(string: "")– Specifies the log format to use; overridden by CLI and env var parameters. Supported log formats: