HashiCorp Archives Boundary CE: The Operational Playbook for Frozen Access Infrastructure

On October 8, 2026, HashiCorp archived the Boundary Community Edition repository. The README now reads like a hospice notice: no new CE releases, no maintenance updates, no bug fixes, no security patches. Future development moves to HCP Boundary and Boundary Enterprise, pitched as the place for "enterprise grade human and agentic access capabilities." A commercial v1.0.x line is now the docs' "latest" — past CE's terminal 0.21.3.

If you run Boundary CE today, you are running frozen software at the edge of your network, terminating human and machine sessions into production infrastructure, with no upstream patch channel. That is not a licensing nuance. That is an incident-response precondition, and this piece is the operational playbook for it: how the product got here (the arc is documented in the deprecation thread and its predecessor), what the freeze actually means technically, and what your exit options cost.

The Structural Shift: From Zero-Trust Darling to Enterprise-Only PAM

Boundary entered the world in 2020 as the zero-trust answer to bastion hosts and homegrown jump servers — an identity-aware proxy that brokered TCP/SSH sessions through short-lived, credentialed connections without installing agents on every host. The pitch was developer-first: kill the VPN, kill the jump box, give humans (and later, machines) time-boxed access to exactly the resources their role permitted. By 2022 it had a commercial launch (HCP Boundary, October 2022), and by the mid-2020s the positioning had drifted from "secure access" to enterprise PAM — privileged access management, the governance-and-compliance market where deals are bigger and procurement cycles are slower.

The drift became a rupture in three documented steps:

The BSL is the load-bearing fact here. Because CE 0.14+ is BSL-licensed, a community fork can never cleanly "save" Boundary the way OpenTofu forked Terraform: the BSL forbids a competing hosted/embedded offering while the grant lasts, and each version's Change Date is four years out. The Change License is MPL 2.0, so v0.14.0 flips to open in October 2027, v0.21.3 in April 2030 — a fork would have to rebuild on years-old code or negotiate separately. The community knows it: a Hacker News thread on the archive drew a pointed exchange where one commenter notes that "the license makes it radioactive," while others point out the Additional Use Grant explicitly permits internal production use. Both are right, which is exactly the trap.

The Irony: A PM Promised Patches for the Repo He Was Archiving

The archive did not come from nowhere. The long-term-scope thread reads like a slow-motion crash. In April 2026, a user evaluating Boundary for production asked whether CE features might migrate to paid tiers. In June, Boundary PM Dan Rohan answered with unusual honesty for a vendor forum: development focus is "fully on our Enterprise edition," and organizations evaluating Boundary for production should scope against Enterprise. In September, users noticed the release cadence had collapsed — v0.21.3 shipped April 30, 2026 and nothing followed. On September 28, product manager Anando Chatterjee wrote the now-infamous reassurance:

"So one might ask 'Hey, I am a small team of 10 developers - what about me?' Well, you are more than welcome to use Boundary CE as we will continue to support it with bug fixes and security patches. We also welcome community contributions to the CE repo."

On October 7, user mismithhisler replied that the repo was already archived and read-only — the promise had shipped dead. Two days later, on October 9, the official deprecation post landed, saying "this thread, amongst other factors" led to the review that ended CE. The deprecation post's own background section confirms the product's pivot: Boundary "quickly matured into a PAM solution" for "large enterprise organizations," and R&D now goes to "a market leading human and agentic privileged access solution."

For platform teams, the pattern is the lesson, not the vendor. A PM promising patches for a repo that was already frozen is not malice — it's what happens when the free tier stops being a strategic surface but still carries strategic expectations. Waypoint got the same treatment in January 2024 (archived, development redirected to HCP Waypoint), and Boundary got it with less ceremony. If your access layer depends on any vendor's community edition, the Boundary arc is your template for how the endgame plays out: a license flip, an acquisition, a cadence collapse, a reassurance, an archive.

The Frozen Surface: What You Are Actually Running

What does "archived" mean mechanically? The last CE release is v0.21.3, built April 28, 2026 (Git revision 8c9715c8). We downloaded the final binary from releases.hashicorp.com and ran it on this host during research:

Version information:
  Build Date:          2026-04-28T10:12:07Z
  Git Revision:        8c9715c868537616a11e0ea555b20042e212bdbc
  Version Number:      0.21.3

The build date is the entire story in four lines. Everything shipped after that — the July 2026 CVE-2026-41989 libgcrypt finding, any Go runtime CVEs disclosed since, any future protocol bugs — lands on a binary that will never be rebuilt. The Docker Hub hashicorp/boundary image's latest tag points at that same April 30 build. If your deployment pulls latest, it has been silently frozen since spring.

The CVE surface is already visible. The v0.21.1 security release (February 2026) was the last CE release that addressed a disclosed CVE chain — Go 1.25.7 for CVE-2025-61730, plus Go crypto fixes for CVE-2025-58181 and CVE-2025-47914. After that, the trail goes cold in a specific and citable way: commit 886cd291 (July 31, 2026) added CVE-2026-41989 — a libgcrypt ECDH heap buffer overflow, CVE-2026-41989 — to .release/security-scan.hcl not as a fix but as a suppression: "There is no fix available in the Alpine Docker image yet." The official advice in the deprecation thread is to "review the license file and take into consideration any bugs or open security vulnerabilities prior to continued use." The license file is reviewed above. The open security vulnerability is a real, disclosed, unpatched-in-dependency heap overflow that nobody will ever backport to CE.

Architectural Blueprint: What a Boundary Deployment Actually Is

Before you migrate, inventory. A Boundary deployment is a controller (state in Postgres), workers (session proxies), and four listener planes you must be able to account for on every host. The repo's own reference config (from the enos test modules) is the cleanest map:

# boundary controller config — four listener planes
disable_mlock = true

controller {
  name                = "boundary-controller"
  public_cluster_addr = "boundary:9201"
  database {
    url = "env://BOUNDARY_POSTGRES_URL"
  }
}

worker {  # collocated worker in the same process
  name = "boundary-collocated-worker"
  tags { type = ["k8s-worker"] }
}

listener "tcp" {
  address     = "0.0.0.0:9200"
  purpose     = "api"          # CLI + API clients authenticate here
  tls_disable = true           # terminate TLS at the LB in front
}

listener "tcp" {
  address     = "0.0.0.0:9201"
  purpose     = "cluster"      # controller↔worker control channel
  tls_disable = true
}

listener "tcp" {
  address     = "0.0.0.0:9202"
  purpose     = "proxy"        # session traffic: humans/agents dial in here
  tls_disable = true
}

listener "tcp" {
  address     = "0.0.0.0:9203"
  purpose     = "ops"          # /health + /metrics (promhttp) live here
  tls_disable = true
}

The port map is the blast-radius inventory: 9200 API (authentication, resource CRUD), 9201 cluster (controller-worker gossip), 9202 proxy (the actual session traffic to targets), 9203 ops (health and Prometheus metrics — we verified the ops mux serves /health and /metrics via promhttp, with pprof behind the debug flag in internal/cmd/ops/server.go). Every one of those four planes is now a frozen attack surface with no patch channel.

                    +---------------------------+
                    |  Boundary (CE 0.21.3, frozen) |
                    |                           |
+---------+        |  +-------+   +---------+  |        +---------------------------+
| Human   | -----> |  | API   |   | Worker  |  | -----> | Target infrastructure     |
| CLI     | :9200  |  | :9200 |   | :9202   |  |  SSH   | (hosts, DBs, k8s, clouds) |
+---------+        |  +-------+   +---------+  |        +---------------------------+
                   |  controller   proxy plane |
                   +---------------------------+

Inventory commands, captured live from the final binary (real output, real error shapes — these are the strings your automation should match):

export BOUNDARY_ADDR="https://boundary.example.com:9200"
boundary scopes list -format json            # inventory org/project scopes
boundary targets list -scope-id <id> -format json  # tcp/ssh targets + their host sets
boundary sessions list -format json         # active session count (your exposure)
boundary host-catalogs list -format json    # what CE can reach

# without a token, the CLI fails like this (captured):
# Token must be provided via BOUNDARY_TOKEN env var or -token flag.
# Reading the token can also be disabled via -keyring-type=none.
# base.ReadTokenFromKeyring: failed to open keyring: Specified keyring backend not available
# {"error":"Error trying to list scopes: error performing client request during
#  List call: Get \"https://127.0.0.1:9200/v1/scopes?scope_id=global\":
#  dial tcp 127.0.0.1:9200: connect: connection refused"}

Note the API shape in that error: /v1/scopes?scope_id=global is the root listing call; session authorization posts to /v1/targets/<id>:authorize-session. If you are scripting a migration export, those are the endpoints to walk. And note the keyring error: on headless hosts, -keyring-type=none plus BOUNDARY_TOKEN is the only workable auth mode for automation — the default keyring backend will not exist on your Linux servers.

The Runbook: Contain, Export, Decide

There is no upgrade path from CE 0.21.3. There is only a migration path to something else, and the first move is pinning and inventorying what you have.

1. Pin and freeze deliberately. Stop pulling latest from Docker Hub — it is frozen anyway, but pin it explicitly so nobody re-pins it to a commercial or unofficial rebuild by mistake. Pin the version you actually run:

# Docker pin (avoid 'latest' — it is frozen at 2026-04-30 and unmanaged)
docker pull hashicorp/boundary:0.21.3

# Binary pin with checksum verification (we verified this SHA on 2026-10-12)
curl -sL -o boundary.zip \
  https://releases.hashicorp.com/boundary/0.21.3/boundary_0.21.3_linux_amd64.zip
echo "1a948c143b849cedba91127aa11155c6006d84051282a0d93f3d89525b460d12  boundary.zip" | sha256sum -c -
unzip boundary.zip && sudo install -m 0755 boundary /usr/local/bin/

2. Export your access model before you lose the CLI that reads it. The CLI that talks to v0.x controllers is still on your machines and still works — but build your export now, while the v0.21.x docs and the binary agree with each other. Walk scopes → auth methods → roles → targets → host catalogs, JSON each level to durable storage. Your users, groups, and managed groups are the expensive part to rebuild; targets and host sets are usually re-creatable from IaC.

3. Watch the frozen surface. Until you migrate off, the ops listener is your only monitoring plane — it will never gain new metrics, but the ones it has are the ones that matter for a frozen deployment:

# scrape the ops listener (verified in source: /health + /metrics via promhttp)
curl -s http://boundary-ops.internal:9203/health
curl -s http://boundary-ops.internal:9203/metrics | grep -c '^boundary_'

# black-box alerts that do not depend on Boundary's own series:
#  - /health probe fails or latency regresses
#  - active session count from GET /v1/sessions spikes off-hours
#  - API 5xx rate on :9200 exceeds baseline
#  - CVE feed matches 'boundary OR libgcrypt' (the frozen dependency set)
#  - Docker image digest for this workload changes (it never should)

4. Decide within your compliance window. The deprecation notice's actual instruction — "evaluate whether it meets your operational, security, and compliance requirements" — is a deadline generator, not a suggestion. If your org has any pen-test or audit cadence, the finding "remote-access broker with disclosed unpatched dependency CVE and no vendor patch channel" writes itself. Plan the exit on that cadence, not on hope.

Where to Migrate: The Honest Option Set

Boundary's category is identity-aware access / PAM-adjacent. Your options, with licenses and states verified this week:

A note on staying: the BSL Additional Use Grant explicitly permits internal production use of 0.21.3, so running frozen CE is legal. The HashiCorp BSL FAQ is the binding interpretive guidance. Legal-to-run and safe-to-run are different questions, and the second one has only one answer for a network-edge access broker.

Day-2 Warnings

The Docker tag trap. hashicorp/boundary:latest and the 0.21.x tags froze April 30, 2026. If your deploy pipeline uses a mutable tag, someone will eventually "fix" it by pointing at the commercial image or an unofficial rebuild — either of which changes behavior under you. Pin the digest, not the tag, and alert on any image mutation for this workload.

The monitoring surface is now frozen too. Whatever your dashboards read from :9203/metrics today is all they will ever read — no future release will add instrumentation, and none of the existing series will gain labels or fixes. Do a one-time audit: list the series you actually scrape, confirm your health probe hits the real /health endpoint, and record the current session/worker counts as your baseline, because drift from that baseline is now your only anomaly signal.

The keyring-on-headless-hosts gotcha. Automation against a Boundary controller needs -keyring-type=none and BOUNDARY_TOKEN; the default keyring backend fails on headless Linux (captured above). Bake that into your export scripts before you discover it during the actual migration weekend.

Blast radius. A Boundary compromise is not one box: the proxy plane (9202) terminates sessions into every target it catalogs, and the API plane (9200) holds the auth methods and roles that decide who gets those sessions. Treat the frozen deployment as a long-lived privileged credential store that also terminates network access, and put it on the same review cadence as your bastion hosts — because that is what it is now, minus the patches.

Who should skip this migration entirely. If you only ever used Boundary for lab access or a handful of static SSH targets, do not buy a PAM suite — a short-lived-certificate design (smallstep or even plain SSH CA) covers that with less surface. The migration is mandatory for teams using Boundary's governance features in regulated environments; for everyone in between, the honest sequencing is: pin, export, monitor, then decide on your audit calendar, not the vendor's.

References & Further Reading

• hashicorp/boundary — the archived repository, README notice, and final CE source (v0.21.3)
• HashiCorp Discuss: Deprecation of Boundary Community Edition — the official announcement thread
• HashiCorp Discuss: Boundary CE long-term scope — the thread that preceded and triggered the deprecation
• Boundary documentation — v0.21.x reference (CE) and v1.0.x (commercial latest)
• HashiCorp Business Source License FAQ — the binding interpretive guidance for BSL use rights
• Hacker News discussion of the archive — community reaction, migration options, license debate
• hashicorp/waypoint — the January 2024 archive precedent for HashiCorp community editions
• IBM newsroom: acquisition completion — the corporate context behind the Boundary pivot
• Teleport · Pomerium · Infisical · smallstep — the migration option set, verified live this week