HashiCorp Boundary: identity-based access to hosts without agents

What Boundary solves, and for whom

Most access tooling assumes you can install something on the machine you want to reach. Boundary takes the opposite position. The README states plainly that Boundary does not require software to be installed on your hosts and services. Instead it sits between the user and the target as an identity-aware proxy, and the README describes it as providing "a simple, secure way to access hosts and critical systems on your network."

The audience is operations and security teams managing a mixed estate: cloud instances, on-prem servers, container-based workloads, managed services. The README lists the intended capabilities directly: OpenID Connect integration with an identity provider, just-in-time network access to resources wherever they reside, session credentials either from a static credential store or generated per-session through HashiCorp Vault, automated discovery of new endpoints, session controls for privileged work, and one consistent access workflow across providers.

That last item is the real pitch. If your engineers currently reach different infrastructure through different mechanisms, Boundary's value is uniformity of the access path, not any single feature. If you only have one environment and one access method that already works, the case is much weaker.

Controllers, workers, and where sessions actually terminate

Boundary ships as two server roles in one binary. The README describes the Controller as the component that serves the API and coordinates session requests, and Workers as the components that perform session handling. A single binary can act in either role or both. A production installation, per the README, will likely be one or more controllers paired with one or more workers.

That split is the architectural decision worth understanding. Clients authenticate to the controller and request a session; the worker is what handles the session itself. Because the worker does the session handling and no agent sits on the target, the worker is the component that must be able to reach your resources. This is why worker placement matters more than controller placement in a segmented network: a worker in the wrong network zone is useless, while an extra controller is mostly a capacity and availability question.

Boundary also provides a Desktop client and a CLI for end users to request and establish authorized sessions. The README notes that it can run in clouds, on-prem, and secure enclaves. The dependency list in go.mod reflects a gRPC core with an HTTP gateway in front of it, which is consistent with the README's statement that the controller serves the API while the CLI and Desktop client are the user-facing entry points.

The two external dependencies you cannot skip

Boundary has exactly two external dependencies, and both are mandatory. The first is a SQL database. The README says the database holds Boundary's configuration and session information, that controller nodes must be able to reach it, and that values which are secrets, such as credentials, are encrypted in the database. PostgreSQL is the supported database, tested with Postgres 12 and above. The README adds that Boundary uses only common extensions and that both hosted and self-managed instances work, so in most cases a database endpoint plus credentials is all you need.

The second is a KMS. Boundary uses KMS keys for protecting secrets, authenticating workers, recovering data, and encrypting values in Boundary's own configuration. The README notes that Boundary uses key derivation extensively to avoid key sprawl of these high-value keys. You can satisfy this with any cloud KMS or with Vault's Transit Secrets Engine.

This is the constraint that decides whether Boundary is practical for you. A team without a cloud KMS and without Vault has to stand one up first. A team whose database platform is MySQL or SQL Server is not supported here. Neither of those is a defect in Boundary; it is simply the shape of the product, and it should be settled before any evaluation effort.

Installing Boundary and running a first session

The README points to a downloads page for the server binary and the desktop clients, and to an installation guide for permanent deployments. For a first look, dev mode is the intended path. It starts a controller and a worker with one command, and the README states that in dev mode the controller starts a PostgreSQL Docker container for storage and uses an internal KMS with ephemeral keys. The container is shut down and removed when the controller is stopped gracefully.

If you prefer to build from source, the README lists the local requirements: Go v1.21 or greater, Docker, and either the Boundary UI dependencies or the gh CLI for downloading pre-built UI assets. The build and install step is:

make install

The README notes that the first run fetches and compiles UI assets and takes a few extra minutes. It also warns that you may hit errors without first installing the pinned tool set, which installs into the normal Go binary directory and can take precedence over tools already on the system:

make tools

With the binary in place, start dev mode:

$GOPATH/bin/boundary dev

The README states this starts a Controller listening on http://127.0.0.1:9200 for API requests and a Worker listening on http://127.0.0.1:9202 for session requests, and prints a login name and password you can use to authenticate. It also creates default resources: the global scope with a Password-type auth method and an account, an organization scope beneath global, and a project scope inside that organization. That printed output is what you should read first, because it is the resource hierarchy you will recreate deliberately in production.

Where Boundary is the wrong tool

Boundary is not a substitute for host-level controls. Because nothing is installed on the target, Boundary cannot enforce policy inside the host, cannot inspect what a user does after a session is established beyond its own session controls, and cannot remediate a compromised host. It governs the path to the resource, not the resource.

The dev mode is also easy to misread. Its PostgreSQL container and its internal KMS with ephemeral keys exist for testing. Nothing about that setup carries into a permanent installation, where you write configuration files telling nodes how to reach their database and KMS. Treating dev mode as a deployment model is a mistake the README preempts by calling it a way to test.

Finally, the README carries an explicit warning about the main branch: do not use it except for dev or test cases, because migrations in main may be renumbered, and the Boundary team states it will not be able to assist if running main long term causes migration breakages. If your team tracks main for infrastructure software, that habit is incompatible with this project.

How this compares with a mesh-based access proxy

The closest alternative approach is an identity-aware access proxy built on a service mesh or on per-host agents. The difference is where the software runs. Agent-based models put a component on or beside every host and service, which gives them local visibility and lets them enforce policy at the workload. Boundary explicitly does not require that, which is what makes it suitable for managed cloud services and container workflows where you cannot install anything, and for estates where the cost of deploying and upgrading an agent everywhere is the reason access management never gets finished.

The trade is reachability. An agent-based model can often reach a host from the inside; Boundary's workers must be able to reach the targets from wherever they are deployed, so network placement becomes your responsibility. Boundary's compensating design is its scope hierarchy, the global, organization and project scopes that dev mode creates by default, which is how access is organized rather than configured per host. If your estate is small and uniform, or if you already have a working agent-based setup, the operational cost of controllers, workers, a database and a KMS is hard to justify.

Maintenance, releases and licensing

The repository is not archived, and the last push was on 2026-09-22. Recent releases listed are v0.21.3, v0.20.3 and v0.19.5, all dated 2026-04-30. That pattern matters more than any single version number: three parallel minor lines receiving releases on the same day indicates maintained release branches rather than a single moving target, which is consistent with the README's note that release branches were introduced at Boundary 0.10 and should be safe to track. The practical upgrade cost is therefore not the binary but the database migrations, which are the exact thing the README warns can be renumbered on main.

Licensing needs care. The repository's licence field reports NOASSERTION, meaning the licence could not be classified automatically. The Dockerfile carries the label org.opencontainers.image.licenses="BUSL-1.1" and its header comment reads SPDX-License-Identifier: BUSL-1.1. The Business Source License is not an open source licence in the usual sense and carries use restrictions that vary by version. Read the LICENSE file in the repository and confirm the terms for your intended use before deploying; this article is not legal advice, and the label in a Dockerfile is not a substitute for the licence text.

Editorial conclusion

Adopt Boundary if you already run PostgreSQL and a KMS and want session brokering that leaves target hosts untouched; skip it if you expected a single binary with no external dependencies or if your access problem is really about per-host agents. Before committing, verify two things against your own environment: that your PostgreSQL version is 12 or above, and that the KMS you intend to use is one Boundary documents for worker authentication and secret protection. Then run `boundary dev` once and inspect the resources it creates, because that layout is the model you will rebuild by hand in production.

Frequently asked questions

Official sources

1. hashicorp/boundary on GitHub
2. Issues
3. Project website
4. README
5. Releases