Cloud Parts

HashiCorp Boundary

An identity-aware proxy: users sign in once and get one proxied session to one private host or database, with credentials fetched per session.

Type
Commercial product
Made by
HashiCorp, an IBM company
License
Business Source License 1.1 since 0.14 (source-available, not OSI open source); MPL 2.0 before the August 2023 change
Facts checked
5 October 2026

What it is

Boundary is a single Go binary that runs as a controller, a worker, or both. Controllers serve the API and admin UI, log users in through OIDC, LDAP or password auth methods, check their roles, and keep all configuration and session state in PostgreSQL. They don’t talk to each other, so you run several behind a load balancer. Workers carry the traffic. When a user picks a target (a host and port they are allowed to reach), the Boundary CLI or Desktop app opens a local port, and the connection runs from there to an ingress worker, through any intermediate workers, to an egress worker that can reach the target. Downstream workers dial out to the worker above them, so a chain can cross firewalls that allow no inbound traffic. Nothing is installed on the targets. Hosts can be listed by hand or synced from AWS, Azure or Google Cloud by tag or label with dynamic host catalogs.

Credentials come from credential stores: Boundary’s own static store or HashiCorp Vault. With brokering, the controller fetches a credential when the session starts, for example a fresh PostgreSQL user from Vault’s database engine, and hands it to the user; it is revoked when the session ends. With injection, the worker logs in to an SSH or RDP target on the user’s behalf, so the user never sees the credential, and the worker can record the session to an S3-compatible bucket. Every session has a maximum duration, and a target can cap how many connections it allows. Injection, multi-hop chains and transparent sessions need HCP Boundary or Boundary Enterprise, and recording needs HCP Boundary Plus or Enterprise. HashiCorp moved Boundary from MPL 2.0 to the Business Source License with version 0.14 in 2023, and Boundary 1.0 (June 2026) ships only as Enterprise builds and in HCP; the free Community Edition’s latest release is 0.21.3.

Why teams pick it

  • Users get a proxied connection to one target, not a route into the network, and use their usual clients (ssh, psql, kubectl, RDP)
  • With Vault, each session can get its own short-lived database user or SSH certificate that is revoked when the session ends
  • Dynamic host catalogs pick up new EC2, Azure and Compute Engine machines by tag or label, with no agent on the hosts
  • Controllers are stateless on top of PostgreSQL, and everything can be configured through a Terraform provider

Watch out for

  • No longer OSI open source, and the free Community Edition has stayed on the 0.21 line while 1.0 ships only to HCP and Enterprise
  • Much of what sets it apart is paid: credential injection, SSH and RDP targets, multi-hop workers and transparent sessions need HCP or Enterprise; session recording needs HCP Plus or Enterprise
  • Self-managed means running controllers, workers, PostgreSQL, a KMS and TLS; HCP Boundary hosts the control plane, but you still run workers inside private networks
  • Brokered credentials are shown to the user, and TCP targets such as databases can only use brokering
  • Permissions are checked only when a session starts; removing a role doesn’t end live sessions until they expire or someone cancels them

Alternatives

What all remote access have in common →

How it fits with other technologies

A PostgreSQL target with hosts synced from AWS and per-session users from Vault · hcl

resource "boundary_host_catalog_plugin" "aws" {
  scope_id        = boundary_scope.project.id
  plugin_name     = "aws"
  attributes_json = jsonencode({
    region                      = "eu-west-1"
    role_arn                    = "arn:aws:iam::123456789012:role/boundary-discovery"
    disable_credential_rotation = true
  })
}
resource "boundary_host_set_plugin" "orders_db" {
  host_catalog_id = boundary_host_catalog_plugin.aws.id
  attributes_json = jsonencode({ filters = ["tag:service=orders-db"] })
}
resource "boundary_credential_store_vault" "vault" {
  scope_id = boundary_scope.project.id
  address  = "https://vault.internal:8200"
  token    = var.vault_token # periodic token Boundary keeps renewed
}
resource "boundary_credential_library_vault" "analyst" {
  credential_store_id = boundary_credential_store_vault.vault.id
  path                = "database/creds/analyst" # Vault creates a new DB user
  credential_type     = "username_password"
}
resource "boundary_target" "orders_db" {
  name                           = "orders-db"
  type                           = "tcp"
  scope_id                       = boundary_scope.project.id
  default_port                   = 5432
  session_max_seconds            = 3600
  host_source_ids                = [boundary_host_set_plugin.orders_db.id]
  brokered_credential_source_ids = [boundary_credential_library_vault.analyst.id]
  egress_worker_filter           = "\"eu-west-1\" in \"/tags/region\""
}
# Then: boundary connect postgres -target-name orders-db -target-scope-name prod -dbname orders

Community, HCP and Enterprise#

The same CLI and Desktop client work with every edition. What differs is who runs the control plane, which version you get, and which features unlock.

FeatureCommunityHCP BoundaryEnterprise
Control planeYou run itHashiCorp runs it; you run workers for private networksYou run it
Latest version0.21.3 (April 2026)1.0.x1.0.x
LicenceBUSL 1.1, freeHashiCorp-hosted service (Standard and Plus tiers)Commercial licence
TCP targets, OIDC and LDAP login, brokered credentialsYesYesYes
Dynamic host catalogs (AWS, Azure, Google Cloud)YesYesYes
SSH and RDP targets with credential injectionNoYesYes
Multi-hop worker chainsNoYesYes
Transparent sessions (Client Agent)NoYesYes
Session recording and playbackNoPlus onlyYes
  • Community features are taken from the 0.21.x docs, the last line that ships a Community build; releases.hashicorp.com lists 1.0.0 to 1.0.2 only as +ent builds.

Other ways to do the same job#

AWS Session Manager and EC2 Instance Connect Endpoint

AWS only

Shell and port forwarding to instances without inbound ports or public IPs, controlled by IAM, with no extra servers to run. Session Manager can log sessions to S3 or CloudWatch.

Google Identity-Aware Proxy

Google Cloud only

Checks IAM before tunnelling TCP to a VM with no external IP; OS Login maps SSH access to IAM instead of copied keys.

Azure Bastion

Azure only

A managed service in your virtual network that gives RDP and SSH over TLS to VMs that have no public IP.

Teleport

AGPL source

Similar identity-aware proxy with a certificate authority for short-lived certificates. The source is AGPL-3.0, but the Community Edition binaries are licensed only to companies under 100 employees and $10M revenue.

OpenSSH bastion with `ProxyJump`

free

One hardened jump host and ssh -J. Simple and fully open source, but users reach the network, keys are long-lived, and auditing is up to you.

See it in a real stack

No architecture uses HashiCorp Boundary yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2020–2026

By 2020 the usual way to reach private servers was an SSH bastion host or a VPN. In HashiCorp’s announcement, engineer Jeff Mitchell listed the problems: once users are on these private networks they can access any system, not just the one they need; if the VPN or SSH credentials are lost or stolen, the whole network is exposed; and the approach suits static data centres badly, not clouds where hosts come and go all the time. Patching over it with internal firewall rules was, in his words, time consuming and wasteful.

HashiCorp announced Boundary on October 14, 2020, the day it tagged version 0.1.0. Access would be decided by identity at the application layer: users authenticate to Boundary, and workers proxy a session to one target, with no agent on the hosts. In 2021 Boundary gained credential stores, starting with Vault, so a session could get its own leased credential that Boundary revokes at the end, and dynamic host catalogs that discover AWS and Azure machines.

Later features went mostly to HCP and Enterprise: multi-hop worker chains in January 2023 (HCP only at first) and SSH session recording in June 2023. Boundary moved to the Business Source License from version 0.14, IBM completed its purchase of HashiCorp in 2025, and Boundary 1.0 arrived in June 2026 with RDP session recording, released only for HCP and Enterprise. HashiCorp now pitches it as the gate for AI agents that need infrastructure access.

Why it’s built this way

Proxy single sessions instead of granting network access
A VPN or bastion puts users on a network where they can reach any system. Proxying one connection to one authorized target keeps the rest of the network out of reach, even with a stolen login.
Split controllers from workers
Controllers handle the API, logins and permissions, while workers sit next to the targets and only move traffic. Workers can live inside private networks and dial out, and stateless controllers share one PostgreSQL database.
No agent on the target hosts
Managed databases, cloud services and short-lived containers can’t always run an agent. Proxying at the network level means anything with an address and port can be a target.
Fetch credentials from Vault per session
Rather than storing passwords itself, Boundary asks Vault for a credential when the session starts and revokes it when the session ends, so each session gets its own short-lived login.

Timeline

  1. 2020

    Announced on October 14, the same day as the 0.1.0 release

  2. 2021

    Vault credential stores in June; AWS and Azure host discovery in November

  3. 2023

    Multi-hop workers in January and SSH session recording in June, not in Community

  4. 2023

    Version 0.14 in October is the first under the Business Source License

  5. 2025

    IBM completes its acquisition of HashiCorp

  6. 2026

    Boundary 1.0 in June, released only for HCP and Enterprise

Sources35 · facts checked 5 October 2026

Improve this page on GitHub