docs: Migrate link formats (#2777)

* Adding docs-content-check-legacy-links-format workflow * Adding test-link-rewrites workflow * Migrating links to new format
2023-01-20 15:17:34 -08:00
1 parent 87b09d5e27
commit e6be6431b2
@@ -0,0 +1,17 @@
+name: Legacy Link Format Checker
+
+on:
+  push:
+    paths:
+      - "website/content/**/*.mdx"
+      - "website/data/*-nav-data.json"
+
+jobs:
+  check-links:
+    uses: hashicorp/dev-portal/.github/workflows/docs-content-check-legacy-links-format.yml@d7c2fceac2dc41e3f857f1ce7c344141fd6a13dd
+    with:
+      repo-owner: "hashicorp"
+      repo-name: "boundary"
+      commit-sha: ${{ github.sha }}
+      mdx-directory: "website/content"
+      nav-data-directory: "website/data"
@@ -0,0 +1,16 @@
+name: Test Link Rewrites
+
+on: [deployment_status]
+
+jobs:
+  test-link-rewrites:
+    if: github.event.deployment_status.state == 'success'
+    uses: hashicorp/dev-portal/.github/workflows/docs-content-link-rewrites-e2e.yml@2aceb60125f6c15f4c8dbe2e4d79148047bfa437
+    with:
+      repo-owner: "hashicorp"
+      repo-name: "boundary"
+      commit-sha: ${{ github.sha }}
+      main-branch-preview-url: "https://boundary-git-main-hashicorp.vercel.app/"
+      # Workflow is only intended to run for one single migration PR
+      # This variable does not need to be updated
+      pr-branch-preview-url: "https://boundary-git-docs-ambmigrate-link-formats-hashicorp.vercel.app/"
@@ -9,11 +9,11 @@ description: |-

 Boundary's API is a JSON-based HTTP API that adheres to a set of standards that are rigidly followed. At its core, it is a standards-compliant JSON API for both input and output.

-Before reading this page, it is useful to understand Boundary's [domain model](/docs/concepts/domain-model) to be aware of the terminology used here.
+Before reading this page, it is useful to understand Boundary's [domain model](/boundary/docs/concepts/domain-model) to be aware of the terminology used here.

 Boundary's API is also described via OpenAPI v2; the version corresponding to any tag of Boundary's source code can be found in Boundary's [GitHub repository](https://github.com/hashicorp/boundary/blob/main/internal/gen/controller.swagger.json).

-> **NOTE:** A rendered version of this generated API definition can be found on the [API page](/api-docs).
+-> **NOTE:** A rendered version of this generated API definition can be found on the [API page](/boundary/api-docs).

 Boundary's current API version is 1; all API paths begin with `/v1/`.

@@ -23,12 +23,12 @@ Below is the typical structure for most Boundary CLI commands:
 boundary <command> <subcommand> [options] [args]
 ```

- `options` - [Client](/docs/api-clients/cli#client-options) and [connection](/docs/api-clients/cli#connection-options) options to specify additional settings
+- `options` - [Client](/boundary/docs/api-clients/cli#client-options) and [connection](/boundary/docs/api-clients/cli#connection-options) options to specify additional settings
 - `args` - API arguments specific to the operation

 #### Examples:

-The following shows use of the [`-addr`](/docs/api-clients/cli#addr) flag to specify which Boundary controller to send the request to.
+The following shows use of the [`-addr`](/boundary/docs/api-clients/cli#addr) flag to specify which Boundary controller to send the request to.

 ```shell-session
 $ boundary authenticate password \
@@ -14,7 +14,7 @@ using your favorite tooling!

 ## Getting Started

-> If you're running Boundary for the first time, [download the latest binary](https://www.boundaryproject.io/downloads)
+-> If you're running Boundary for the first time, [download the latest binary](/boundary/downloads)
 and run it in `dev` mode locally so you can have a server to run against:

 ```shell-session
@@ -13,7 +13,7 @@ Below, an example walks through using the SDK to authenticate against an auth me

 ## Authenticating to Boundary with the Go SDK

-Authenticating to Boundary starts with an [Auth Method](/docs/concepts/domain-model/auth-methods). An auth method provides
+Authenticating to Boundary starts with an [Auth Method](/boundary/docs/concepts/domain-model/auth-methods). An auth method provides
 the basic identity delegation needed for Boundary to generate a token for a client. There are two primary methods for
 authenticating to Boundary:

@@ -28,7 +28,7 @@ This is the most common way for a client to authenticate to Boundary. To demonst
 use the [authmethods](https://github.com/hashicorp/boundary/tree/main/api/authmethods) library to generate
 a valid token for a client in Go.

-For this example, we're going to use the [password auth method](/docs/concepts/domain-model/auth-methods#password-auth-method-attributes). This example
+For this example, we're going to use the [password auth method](/boundary/docs/concepts/domain-model/auth-methods#password-auth-method-attributes). This example
 assumes there's already a valid user and an associated account in Boundary
 against which the client can authenticate. To simplify this example, we're
 assuming you're running a Boundary instance in dev mode, where the default auth
@@ -132,7 +132,7 @@ client.SetToken(fmt.Sprint(authenticationResult.Attributes["token"]))
 ### Recovery KMS Workflow

 The recovery KMS workflow allows you to use a valid [KMS
-configuration](/docs/configuration/kms) to authenticate and authorize calls
+configuration](/boundary/docs/configuration/kms) to authenticate and authorize calls
 within the Boundary API. For this example, we're going to assume you've read the
 above and know how to get a base Boundary API client.

@@ -6,6 +6,6 @@ description: Common workflows for Boundary

 # Common Workflows

-This section covers common workflows for managing targets, identities, and sessions within Boundary. This section assumes you've already covered the [Getting Started](/docs/getting-started) section and are familiar with basic Boundary knowledge. This section extends Getting Started by showing how to accomplish common workflows in the admin console, the command line, and with our [Terraform provider](https://github.com/hashicorp/terraform-provider-boundary).
+This section covers common workflows for managing targets, identities, and sessions within Boundary. This section assumes you've already covered the [Getting Started](/boundary/docs/getting-started) section and are familiar with basic Boundary knowledge. This section extends Getting Started by showing how to accomplish common workflows in the admin console, the command line, and with our [Terraform provider](https://github.com/hashicorp/terraform-provider-boundary).

-For more detailed guides on using Boundary please consult our [Learn site](https://learn.hashicorp.com/boundary).
+For more detailed guides on using Boundary please consult our [Learn site](/boundary/tutorials).
@@ -6,7 +6,7 @@ description: How to manage Roles and Permissions

 # Manage Roles and Permissions

-[Roles](/docs/concepts/domain-model/roles) in Boundary manage the permissions given to principals ([Users](/docs/concepts/domain-model/users)/[Groups](/docs/concepts/domain-model/groups)). Roles can be defined at the global, org, or project scopes.
+[Roles](/boundary/docs/concepts/domain-model/roles) in Boundary manage the permissions given to principals ([Users](/boundary/docs/concepts/domain-model/users)/[Groups](/boundary/docs/concepts/domain-model/groups)). Roles can be defined at the global, org, or project scopes.

 In this example, we're going to show you how to create a role in Boundary, assign that roles grants, and assign principals to the role.

@@ -132,7 +132,7 @@ resource "boundary_scope" "role" {

 # Assign Grants to a Role

-Grants describe the actions that the principals should be allowed to perform. For more information on how to format grants see [Permission Grant Formats](https://boundaryproject.io/docs/concepts/security/permissions#permission-grant-formats).
+Grants describe the actions that the principals should be allowed to perform. For more information on how to format grants see [Permission Grant Formats](/boundary/docs/concepts/security/permissions#permission-grant-formats).
 In this example we give a role read and list permissions to all resources.

 <Tabs>
@@ -6,7 +6,7 @@ description: How to manage Boundary scopes

 # Manage Scopes

-[Scopes](/docs/concepts/domain-model/scopes) are a foundational part of Boundary. They allow users to partition resources and assign ownership of resources to principals. There are three types of scopes within Boundary:
+[Scopes](/boundary/docs/concepts/domain-model/scopes) are a foundational part of Boundary. They allow users to partition resources and assign ownership of resources to principals. There are three types of scopes within Boundary:

 1. Global (`global`)
 2. Org
@@ -18,7 +18,7 @@ These are in a hierarchy:
 - Under the `global` scope there can be many org scopes. These are used to hold IAM-related resources and project scopes.
 - Under each org scope can be many project scopes. These are used to hold infrastructure-related resources.

-Some resources can only be associated with a specific level of scope. As an example, [Targets](/docs/concepts/domain-model/targets) can only be contained within a project scope. Other resources can be contained by multiple scopes. For example, users can be created within the `global` scope or an org-level scope. See the [domain model](/docs/concepts/domain-model) for detailed resource specific information.
+Some resources can only be associated with a specific level of scope. As an example, [Targets](/boundary/docs/concepts/domain-model/targets) can only be contained within a project scope. Other resources can be contained by multiple scopes. For example, users can be created within the `global` scope or an org-level scope. See the [domain model](/boundary/docs/concepts/domain-model) for detailed resource specific information.

 In this example, we're going to create two scopes, an org and a project.

@@ -6,7 +6,7 @@ description: How to manage Boundary sessions

 # Manage Sessions

-[Sessions](/docs/concepts/domain-model/sessions) are Boundary resources created when connecting to a [Target](/docs/concepts/domain-model/targets). A target allows Boundary users to define an endpoint with a protocol and default port to establish a session. Unless specified with a `-host-id` flag when establishing a session, Boundary will choose one [Host](/docs/concepts/domain-model/hosts) from the target's [Host Sets](/docs/concepts/domain-model/host-sets) to connect to at random.
+[Sessions](/boundary/docs/concepts/domain-model/sessions) are Boundary resources created when connecting to a [Target](/boundary/docs/concepts/domain-model/targets). A target allows Boundary users to define an endpoint with a protocol and default port to establish a session. Unless specified with a `-host-id` flag when establishing a session, Boundary will choose one [Host](/boundary/docs/concepts/domain-model/hosts) from the target's [Host Sets](/boundary/docs/concepts/domain-model/host-sets) to connect to at random.

 In this section, we'll show you the basics of how to start a session, view the session details, and cancel a session in Boundary using the CLI.

@@ -28,7 +28,7 @@ Proxy listening information:
    Session ID:          s_h7vBIhH5SZ
 ```

-For more information regarding different ways to connect to a target behind Boundary see [Connect to Target](/docs/getting-started/connect-to-target) under Getting Started and [Advanced Session Establishment](#advanced-session-establishment) below.
+For more information regarding different ways to connect to a target behind Boundary see [Connect to Target](/boundary/docs/getting-started/connect-to-target) under Getting Started and [Advanced Session Establishment](#advanced-session-establishment) below.

 ## View Sessions

@@ -6,7 +6,7 @@ description: How to manage Boundary targets

 # Manage Targets

-[Targets](/docs/concepts/domain-model/targets) are Boundary resources which contain one or more [Host Sets](/docs/concepts/domain-model/host-sets). A target allows Boundary users to define an endpoint with a default port and a protocol to establish a session. Unless specified with a `-host-id` flag, Boundary will choose one [Host](/docs/concepts/domain-model/hosts) in the host set to connect to at random.
+[Targets](/boundary/docs/concepts/domain-model/targets) are Boundary resources which contain one or more [Host Sets](/boundary/docs/concepts/domain-model/host-sets). A target allows Boundary users to define an endpoint with a default port and a protocol to establish a session. Unless specified with a `-host-id` flag, Boundary will choose one [Host](/boundary/docs/concepts/domain-model/hosts) in the host set to connect to at random.

 In this section, we'll show you the basics of how to define a host, host set, and a target in Boundary on the CLI, the admin console, and using our [Terraform provider](https://github.com/hashicorp/terraform-provider-boundary).

@@ -7,8 +7,8 @@ description: How to manage Boundary users and groups
 # Managing Principals (Users and Groups)

 Users and Groups in Boundary are collectively known as principals. Assigning
-[grants](/docs/concepts/security/permissions) on
-[Roles](/docs/concepts/domain-model/roles) is performed through principal IDs;
+[grants](/boundary/docs/concepts/security/permissions) on
+[Roles](/boundary/docs/concepts/domain-model/roles) is performed through principal IDs;
 that is, the unique IDs of either users, groups, or both.

 This page will walk you through managing users within Boundary. (Groups will be
@@ -18,8 +18,8 @@ added at a later time.)

 Users in Boundary represent an _internal_ notion of a particular entity (human,
 machine, etc.). Users can be correlated with one or more
-[Account](/docs/concepts/domain-model/accounts) resources via [Auth
-Methods](/docs/concepts/domain-model/auth-methods). Accounts represent
+[Account](/boundary/docs/concepts/domain-model/accounts) resources via [Auth
+Methods](/boundary/docs/concepts/domain-model/auth-methods). Accounts represent
 _external_ notions of a particular entity. Among other use-cases, this mechanism
 allows for an easy way to switch users to new IdPs within the organization
 deploying Boundary.
@@ -41,7 +41,7 @@ $ boundary authenticate password -login-name=admin -auth-method-id=ampw_12345678

 ## SSH to Target

-Running Boundary in [dev mode](/docs/oss/installing/dev-mode) creates other
+Running Boundary in [dev mode](/boundary/docs/oss/installing/dev-mode) creates other
 default resources such as a target and auth method. The default target (ttcp_1234567890) is already setup with a host
 at `localhost` and a default port of `22`.

@@ -122,7 +122,7 @@ $ boundary authenticate password -login-name=admin -auth-method-id=ampw_12345678

 ## Authorize the Session

-Running Boundary in [dev mode](/docs/oss/installing/dev-mode) creates other
+Running Boundary in [dev mode](/boundary/docs/oss/installing/dev-mode) creates other
 default resources such as a target and auth method. The default target (ttcp_1234567890) is already setup with a host
 at `localhost` and a default port of `22`.

@@ -42,12 +42,12 @@ Password account types have the following additional attributes:
 - [Managed Group][]
 - [User][]

-[auth method]: /docs/concepts/domain-model/auth-methods
-[managed group]: /docs/concepts/domain-model/managed-groups
-[user]: /docs/concepts/domain-model/users
+[auth method]: /boundary/docs/concepts/domain-model/auth-methods
+[managed group]: /boundary/docs/concepts/domain-model/managed-groups
+[user]: /boundary/docs/concepts/domain-model/users

 ## Service API Docs

 The following services are relevant to this resource:

- [Account Service](/api-docs/account-service)
+- [Account Service](/boundary/api-docs/account-service)
@@ -38,19 +38,19 @@ The password auth method has the following additional attributes:
 - [Managed Group][]
 - [Organization][]

-[account]: /docs/concepts/domain-model/accounts
-[accounts]: /docs/concepts/domain-model/accounts
-[global]: /docs/concepts/domain-model/scopes#global
-[managed group]: /docs/concepts/domain-model/managed-groups
-[managed groups]: /docs/concepts/domain-model/managed-groups
-[organization]: /docs/concepts/domain-model/scopes#organizations
-[roles]: /docs/concepts/domain-model/roles
-[scope]: /docs/concepts/domain-model/scopes
-[users]: /docs/concepts/domain-model/users
+[account]: /boundary/docs/concepts/domain-model/accounts
+[accounts]: /boundary/docs/concepts/domain-model/accounts
+[global]: /boundary/docs/concepts/domain-model/scopes#global
+[managed group]: /boundary/docs/concepts/domain-model/managed-groups
+[managed groups]: /boundary/docs/concepts/domain-model/managed-groups
+[organization]: /boundary/docs/concepts/domain-model/scopes#organizations
+[roles]: /boundary/docs/concepts/domain-model/roles
+[scope]: /boundary/docs/concepts/domain-model/scopes
+[users]: /boundary/docs/concepts/domain-model/users

 ## Service API Docs

 The following services are relevant to this resource:

- [Auth Method Service](/api-docs/auth-method-service)
- [Auth Token Service](/api-docs/auth-token-service)
+- [Auth Method Service](/boundary/api-docs/auth-method-service)
+- [Auth Token Service](/boundary/api-docs/auth-token-service)
@@ -70,17 +70,17 @@ The example above uses the account email, but it could be any other parameter.
 - [Credential Store][]
 - [Target][]

-[credential store]: /docs/concepts/domain-model/credential-stores
-[credential stores]: /docs/concepts/domain-model/credential-stores
-[credential]: /docs/concepts/domain-model/credentials
-[credentials]: /docs/concepts/domain-model/credentials
-[project]: /docs/concepts/domain-model/scopes#projects
-[projects]: /docs/concepts/domain-model/scopes#projects
-[target]: /docs/concepts/domain-model/targets
-[targets]: /docs/concepts/domain-model/targets
+[credential store]: /boundary/docs/concepts/domain-model/credential-stores
+[credential stores]: /boundary/docs/concepts/domain-model/credential-stores
+[credential]: /boundary/docs/concepts/domain-model/credentials
+[credentials]: /boundary/docs/concepts/domain-model/credentials
+[project]: /boundary/docs/concepts/domain-model/scopes#projects
+[projects]: /boundary/docs/concepts/domain-model/scopes#projects
+[target]: /boundary/docs/concepts/domain-model/targets
+[targets]: /boundary/docs/concepts/domain-model/targets

 ## Service API Docs

 The following services are relevant to this resource:

- [Credential Library Service](/api-docs/credential-library-service)
+- [Credential Library Service](/boundary/api-docs/credential-library-service)
@@ -80,13 +80,13 @@ A static credential store has no type-specific attributes.

 The following services are relevant to this resource:

- [Credential Store Service](/api-docs/credential-store-service)
+- [Credential Store Service](/boundary/api-docs/credential-store-service)

-[credential library]: /docs/concepts/domain-model/credential-libraries
-[credential libraries]: /docs/concepts/domain-model/credential-libraries
-[credential]: /docs/concepts/domain-model/credentials
-[credentials]: /docs/concepts/domain-model/credentials
-[project]: /docs/concepts/domain-model/scopes#projects
+[credential library]: /boundary/docs/concepts/domain-model/credential-libraries
+[credential libraries]: /boundary/docs/concepts/domain-model/credential-libraries
+[credential]: /boundary/docs/concepts/domain-model/credentials
+[credentials]: /boundary/docs/concepts/domain-model/credentials
+[project]: /boundary/docs/concepts/domain-model/scopes#projects

 ## Vault Token Requirements

@@ -158,7 +158,7 @@ path "sys/capabilities-self" {
 }
 ```

-The above [`boundary-controller` policy](/data/vault/boundary-controller-policy.hcl) is
+The above [`boundary-controller` policy](https://boundaryproject.io/data/vault/boundary-controller-policy.hcl) is
 available for download. Below is an example of writing this policy to Vault:

 ```shell-session
@@ -173,12 +173,12 @@ $ vault policy write boundary-controller boundary-controller-policy.hcl

 A static credential store allows user-supplied credentials to be managed by Boundary. Credentials are encrypted and stored directly in Boundary. Currently, the static credential store can hold credentials of type `username_password`.

-[token_requirements]: /docs/concepts/domain-model/credential-stores#vault-token-requirements
-[token_policy]: /docs/concepts/domain-model/credential-stores#vault-boundary-controller-policy
-[vault]: https://www.vaultproject.io
-[namespace]: https://www.vaultproject.io/docs/enterprise/namespaces
-[renewable]: https://www.vaultproject.io/api-docs/auth/token#renewable-1
-[periodic]: https://www.vaultproject.io/api-docs/auth/token#token_period
-[orphan]: https://www.vaultproject.io/api-docs/auth/token#orphan
-[PKI workers]: /docs/configuration/worker/pki-worker
-[filter]: /docs/concepts/filtering/worker-tags
+[token_requirements]: /boundary/docs/concepts/domain-model/credential-stores#vault-token-requirements
+[token_policy]: /boundary/docs/concepts/domain-model/credential-stores#vault-boundary-controller-policy
+[vault]: https://www.vaultproject.io/
+[namespace]: /vault/docs/enterprise/namespaces
+[renewable]: /vault/api-docs/auth/token#renewable-1
+[periodic]: /vault/api-docs/auth/token#token_period
+[orphan]: /vault/api-docs/auth/token#orphan
+[PKI workers]: /boundary/docs/configuration/worker/pki-worker
+[filter]: /boundary/docs/concepts/filtering/worker-tags
@@ -41,10 +41,10 @@ format.
 - [Session][]
 - [Target][]

-[credential library]: /docs/concepts/domain-model/credential-libraries
-[credential libraries]: /docs/concepts/domain-model/credential-libraries
-[credential store]: /docs/concepts/domain-model/credential-stores
-[credential stores]: /docs/concepts/domain-model/credential-stores
-[host]: /docs/concepts/domain-model/hosts
-[session]: /docs/concepts/domain-model/sessions
-[target]: /docs/concepts/domain-model/targets
+[credential library]: /boundary/docs/concepts/domain-model/credential-libraries
+[credential libraries]: /boundary/docs/concepts/domain-model/credential-libraries
+[credential store]: /boundary/docs/concepts/domain-model/credential-stores
+[credential stores]: /boundary/docs/concepts/domain-model/credential-stores
+[host]: /boundary/docs/concepts/domain-model/hosts
+[session]: /boundary/docs/concepts/domain-model/sessions
+[target]: /boundary/docs/concepts/domain-model/targets
@@ -34,24 +34,24 @@ A group has the following configurable attributes:
 - [Role][]
 - [User][]

-[global]: /docs/concepts/domain-model/scopes#global
-[group]: /docs/concepts/domain-model/groups
-[groups]: /docs/concepts/domain-model/groups
-[organization]: /docs/concepts/domain-model/scopes#organizations
-[permissions]: /docs/concepts/security/permissions
-[project]: /docs/concepts/domain-model/scopes#projects
-[role]: /docs/concepts/domain-model/roles
-[roles]: /docs/concepts/domain-model/roles
-[scope]: /docs/concepts/domain-model/scopes
-[user]: /docs/concepts/domain-model/users
-[users]: /docs/concepts/domain-model/users
+[global]: /boundary/docs/concepts/domain-model/scopes#global
+[group]: /boundary/docs/concepts/domain-model/groups
+[groups]: /boundary/docs/concepts/domain-model/groups
+[organization]: /boundary/docs/concepts/domain-model/scopes#organizations
+[permissions]: /boundary/docs/concepts/security/permissions
+[project]: /boundary/docs/concepts/domain-model/scopes#projects
+[role]: /boundary/docs/concepts/domain-model/roles
+[roles]: /boundary/docs/concepts/domain-model/roles
+[scope]: /boundary/docs/concepts/domain-model/scopes
+[user]: /boundary/docs/concepts/domain-model/users
+[users]: /boundary/docs/concepts/domain-model/users

 ## Service API Docs

 The following services are relevant to this resource:

- [Group Service](/api-docs/group-service)
+- [Group Service](/boundary/api-docs/group-service)

 ## Tutorial

-Refer to the [Manage Users and Groups with HCP Boundary](https://learn.hashicorp.com/tutorials/boundary/hcp-manage-users-groups) tutorial to learn how to complete user management related tasks.
+Refer to the [Manage Users and Groups with HCP Boundary](/boundary/tutorials/hcp-administration/hcp-manage-users-groups) tutorial to learn how to complete user management related tasks.
@@ -39,14 +39,14 @@ A host catalog has the following configurable attributes:
 - [Host Set][]
 - [Project][]

-[host set]: /docs/concepts/domain-model/host-sets
-[host sets]: /docs/concepts/domain-model/host-sets
-[host]: /docs/concepts/domain-model/hosts
-[hosts]: /docs/concepts/domain-model/hosts
-[project]: /docs/concepts/domain-model/scopes#projects
+[host set]: /boundary/docs/concepts/domain-model/host-sets
+[host sets]: /boundary/docs/concepts/domain-model/host-sets
+[host]: /boundary/docs/concepts/domain-model/hosts
+[hosts]: /boundary/docs/concepts/domain-model/hosts
+[project]: /boundary/docs/concepts/domain-model/scopes#projects

 ## Service API Docs

 The following services are relevant to this resource:

- [Host Catalog Service](/api-docs/host-catalog-service)
+- [Host Catalog Service](/boundary/api-docs/host-catalog-service)
@@ -48,19 +48,19 @@ A host set has the following configurable attributes:
 - [Host Catalog][]
 - [Target][]

-[host catalog]: /docs/concepts/domain-model/host-catalogs
-[host catalogs]: /docs/concepts/domain-model/host-catalogs
-[host]: /docs/concepts/domain-model/hosts
-[hosts]: /docs/concepts/domain-model/hosts
-[project]: /docs/concepts/domain-model/scopes#projects
-[projects]: /docs/concepts/domain-model/scopes#projects
-[session]: /docs/concepts/domain-model/sessions
-[sessions]: /docs/concepts/domain-model/sessions
-[target]: /docs/concepts/domain-model/targets
-[targets]: /docs/concepts/domain-model/targets
+[host catalog]: /boundary/docs/concepts/domain-model/host-catalogs
+[host catalogs]: /boundary/docs/concepts/domain-model/host-catalogs
+[host]: /boundary/docs/concepts/domain-model/hosts
+[hosts]: /boundary/docs/concepts/domain-model/hosts
+[project]: /boundary/docs/concepts/domain-model/scopes#projects
+[projects]: /boundary/docs/concepts/domain-model/scopes#projects
+[session]: /boundary/docs/concepts/domain-model/sessions
+[sessions]: /boundary/docs/concepts/domain-model/sessions
+[target]: /boundary/docs/concepts/domain-model/targets
+[targets]: /boundary/docs/concepts/domain-model/targets

 ## Service API Docs

 The following services are relevant to this resource:

- [Host Set Service](/api-docs/host-set-service)
+- [Host Set Service](/boundary/api-docs/host-set-service)
@@ -42,13 +42,13 @@ Static host types have the following additional attribute:
 - [Host Catalog][]
 - [Host Set][]

-[host catalog]: /docs/concepts/domain-model/host-catalogs
-[host catalogs]: /docs/concepts/domain-model/host-catalogs
-[host set]: /docs/concepts/domain-model/host-sets
-[host sets]: /docs/concepts/domain-model/host-sets
+[host catalog]: /boundary/docs/concepts/domain-model/host-catalogs
+[host catalogs]: /boundary/docs/concepts/domain-model/host-catalogs
+[host set]: /boundary/docs/concepts/domain-model/host-sets
+[host sets]: /boundary/docs/concepts/domain-model/host-sets

 ## Service API Docs

 The following services are relevant to this resource:

- [Host Service](/api-docs/host-service)
+- [Host Service](/boundary/api-docs/host-service)
@@ -11,17 +11,17 @@ description: |-

 ## Scopes

-When conducting threat modeling exercises, it is common practice to mitigate  identified risks by reducing their potential blast radius and attack surface. Boundary uses the concept of scopes to help security operators achieve this type of mitigation.  A [Scope](/docs/concepts/domain-model/scopes) can be considered as a container for resources and permissions. Each scope has a permissions boundary that is isolated from other scopes on the same level, creating a defined blast radius.
+When conducting threat modeling exercises, it is common practice to mitigate  identified risks by reducing their potential blast radius and attack surface. Boundary uses the concept of scopes to help security operators achieve this type of mitigation.  A [Scope](/boundary/docs/concepts/domain-model/scopes) can be considered as a container for resources and permissions. Each scope has a permissions boundary that is isolated from other scopes on the same level, creating a defined blast radius.
 The diagram below illustrates the relationship between the different levels of scopes.


 ![](/img/boundary-domain-model-overview.jpg)

-The highest-level  scope is the [Global Scope](/docs/concepts/domain-model/scopes#global). Boundary administrators operate on this level to configure and manage Boundary for the entire business. Boundary administrators  can also manage child scopes, auth methods, users, groups, roles, and grants.
+The highest-level  scope is the [Global Scope](/boundary/docs/concepts/domain-model/scopes#global). Boundary administrators operate on this level to configure and manage Boundary for the entire business. Boundary administrators  can also manage child scopes, auth methods, users, groups, roles, and grants.

-The intermediate scope level is  [Organizations](/docs/concepts/domain-model/scopes#organizations), also referred to as orgs, which are a child scope of global.  Though the implementation may be flexible for organization scopes, we recommend scoping by business units in this case. Scoping by business unit provides a clear separation of concerns for each business unit. Creating organizations for the development, operations, and support teams would be an example.
+The intermediate scope level is  [Organizations](/boundary/docs/concepts/domain-model/scopes#organizations), also referred to as orgs, which are a child scope of global.  Though the implementation may be flexible for organization scopes, we recommend scoping by business units in this case. Scoping by business unit provides a clear separation of concerns for each business unit. Creating organizations for the development, operations, and support teams would be an example.

-The lowest scope level is the [Project](/docs/concepts/domain-model/scopes#projects). An organization’s scope may have as many projects as required based on its business workflows. To expand on the example used earlier, the development team’s organization can also have project scopes for their different products.
+The lowest scope level is the [Project](/boundary/docs/concepts/domain-model/scopes#projects). An organization’s scope may have as many projects as required based on its business workflows. To expand on the example used earlier, the development team’s organization can also have project scopes for their different products.

 For example, they could have the following project scopes:

@@ -31,27 +31,27 @@ For example, they could have the following project scopes:

 ## Identity and Access Management

-As mentioned earlier, IAM  is handled at the organization and global scope levels. Here, operators can create and manage principals. Principals are entities in Boundary that are either [Users](/docs/concepts/domain-model/users) or [Groups](/docs/concepts/domain-model/groups) that may be assigned capabilities.
+As mentioned earlier, IAM  is handled at the organization and global scope levels. Here, operators can create and manage principals. Principals are entities in Boundary that are either [Users](/boundary/docs/concepts/domain-model/users) or [Groups](/boundary/docs/concepts/domain-model/groups) that may be assigned capabilities.

 Users are associated with either the global or an organization’s scope. For better access control management, users may be positioned into groups to ease access control demands. Groups can also contain users from different organizations or global scopes without creating multiple users for a single entity, making permissioning less complicated to implement.

-An [Auth Method](/docs/concepts/domain-model/auth-methods) is the mechanism in Boundary used for authentication. An organization may use numerous authentication methods. Boundary supports Open ID Connect (OIDC) auth methods to delegate authentication to an external identity provider (IDP) - such as Azure Active Directory, Okta, and other OIDC providers - as well as a Boundary-native password auth method. Within an auth method, [Accounts](/docs/concepts/domain-model/accounts) may be created and associated with users.  Once associated with a user, the principal may authenticate in Boundary using the method specified by their auth method. An account for the password auth method consists of a login name and password. A user may be associated with accounts from different auth methods, where they can have both an Azure Active Directory account and an Okta account, for example. In such cases, the user could authenticate with either provider.
+An [Auth Method](/boundary/docs/concepts/domain-model/auth-methods) is the mechanism in Boundary used for authentication. An organization may use numerous authentication methods. Boundary supports Open ID Connect (OIDC) auth methods to delegate authentication to an external identity provider (IDP) - such as Azure Active Directory, Okta, and other OIDC providers - as well as a Boundary-native password auth method. Within an auth method, [Accounts](/boundary/docs/concepts/domain-model/accounts) may be created and associated with users.  Once associated with a user, the principal may authenticate in Boundary using the method specified by their auth method. An account for the password auth method consists of a login name and password. A user may be associated with accounts from different auth methods, where they can have both an Azure Active Directory account and an Okta account, for example. In such cases, the user could authenticate with either provider.

 ## Access Management

 Boundary’s method of access management starts at the lowest level with Actions. Actions are capabilities that can be performed against Boundary resources. Boundary supports generic Actions such as, Create, Read, Update, Delete, and List. However, there are many more that are resource-type-specific actions that can be used in grants.

-The next level of access management is a [Grant](/docs/concepts/security/permissions#grant-strings). A grant in Boundary contains an action(s) and the resource(s) that the action(s) are permitted to be performed against. This can be thought of like a rule.
+The next level of access management is a [Grant](/boundary/docs/concepts/security/permissions#grant-strings). A grant in Boundary contains an action(s) and the resource(s) that the action(s) are permitted to be performed against. This can be thought of like a rule.

 For example, a grant can specify the List Action against a specific resource. Grants can specify resource types or resource IDs and may also be implemented as a rule.

-The highest-level in Boundary utilizes the concepts of [Roles](/docs/concepts/domain-model/roles). Roles are a collection of zero or more grants. Roles are assigned to principals (users and groups) and govern what actions they are authorized to perform.  Roles belong to a single scope and their lifecycle is dependent on the existence of that scope. Should the scope be deleted, the role would be deleted too. The diagram below illustrates the relationship between the different IAM components within Boundary.
+The highest-level in Boundary utilizes the concepts of [Roles](/boundary/docs/concepts/domain-model/roles). Roles are a collection of zero or more grants. Roles are assigned to principals (users and groups) and govern what actions they are authorized to perform.  Roles belong to a single scope and their lifecycle is dependent on the existence of that scope. Should the scope be deleted, the role would be deleted too. The diagram below illustrates the relationship between the different IAM components within Boundary.

 ![](/img/component-relationship.png)

 ## Target and Host Resources

-Boundary exposes endpoints to users as [Targets](/docs/concepts/domain-model/targets). A target is a resource representing a networked service, with an associated set of permissions, that allows a user to connect and interact with Boundary within a single session. A target may contain references to [Host](/docs/concepts/domain-model/hosts) sources or an address, and [Credential](/docs/concepts/domain-model/credentials) sources. Users who access a target create an authorized session to its address or one of its host sources with returned credentials from the target’s credential source.
+Boundary exposes endpoints to users as [Targets](/boundary/docs/concepts/domain-model/targets). A target is a resource representing a networked service, with an associated set of permissions, that allows a user to connect and interact with Boundary within a single session. A target may contain references to [Host](/boundary/docs/concepts/domain-model/hosts) sources or an address, and [Credential](/boundary/docs/concepts/domain-model/credentials) sources. Users who access a target create an authorized session to its address or one of its host sources with returned credentials from the target’s credential source.

 A target exposes two distinct and mutually exclusive configuration paths for its
 representation of a networked service:
@@ -169,35 +169,35 @@ that is itself contained within a scope.
 Refer to the [Scopes] section to help you understand the structure of resources within Boundary.

 [iam]: https://en.wikipedia.org/wiki/Identity_management
-[account]: /docs/concepts/domain-model/accounts
-[accounts]: /docs/concepts/domain-model/accounts
-[authentication method]: /docs/concepts/domain-model/auth-methods
-[authentication methods]: /docs/concepts/domain-model/auth-methods
-[credential library]: /docs/concepts/domain-model/credential-libraries
-[credential libraries]: /docs/concepts/domain-model/credential-libraries
-[credential store]: /docs/concepts/domain-model/credential-stores
-[credential stores]: /docs/concepts/domain-model/credential-stores
-[credential]: /docs/concepts/domain-model/credentials
-[credentials]: /docs/concepts/domain-model/credentials
-[group]: /docs/concepts/domain-model/groups
-[groups]: /docs/concepts/domain-model/groups
-[host catalog]: /docs/concepts/domain-model/host-catalogs
-[host catalogs]: /docs/concepts/domain-model/host-catalogs
-[host set]: /docs/concepts/domain-model/host-sets
-[host sets]: /docs/concepts/domain-model/host-sets
-[host]: /docs/concepts/domain-model/hosts
-[hosts]: /docs/concepts/domain-model/hosts
-[managed group]: /docs/concepts/domain-model/managed-groups
-[role]: /docs/concepts/domain-model/roles
-[roles]: /docs/concepts/domain-model/roles
-[scope]: /docs/concepts/domain-model/scopes
-[scopes]: /docs/concepts/domain-model/scopes
-[project]: /docs/concepts/domain-model/scopes#projects
-[session]: /docs/concepts/domain-model/sessions
-[sessions]: /docs/concepts/domain-model/sessions
-[target]: /docs/concepts/domain-model/targets
-[targets]: /docs/concepts/domain-model/targets
-[user]: /docs/concepts/domain-model/users
-[users]: /docs/concepts/domain-model/users
-[permission]: /docs/concepts/security/permissions
-[permissions]: /docs/concepts/security/permissions
+[account]: /boundary/docs/concepts/domain-model/accounts
+[accounts]: /boundary/docs/concepts/domain-model/accounts
+[authentication method]: /boundary/docs/concepts/domain-model/auth-methods
+[authentication methods]: /boundary/docs/concepts/domain-model/auth-methods
+[credential library]: /boundary/docs/concepts/domain-model/credential-libraries
+[credential libraries]: /boundary/docs/concepts/domain-model/credential-libraries
+[credential store]: /boundary/docs/concepts/domain-model/credential-stores
+[credential stores]: /boundary/docs/concepts/domain-model/credential-stores
+[credential]: /boundary/docs/concepts/domain-model/credentials
+[credentials]: /boundary/docs/concepts/domain-model/credentials
+[group]: /boundary/docs/concepts/domain-model/groups
+[groups]: /boundary/docs/concepts/domain-model/groups
+[host catalog]: /boundary/docs/concepts/domain-model/host-catalogs
+[host catalogs]: /boundary/docs/concepts/domain-model/host-catalogs
+[host set]: /boundary/docs/concepts/domain-model/host-sets
+[host sets]: /boundary/docs/concepts/domain-model/host-sets
+[host]: /boundary/docs/concepts/domain-model/hosts
+[hosts]: /boundary/docs/concepts/domain-model/hosts
+[managed group]: /boundary/docs/concepts/domain-model/managed-groups
+[role]: /boundary/docs/concepts/domain-model/roles
+[roles]: /boundary/docs/concepts/domain-model/roles
+[scope]: /boundary/docs/concepts/domain-model/scopes
+[scopes]: /boundary/docs/concepts/domain-model/scopes
+[project]: /boundary/docs/concepts/domain-model/scopes#projects
+[session]: /boundary/docs/concepts/domain-model/sessions
+[sessions]: /boundary/docs/concepts/domain-model/sessions
+[target]: /boundary/docs/concepts/domain-model/targets
+[targets]: /boundary/docs/concepts/domain-model/targets
+[user]: /boundary/docs/concepts/domain-model/users
+[users]: /boundary/docs/concepts/domain-model/users
+[permission]: /boundary/docs/concepts/security/permissions
+[permissions]: /boundary/docs/concepts/security/permissions
@@ -38,24 +38,24 @@ OIDC managed groups have the following additional attributes:
  specific information on the data available for this purpose see the [OIDC
  Managed Groups Filtering][] page.

-[filtering concepts]: /docs/concepts/filtering
-[oidc managed groups filtering]: /docs/concepts/filtering/oidc-managed-groups
+[filtering concepts]: /boundary/docs/concepts/filtering
+[oidc managed groups filtering]: /boundary/docs/concepts/filtering/oidc-managed-groups

 ## Referenced By

 - [Accounts][]
 - [Auth Method][]

-[accounts]: /docs/concepts/domain-model/accounts
-[auth method]: /docs/concepts/domain-model/auth-methods
-[roles]: /docs/concepts/domain-model/roles
+[accounts]: /boundary/docs/concepts/domain-model/accounts
+[auth method]: /boundary/docs/concepts/domain-model/auth-methods
+[roles]: /boundary/docs/concepts/domain-model/roles

 ## Service API Docs

 The following services are relevant to this resource:

- [Managed Group Service](/api-docs/managed-group-service)
+- [Managed Group Service](/boundary/api-docs/managed-group-service)

 ## Tutorial

-Refer to the [Manage Users and Groups with HCP Boundary](https://learn.hashicorp.com/tutorials/boundary/hcp-manage-users-groups) tutorial to learn how to complete user management related tasks.
+Refer to the [Manage Users and Groups with HCP Boundary](/boundary/tutorials/hcp-administration/hcp-manage-users-groups) tutorial to learn how to complete user management related tasks.
@@ -31,22 +31,22 @@ A role has the following configurable attributes:
 - [Project][]
 - [User][]

-[group]: /docs/concepts/domain-model/groups
-[groups]: /docs/concepts/domain-model/groups
-[managed group]: /docs/concepts/domain-model/managed-groups
-[managed groups]: /docs/concepts/domain-model/managed-groups
-[permissions]: /docs/concepts/security/permissions
-[project]: /docs/concepts/domain-model/scopes#projects
-[scope]: /docs/concepts/domain-model/scopes
-[user]: /docs/concepts/domain-model/users
-[users]: /docs/concepts/domain-model/users
+[group]: /boundary/docs/concepts/domain-model/groups
+[groups]: /boundary/docs/concepts/domain-model/groups
+[managed group]: /boundary/docs/concepts/domain-model/managed-groups
+[managed groups]: /boundary/docs/concepts/domain-model/managed-groups
+[permissions]: /boundary/docs/concepts/security/permissions
+[project]: /boundary/docs/concepts/domain-model/scopes#projects
+[scope]: /boundary/docs/concepts/domain-model/scopes
+[user]: /boundary/docs/concepts/domain-model/users
+[users]: /boundary/docs/concepts/domain-model/users

 ## Service API Docs

 The following services are relevant to this resource:

- [Role Service](/api-docs/role-service)
+- [Role Service](/boundary/api-docs/role-service)

 ## Tutorial

-Refer to the [Managed Roles and Permissions with HCP Boundary](https://learn.hashicorp.com/tutorials/boundary/hcp-manage-roles) tutorial to learn how to create a role in Boundary.
+Refer to the [Managed Roles and Permissions with HCP Boundary](/boundary/tutorials/hcp-administration/hcp-manage-roles) tutorial to learn how to create a role in Boundary.
@@ -57,34 +57,34 @@ A scope has the following configurable attributes:
 - [Target][]
 - [User][]

-[auth method]: /docs/concepts/domain-model/auth-methods
-[auth methods]: /docs/concepts/domain-model/auth-methods
-[credential store]: /docs/concepts/domain-model/credential-stores
-[credential stores]: /docs/concepts/domain-model/credential-stores
-[global]: /docs/concepts/domain-model/scopes#global
-[group]: /docs/concepts/domain-model/groups
-[groups]: /docs/concepts/domain-model/groups
-[host catalog]: /docs/concepts/domain-model/host-catalogs
-[host catalogs]: /docs/concepts/domain-model/host-catalogs
-[organization]: /docs/concepts/domain-model/scopes#organizations
-[organizations]: /docs/concepts/domain-model/scopes#organizations
-[permission]: /docs/concepts/security/permissions
-[permissions]: /docs/concepts/security/permissions
-[project]: /docs/concepts/domain-model/scopes#projects
-[projects]: /docs/concepts/domain-model/scopes#projects
-[role]: /docs/concepts/domain-model/roles
-[roles]: /docs/concepts/domain-model/roles
-[target]: /docs/concepts/domain-model/targets
-[targets]: /docs/concepts/domain-model/targets
-[user]: /docs/concepts/domain-model/users
-[users]: /docs/concepts/domain-model/users
+[auth method]: /boundary/docs/concepts/domain-model/auth-methods
+[auth methods]: /boundary/docs/concepts/domain-model/auth-methods
+[credential store]: /boundary/docs/concepts/domain-model/credential-stores
+[credential stores]: /boundary/docs/concepts/domain-model/credential-stores
+[global]: /boundary/docs/concepts/domain-model/scopes#global
+[group]: /boundary/docs/concepts/domain-model/groups
+[groups]: /boundary/docs/concepts/domain-model/groups
+[host catalog]: /boundary/docs/concepts/domain-model/host-catalogs
+[host catalogs]: /boundary/docs/concepts/domain-model/host-catalogs
+[organization]: /boundary/docs/concepts/domain-model/scopes#organizations
+[organizations]: /boundary/docs/concepts/domain-model/scopes#organizations
+[permission]: /boundary/docs/concepts/security/permissions
+[permissions]: /boundary/docs/concepts/security/permissions
+[project]: /boundary/docs/concepts/domain-model/scopes#projects
+[projects]: /boundary/docs/concepts/domain-model/scopes#projects
+[role]: /boundary/docs/concepts/domain-model/roles
+[roles]: /boundary/docs/concepts/domain-model/roles
+[target]: /boundary/docs/concepts/domain-model/targets
+[targets]: /boundary/docs/concepts/domain-model/targets
+[user]: /boundary/docs/concepts/domain-model/users
+[users]: /boundary/docs/concepts/domain-model/users

 ## Service API Docs

 The following services are relevant to this resource:

- [Scope Service](/api-docs/scope-service)
+- [Scope Service](/boundary/api-docs/scope-service)

 ## Tutorial

-Refer to the [Manage Scopes with HCP Boundary](https://learn.hashicorp.com/tutorials/boundary/hcp-manage-scopes) tutorial to learn how to create an org scope and a project scope.
+Refer to the [Manage Scopes with HCP Boundary](/boundary/tutorials/hcp-administration/hcp-manage-scopes) tutorial to learn how to create an org scope and a project scope.
@@ -19,8 +19,8 @@ Session connections terminate on user exit from the proxy, or on termination of

 - [Session][]

-[credentials]: /docs/concepts/domain-model/credentials
-[host]: /docs/concepts/domain-model/hosts
-[session]: /docs/concepts/domain-model/sessions
-[target]: /docs/concepts/domain-model/targets
-[user]: /docs/concepts/domain-model/users
+[credentials]: /boundary/docs/concepts/domain-model/credentials
+[host]: /boundary/docs/concepts/domain-model/hosts
+[session]: /boundary/docs/concepts/domain-model/sessions
+[target]: /boundary/docs/concepts/domain-model/targets
+[user]: /boundary/docs/concepts/domain-model/users
@@ -67,42 +67,42 @@ Changes to a user's permissions do not effect existing sessions.
 - [Host Set][]
 - [Target][]

-[expiration time]: /docs/concepts/domain-model/targets#session_max_seconds
-[connection limit]: /docs/concepts/domain-model/targets#session_connection_limit
-[target's attributes]: /docs/concepts/domain-model/targets#tcp-target-attributes
-[account]: /docs/concepts/domain-model/accounts
-[accounts]: /docs/concepts/domain-model/accounts
-[authentication method]: /docs/concepts/domain-model/auth-methods
-[authentication methods]: /docs/concepts/domain-model/auth-methods
-[connections]: /docs/concepts/domain-model/session-connections
-[credential library]: /docs/concepts/domain-model/credential-libraries
-[credential libraries]: /docs/concepts/domain-model/credential-libraries
-[credential store]: /docs/concepts/domain-model/credential-stores
-[credential stores]: /docs/concepts/domain-model/credential-stores
-[credential]: /docs/concepts/domain-model/credentials
-[credentials]: /docs/concepts/domain-model/credentials
-[host catalog]: /docs/concepts/domain-model/host-catalogs
-[host catalogs]: /docs/concepts/domain-model/host-catalogs
-[host set]: /docs/concepts/domain-model/host-sets
-[host sets]: /docs/concepts/domain-model/host-sets
-[host]: /docs/concepts/domain-model/hosts
-[hosts]: /docs/concepts/domain-model/hosts
-[target]: /docs/concepts/domain-model/targets
-[targets]: /docs/concepts/domain-model/targets
-[user]: /docs/concepts/domain-model/users
-[users]: /docs/concepts/domain-model/users
-[organization]: /docs/concepts/domain-model/scopes#organizations
-[organizations]: /docs/concepts/domain-model/scopes#organizations
-[project]: /docs/concepts/domain-model/scopes#projects
-[projects]: /docs/concepts/domain-model/scopes#projects
-[permissions]: /docs/concepts/security/permissions
+[expiration time]: /boundary/docs/concepts/domain-model/targets#session_max_seconds
+[connection limit]: /boundary/docs/concepts/domain-model/targets#session_connection_limit
+[target's attributes]: /boundary/docs/concepts/domain-model/targets#tcp-target-attributes
+[account]: /boundary/docs/concepts/domain-model/accounts
+[accounts]: /boundary/docs/concepts/domain-model/accounts
+[authentication method]: /boundary/docs/concepts/domain-model/auth-methods
+[authentication methods]: /boundary/docs/concepts/domain-model/auth-methods
+[connections]: /boundary/docs/concepts/domain-model/session-connections
+[credential library]: /boundary/docs/concepts/domain-model/credential-libraries
+[credential libraries]: /boundary/docs/concepts/domain-model/credential-libraries
+[credential store]: /boundary/docs/concepts/domain-model/credential-stores
+[credential stores]: /boundary/docs/concepts/domain-model/credential-stores
+[credential]: /boundary/docs/concepts/domain-model/credentials
+[credentials]: /boundary/docs/concepts/domain-model/credentials
+[host catalog]: /boundary/docs/concepts/domain-model/host-catalogs
+[host catalogs]: /boundary/docs/concepts/domain-model/host-catalogs
+[host set]: /boundary/docs/concepts/domain-model/host-sets
+[host sets]: /boundary/docs/concepts/domain-model/host-sets
+[host]: /boundary/docs/concepts/domain-model/hosts
+[hosts]: /boundary/docs/concepts/domain-model/hosts
+[target]: /boundary/docs/concepts/domain-model/targets
+[targets]: /boundary/docs/concepts/domain-model/targets
+[user]: /boundary/docs/concepts/domain-model/users
+[users]: /boundary/docs/concepts/domain-model/users
+[organization]: /boundary/docs/concepts/domain-model/scopes#organizations
+[organizations]: /boundary/docs/concepts/domain-model/scopes#organizations
+[project]: /boundary/docs/concepts/domain-model/scopes#projects
+[projects]: /boundary/docs/concepts/domain-model/scopes#projects
+[permissions]: /boundary/docs/concepts/security/permissions

 ## Service API Docs

 The following services are relevant to this resource:

- [Session Service](/api-docs/session-service)
+- [Session Service](/boundary/api-docs/session-service)

 ## Tutorial

-Refer to the [Manage Sessions with HCP Boundary](https://learn.hashicorp.com/tutorials/boundary/hcp-manage-sessions) tutorial to learn how to start, view, and cancel a session.
+Refer to the [Manage Sessions with HCP Boundary](/boundary/tutorials/hcp-administration/hcp-manage-sessions) tutorial to learn how to start, view, and cancel a session.
@@ -118,32 +118,32 @@ SSH targets have the following additional attributes:
 - [Session][]
 - [Worker Filtering][]

-[credentials]: /docs/concepts/domain-model/credentials
-[credential library]: /docs/concepts/domain-model/credential-libraries
-[credential libraries]: /docs/concepts/domain-model/credential-libraries
-[credential store]: /docs/concepts/domain-model/credential-stores
-[credential stores]: /docs/concepts/domain-model/credential-stores
-[host catalog]: /docs/concepts/domain-model/host-catalogs
-[host catalogs]: /docs/concepts/domain-model/host-catalogs
-[host set]: /docs/concepts/domain-model/host-sets
-[host sets]: /docs/concepts/domain-model/host-sets
-[host]: /docs/concepts/domain-model/hosts
-[hosts]: /docs/concepts/domain-model/hosts
-[permission]: /docs/concepts/security/permissions
-[permissions]: /docs/concepts/security/permissions
-[project]: /docs/concepts/domain-model/scopes#projects
-[projects]: /docs/concepts/domain-model/scopes#projects
-[role]: /docs/concepts/domain-model/roles
-[roles]: /docs/concepts/domain-model/roles
-[session]: /docs/concepts/domain-model/sessions
-[sessions]: /docs/concepts/domain-model/sessions
-[filter]: /docs/concepts/filtering/worker-tags
-[worker filtering]: /docs/concepts/filtering/worker-tags
-[user]: /docs/concepts/domain-model/users
-[users]: /docs/concepts/domain-model/users
+[credentials]: /boundary/docs/concepts/domain-model/credentials
+[credential library]: /boundary/docs/concepts/domain-model/credential-libraries
+[credential libraries]: /boundary/docs/concepts/domain-model/credential-libraries
+[credential store]: /boundary/docs/concepts/domain-model/credential-stores
+[credential stores]: /boundary/docs/concepts/domain-model/credential-stores
+[host catalog]: /boundary/docs/concepts/domain-model/host-catalogs
+[host catalogs]: /boundary/docs/concepts/domain-model/host-catalogs
+[host set]: /boundary/docs/concepts/domain-model/host-sets
+[host sets]: /boundary/docs/concepts/domain-model/host-sets
+[host]: /boundary/docs/concepts/domain-model/hosts
+[hosts]: /boundary/docs/concepts/domain-model/hosts
+[permission]: /boundary/docs/concepts/security/permissions
+[permissions]: /boundary/docs/concepts/security/permissions
+[project]: /boundary/docs/concepts/domain-model/scopes#projects
+[projects]: /boundary/docs/concepts/domain-model/scopes#projects
+[role]: /boundary/docs/concepts/domain-model/roles
+[roles]: /boundary/docs/concepts/domain-model/roles
+[session]: /boundary/docs/concepts/domain-model/sessions
+[sessions]: /boundary/docs/concepts/domain-model/sessions
+[filter]: /boundary/docs/concepts/filtering/worker-tags
+[worker filtering]: /boundary/docs/concepts/filtering/worker-tags
+[user]: /boundary/docs/concepts/domain-model/users
+[users]: /boundary/docs/concepts/domain-model/users

 ## Service API Docs

 The following services are relevant to this resource:

- [Target Service](/api-docs/target-service)
+- [Target Service](/boundary/api-docs/target-service)
@@ -41,20 +41,20 @@ A user has the following configurable attributes:
 - [Organization][]
 - [Role][]

-[account]: /docs/concepts/domain-model/accounts
-[accounts]: /docs/concepts/domain-model/accounts
-[auth method]: /docs/concepts/domain-model/auth-methods
-[global]: /docs/concepts/domain-model/scopes#global
-[group]: /docs/concepts/domain-model/groups
-[groups]: /docs/concepts/domain-model/groups
-[organization]: /docs/concepts/domain-model/scopes#organizations
-[permissions]: /docs/concepts/security/permissions
-[role]: /docs/concepts/domain-model/roles
-[roles]: /docs/concepts/domain-model/roles
-[scope]: /docs/concepts/domain-model/scopes
+[account]: /boundary/docs/concepts/domain-model/accounts
+[accounts]: /boundary/docs/concepts/domain-model/accounts
+[auth method]: /boundary/docs/concepts/domain-model/auth-methods
+[global]: /boundary/docs/concepts/domain-model/scopes#global
+[group]: /boundary/docs/concepts/domain-model/groups
+[groups]: /boundary/docs/concepts/domain-model/groups
+[organization]: /boundary/docs/concepts/domain-model/scopes#organizations
+[permissions]: /boundary/docs/concepts/security/permissions
+[role]: /boundary/docs/concepts/domain-model/roles
+[roles]: /boundary/docs/concepts/domain-model/roles
+[scope]: /boundary/docs/concepts/domain-model/scopes

 ## Service API Docs

 The following services are relevant to this resource:

- [User Service](/api-docs/user-service)
+- [User Service](/boundary/api-docs/user-service)
@@ -17,9 +17,9 @@ json.

 Boundary allows you to configure any number of sinks where these events will be
 written. When configuring an event sink, you can specify [common sink
-parameters](/docs/configuration/events/common) which include both
+parameters](/boundary/docs/configuration/events/common) which include both
 `allow_filters` and `deny_filters` which use the standard [filter
-syntax](/docs/concepts/filtering) used elsewhere in Boundary.
+syntax](/boundary/docs/concepts/filtering) used elsewhere in Boundary.

 Example events encoded as cloudevents-text.  The first event is a system event
 and the second event is an observation event.
@@ -5,7 +5,7 @@ description: |-
  How to configure filters for managed groups within the OIDC auth method.
 ---

-[filter syntax]: /docs/concepts/filtering
+[filter syntax]: /boundary/docs/concepts/filtering

 # OIDC Managed Groups Filtering

@@ -15,7 +15,7 @@ affect the database queries generated for the operation and as such is not
 designed to provide greater efficiency.

 Starting in Boundary 0.1.8, when running a list action, a filter can be
-specified. It uses the standard [filter syntax](/docs/concepts/filtering) used
+specified. It uses the standard [filter syntax](/boundary/docs/concepts/filtering) used
 elsewhere in Boundary. Unless otherwise specified for a given list endpoint, the
 list of items being returned is looped through and the filter is run on the JSON
 representation of that item. A good way to see what that data looks like is by
@@ -138,7 +138,7 @@ Following are some examples of using these values in filters:

 Once workers have tags, you can use these tags to control which
 workers are allowed to manage a given session by specifying optional worker filter attributes
-when you configure [targets](/docs/concepts/domain-model/targets).
+when you configure [targets](/boundary/docs/concepts/domain-model/targets).

 The `egress_worker_filter` attribute controls which workers are used for egress to a target. This is the worker
 that accesses the target.
@@ -158,5 +158,5 @@ Vault requests to Boundary controllers.
 ~> **Note:** A PKI worker that matches the worker filter must exist before defining the Vault credential store, as it
 will perform the Vault calls needed to set up the credential store with Boundary.

-[PKI workers]: /docs/configuration/worker/pki-worker
-[credential stores]: /docs/concepts/domain-model/credential-stores#vault-credential-store-attributes
+[PKI workers]: /boundary/docs/configuration/worker/pki-worker
+[credential stores]: /boundary/docs/concepts/domain-model/credential-stores#vault-credential-store-attributes
@@ -8,6 +8,6 @@ description: |-
 # Concepts

 This section covers some concepts that are imporant to understand Boundary usage and operation. Every page in this section is recommended reading for anyone consuming or operating
-Boundary. For a glossary of terms, refer to the [domain model](/docs/concepts/domain-model) section.
+Boundary. For a glossary of terms, refer to the [domain model](/boundary/docs/concepts/domain-model) section.

 Please use the navigation to the left to learn more about a topic.
@@ -241,7 +241,7 @@ mechanism is as follows:

 ### KMS-Based Worker Authentication

-Workers can take advantage of the [KMS](/docs/concepts/security/data-encryption)
+Workers can take advantage of the [KMS](/boundary/docs/concepts/security/data-encryption)
 key designated for `worker-auth` within Boundary's configuration file, which
 must point to the same key on the KMS for both the Controller and the Worker.
 Security of the connection relies on secure transmission of a single set of
@@ -9,14 +9,14 @@ description: |-

 Boundary has multiple mechanisms to ensure secure end-to-end behavior of the
 system. A key part of this is [support for various Key Management
-Systems](/docs/configuration/kms) that protect the base encryption keys used
+Systems](/boundary/docs/configuration/kms) that protect the base encryption keys used
 for various functions. This page describes the various KMS key purposes that
 Boundary supports and how they are used within the system.

 ## The `worker-auth-storage` KMS Key

 The `worker-auth-storage` KMS key is used by a [PKI
-Worker](/docs/configuration/worker/pki-worker) for storage of authentication
+Worker](/boundary/docs/configuration/worker/pki-worker) for storage of authentication
 keys. It is optional for PKI workers; if not specified the authentication keys
 will not be encrypted on disk. This is not used by KMS workers.

@@ -39,7 +39,7 @@ The current scoped DEKs and their purposes are detailed below:

 - `audit`: This is used to encrypt secret values in the event log. For more
  information about the event log, refer to
-  [the events config](/docs/configuration/events).
+  [the events config](/boundary/docs/configuration/events).

 - `database`: This is the general-purpose DEK used to encrypt values within the
  database. Values that are encrypted are those generally considered to be
@@ -116,9 +116,9 @@ rotate and rewrap the KEKs to complete the migration to the new root key.

 The `worker-auth` KMS key is a key shared by the Controller and Worker in order
 to authenticate a Worker to the Controller. Specifics of this mechanism can be
-found on the [Connections/TLS page](/docs/concepts/security/connections-tls). If
+found on the [Connections/TLS page](/boundary/docs/concepts/security/connections-tls). If
 a worker is used with [PKI
-authentication](/docs/configuration/worker/pki-worker) this is unnecessary.
+authentication](/boundary/docs/configuration/worker/pki-worker) this is unnecessary.

 ## The `recovery` KMS Key <sup>OSS Only</sup>

@@ -15,7 +15,7 @@ model's fundamental concepts, provides examples of the specific forms of allowed
 grants, and contains a table that acts as an easy cheat sheet to help those new
 to its grant syntax with crafting roles.

-Boundary's [domain model](/docs/concepts/domain-model) is based on resource
+Boundary's [domain model](/boundary/docs/concepts/domain-model) is based on resource
 types. These can be implemented directly, such as with targets, or they can be
 abstract types that are implemented by concrete types within the system. As an
 example of the latter, a host catalog is an abstract type and a Static host
@@ -12,7 +12,7 @@ permissions. Note that it's not exhaustive; for brevity it does _not_ show
 wildcard or templated grant strings.

 Additionally, this does not include available output fields; see the [service
-documentation](https://www.boundaryproject.io/api-docs) for guidance.
+documentation](/boundary/api-docs) for guidance.

 <!-- BEGIN TABLE -->

@@ -21,20 +21,20 @@ as hosts.

 Boundary supports target/service discovery in three primary workflows: 

-**[Manual configuration](https://learn.hashicorp.com/tutorials/boundary/oss-manage-targets)**: 
+**[Manual configuration](/boundary/tutorials/oss-administration/oss-manage-targets)**: 
 Boundary administrators can manually configure static 
 hosts and targets via the administrator UI and CLI. Manual configuration of 
 targets with static hosts requires knowledge of the IP address or endpoint used 
 to connect to a host.

-**[Service discovery via configuration as code with Terraform](https://learn.hashicorp.com/tutorials/boundary/oss-getting-started-config)**: 
+**[Service discovery via configuration as code with Terraform](/boundary/tutorials/oss-getting-started/oss-getting-started-config)**: 
 Boundary is fully programmatically instrumented and the discovery and configuration of new 
 infrastructure targets can be automated with 
 [Boundary’s Terraform provider](https://registry.terraform.io/providers/hashicorp/boundary/latest/docs). 
 This allows for dynamic configuration of a host and target without the need 
 for prior knowledge of the target’s connection info. 

-**[Runtime service discovery via dynamic host catalogs](https://learn.hashicorp.com/tutorials/boundary/azure-host-catalogs)**: 
+**[Runtime service discovery via dynamic host catalogs](/boundary/tutorials/access-management/azure-host-catalogs)**: 
 Boundary dynamic host catalogs automate the ingestion of resources from 
 infrastructure providers into Boundary. Boundary hosts are automatically 
 created, updated and added to host sets in order to reflect the connection 
@@ -49,11 +49,11 @@ securely query infrastructure providers at runtime to discover and configure
 new services. Boundary dynamic host catalogs are written in go-plugin and run 
 as separate processes. Boundary administrators can define rules for which 
 external resources should be ingested into the catalog by 
-[creating dynamic host](https://www.boundaryproject.io/docs/concepts/domain-model/host-sets)
+[creating dynamic host](/boundary/docs/concepts/domain-model/host-sets)
 sets with an attributes filter. Attributes specify the fields which the plugin 
 should use to lookup which hosts should be members of this host set.

 Currently, Boundary supports dynamic host catalog implementations for AWS and 
 Azure and we will continue to grow this ecosystem to support additional providers. 

-You can get started with dynamic host catalogs [here](https://learn.hashicorp.com/tutorials/boundary/azure-host-catalogs).
+You can get started with dynamic host catalogs [here](/boundary/tutorials/access-management/azure-host-catalogs).
@@ -157,7 +157,7 @@ kms "aead" {
 ```

 Boundary supports many kinds of KMS integrations. For a complete guide to all available
-KMS types, see our [KMS documentation](/docs/configuration/kms).
+KMS types, see our [KMS documentation](/boundary/docs/configuration/kms).

 # Complete Configuration Example

@@ -22,11 +22,11 @@ These parameters are shared across all sink types:

 - `allow_filters` - Specifies a set of predicates for including an event in the
  sink. If any filter matches, the event will be included. For more information,
-  on using filters see: [event filtering](/docs/concepts/filtering/events)
+  on using filters see: [event filtering](/boundary/docs/concepts/filtering/events)

 - `deny-filters` - Specifies a set predicates for excluding an event in the
  sink. If any filter matches, the event will be excluded. For more information
-  on using filters see: [event filtering](/docs/concepts/filtering/events)
+  on using filters see: [event filtering](/boundary/docs/concepts/filtering/events)

 - `format` - Specifies the format for the sink. Can be `cloudevents-json`,
  `cloudevents-text`, `hclog-json`, or `hclog-text`.
@@ -28,7 +28,7 @@ to multiple sinks; however, each file sink must have a unique `path` +

 ## common parameters

-These parameters are shared across all sink types: [common sink parameters](/docs/configuration/events/common)
+These parameters are shared across all sink types: [common sink parameters](/boundary/docs/configuration/events/common)

 ## `file` parameters

@@ -41,8 +41,8 @@ events {
 - `sysevents_enabled` - Specifies if system events should be emitted.

 - `sink` - Specifies the configuration of an event sink. Currently, two types of
-  sink are supported: [file](/docs/configuration/events/file) and [stderr](/docs/configuration/events/stderr). If no sinks are configured then all
-  events will be sent to a default [stderr](/docs/configuration/events/stderr) sink. Events may be sent to multiple
+  sink are supported: [file](/boundary/docs/configuration/events/file) and [stderr](/boundary/docs/configuration/events/stderr). If no sinks are configured then all
+  events will be sent to a default [stderr](/boundary/docs/configuration/events/stderr) sink. Events may be sent to multiple
  sinks.

 ## Default Events Stanza
@@ -21,7 +21,7 @@ sink "stderr" {

 ## common parameters

-These parameters are shared across all sink types: [common sink parameters](/docs/configuration/events/common)
+These parameters are shared across all sink types: [common sink parameters](/boundary/docs/configuration/events/common)

 ## `stderr` parameters

@@ -6,12 +6,12 @@ description: Boundary configuration reference.

 # Configuration

-[listener]: /docs/configuration/listener
-[controller]: /docs/configuration/controller
-[worker]: /docs/configuration/worker
-[kms]: /docs/configuration/kms
-[plugins]: /docs/configuration/plugins
-[events]: /docs/configuration/events
+[listener]: /boundary/docs/configuration/listener
+[controller]: /boundary/docs/configuration/controller
+[worker]: /boundary/docs/configuration/worker
+[kms]: /boundary/docs/configuration/kms
+[plugins]: /boundary/docs/configuration/plugins
+[events]: /boundary/docs/configuration/events

 Outside of development mode, Boundary controllers and workers are configured
 using a file. The format of this file is
@@ -29,10 +29,10 @@ path to the file.

 ## Shared OSS and HCP Boundary Parameters

- [`worker`](/docs/configuration/worker): Worker specific configuration. If
+- [`worker`](/boundary/docs/configuration/worker): Worker specific configuration. If
  present, `boundary server` will start a Worker subprocess.

- [`listener`](/docs/configuration/listener): Configures the listeners on which
+- [`listener`](/boundary/docs/configuration/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
@@ -43,10 +43,10 @@ path to the file.
  Optionally, the `ops` purpose listener block serves as a higher-level listener
  where Boundary's operational endpoints live (eg: /health).

- [`kms`](/docs/configuration/kms): Configures KMS blocks [for various
-  purposes](/docs/concepts/security/data-encryption).
+- [`kms`](/boundary/docs/configuration/kms): Configures KMS blocks [for various
+  purposes](/boundary/docs/concepts/security/data-encryption).

- [`events`](/docs/configuration/events): Configures event (observability,
+- [`events`](/boundary/docs/configuration/events): Configures event (observability,
  audit, error) handling.

 - `disable_mlock` `(bool: false)` – Disables the server from executing the
@@ -82,13 +82,13 @@ path to the file.

 ## OSS-Only Parameters

- [`controller`](/docs/configuration/controller): Controller specific
+- [`controller`](/boundary/docs/configuration/controller): Controller specific
  configuration. If present, `boundary server` will start a Controller subprocess.

- [`plugins`](/docs/configuration/plugins): Configures options for plugins.
+- [`plugins`](/boundary/docs/configuration/plugins): Configures options for plugins.

 ## Example Configurations

 For complete example configurations see the sections for
-[controller](/docs/configuration/controller) and
-[worker](/docs/configuration/worker).
+[controller](/boundary/docs/configuration/controller) and
+[worker](/boundary/docs/configuration/worker).
@@ -45,7 +45,7 @@ These parameters apply to the `kms` stanza in the Boundary configuration file:
 Authentication-related values must be provided, either as environment
 variables or as configuration parameters.

-If you want to use Instance Principal, add section configuration below and add further configuration settings as detailed in the [configuration docs](/docs/configuration/).
+If you want to use Instance Principal, add section configuration below and add further configuration settings as detailed in the [configuration docs](/boundary/docs/configuration/).

 ```hcl
 kms "ocikms" {
@@ -10,7 +10,7 @@ description: |-

 The `listener` stanza configures the addresses and ports on which Boundary will
 respond to requests. At this time, there are two listener types:
-[TCP](/docs/configuration/listener/tcp) and [Unix](/docs/configuration/listener/unix).
+[TCP](/boundary/docs/configuration/listener/tcp) and [Unix](/boundary/docs/configuration/listener/unix).


 ## `listener` Purpose
@@ -147,7 +147,7 @@ for serving content to a web browser, such as CSP headers.
 ~> `tls` parameters are valid for `api` and `ops` listeners. `cluster`
 and `proxy` connections use their own ephemeral TLS stacks. For more 
 information, see [the connections security concepts
-page](https://www.boundaryproject.io/docs/concepts/security/connections-tls).
+page](/boundary/docs/concepts/security/connections-tls).

 - `tls_disable` `(string: "false")` – Specifies if TLS will be disabled. Boundary
  assumes TLS by default, so you must explicitly disable TLS to opt-in to
@@ -336,5 +336,5 @@ listener "tcp" {
 ```

 [golang-tls]: https://golang.org/src/crypto/tls/cipher_suites.go
-[api-addr]: /docs/configuration#api_addr
-[cluster-addr]: /docs/configuration#cluster_addr
+[api-addr]: /boundary/docs/configuration#api_addr
+[cluster-addr]: /boundary/docs/configuration#cluster_addr
@@ -90,7 +90,7 @@ allowed.
 ~> `tls` parameters are valid for `api` and `ops` listeners. `cluster`
 and `proxy` connections use their own ephemeral TLS stacks. For more
 information, see [the connections security concepts
-page](https://www.boundaryproject.io/docs/concepts/security/connections-tls).
+page](/boundary/docs/concepts/security/connections-tls).

 - `tls_disable` `(string: "false")` – Specifies if TLS will be disabled. Boundary
  assumes TLS by default, so you must explicitly disable TLS to opt-in to
@@ -196,5 +196,5 @@ listener "tcp" {
 ```

 [golang-tls]: https://golang.org/src/crypto/tls/cipher_suites.go
-[api-addr]: /docs/configuration#api_addr
-[cluster-addr]: /docs/configuration#cluster_addr
+[api-addr]: /boundary/docs/configuration#api_addr
+[cluster-addr]: /boundary/docs/configuration#cluster_addr
@@ -56,10 +56,10 @@ worker {
  "192.168.0.1", "10.0.0.1"]`

 - `tags` - A map of key-value pairs where values are an array of strings. Most
-  commonly used for [filtering](/docs/concepts/filtering) targets a worker can
-  proxy via [worker tags](/docs/concepts/filtering/worker-tags). On `SIGHUP`, the
+  commonly used for [filtering](/boundary/docs/concepts/filtering) targets a worker can
+  proxy via [worker tags](/boundary/docs/concepts/filtering/worker-tags). On `SIGHUP`, the
  tags set here will be re-parsed and new values used. It can also be a string
  referring to a file on disk (`file://`) or an env var (`env://`).

-[kms workers]: /docs/configuration/worker/kms-worker
-[pki workers]: /docs/configuration/worker/pki-worker
+[kms workers]: /boundary/docs/configuration/worker/kms-worker
+[pki workers]: /boundary/docs/configuration/worker/pki-worker
@@ -58,7 +58,7 @@ kms "aead" {
 ```

 Boundary supports many kinds of KMS integrations. For a complete guide to all available
-KMS types, see our [KMS documentation](/docs/configuration/kms).
+KMS types, see our [KMS documentation](/boundary/docs/configuration/kms).

 # Complete Configuration Example

@@ -98,11 +98,11 @@ kms "aead" {
 }
 ```

-[`initial_upstreams`](/docs/configuration/worker/overview#initial_upstreams)
+[`initial_upstreams`](/boundary/docs/configuration/worker/overview#initial_upstreams)
 are used to connect to upstream Boundary clusters.

 ## Resources

 For more on how `tags{}` in the above configuration are used to facilitate
 routing to the correct target, refer to the [Worker
-Tags](/docs/concepts/filtering/worker-tags) page.
+Tags](/boundary/docs/concepts/filtering/worker-tags) page.
@@ -140,10 +140,10 @@ kms "aead" {


 ```
-[kms workers]: /docs/configuration/worker/kms-worker
-[target]: /docs/concepts/domain-model/targets
-[target worker filters]: /docs/concepts/filtering/worker-tags
+[kms workers]: /boundary/docs/configuration/worker/kms-worker
+[target]: /boundary/docs/concepts/domain-model/targets
+[target worker filters]: /boundary/docs/concepts/filtering/worker-tags

 ## Tutorial

-Refer to the [Self-Managed Worker Registration with HCP Boundary](https://learn.hashicorp.com/tutorials/boundary/hcp-manage-workers) tutorial to learn how to register and manage PKI workers.
+Refer to the [Self-Managed Worker Registration with HCP Boundary](/boundary/tutorials/hcp-administration/hcp-manage-workers) tutorial to learn how to register and manage PKI workers.
@@ -8,7 +8,7 @@ description: |-
 # Connect to Your First Target

 The [Quick setup
-wizard](/docs/getting-started/deploy-and-login#login-to-hcp-boundary)
+wizard](/boundary/docs/getting-started/deploy-and-login#login-to-hcp-boundary)
 is the fastest way to onboard a target to HCP Boundary.

 ![Setup Wizard](/img/setup-wizard-target.png)
@@ -224,10 +224,10 @@ proxy details.

 ## Tutorial

-Refer to the [Connect to your First Target](https://learn.hashicorp.com/tutorials/boundary/hcp-getting-started-connect?in=boundary/hcp-getting-started) tutorial for steps on how to create a host catalog, host set, and a target in Boundary.
+Refer to the [Connect to your First Target](/boundary/tutorials/hcp-getting-started/hcp-getting-started-connect) tutorial for steps on how to create a host catalog, host set, and a target in Boundary.

 ## Next Steps

 Refer to our [basic administration
-workflows](https://learn.hashicorp.com/collections/boundary/hcp-administration) tutorial series
+workflows](/boundary/tutorials/hcp-administration) tutorial series
 for in depth discussions on managing scopes, targets, identities, and sessions.
@@ -21,15 +21,15 @@ To get started with HCP Boundary, users need:

 - A [HashiCorp Cloud Platform](https://portal.cloud.hashicorp.com/sign-up)
  account
- [Installation](https://learn.hashicorp.com/tutorials/boundary/hcp-getting-started-install)
+- [Installation](/boundary/tutorials/hcp-getting-started/hcp-getting-started-install)
  of the Boundary CLI
- A [Boundary binary](https://www.boundaryproject.io/downloads) in your `$PATH`
+- A [Boundary binary](/boundary/downloads) in your `$PATH`
 - Optionally, an [installation of Boundary
-  Desktop](https://learn.hashicorp.com/tutorials/boundary/hcp-getting-started-desktop-app)
+  Desktop](/boundary/tutorials/hcp-getting-started/hcp-getting-started-desktop-app)

 If you prefer to get started on your local machine, refer to [Run and Login in
-Dev Mode](/docs/oss/installing/run-and-login). For more information on Boundary
-OSS and self-managed installations, refer to [Boundary OSS](/docs/oss).
+Dev Mode](/boundary/docs/oss/installing/run-and-login). For more information on Boundary
+OSS and self-managed installations, refer to [Boundary OSS](/boundary/docs/oss).

 ## Deploy an HCP Boundary Cluster

@@ -138,7 +138,7 @@ help pages.
 <Tab heading="Desktop Client">


-[Boundary Desktop](https://www.boundaryproject.io/downloads) can be used to
+[Boundary Desktop](/boundary/downloads) can be used to
 connect to HCP Boundary.

 To get started with Boundary Desktop:
@@ -209,15 +209,15 @@ To find your environment’s default `auth_method_id`:
 ## Tutorial

 - Refer to the [Create a Boundary Instance on
-  HCP](https://learn.hashicorp.com/tutorials/boundary/hcp-getting-started-create)
+  HCP](/boundary/tutorials/hcp-getting-started/hcp-getting-started-create)
  tutorial to learn how to deploy a Boundary instance.
 - Refer to the [Install Boundary
-  Desktop](https://learn.hashicorp.com/tutorials/boundary/hcp-getting-started-desktop-app)
+  Desktop](/boundary/tutorials/hcp-getting-started/hcp-getting-started-desktop-app)
  tutorial to learn how to use the Boundary desktop to connect to a running HCP
  Boundary instance.


 ## Next Steps

-See [connecting to your first target](/docs/getting-started/connect-to-target)
+See [connecting to your first target](/boundary/docs/getting-started/connect-to-target)
 for how to use HCP Boundary to run your first SSH session.
@@ -16,20 +16,20 @@ There are two options to get started with Boundary:
  available as a freemium service. HCP Boundary allows users to run their own
  worker proxies, preventing exposure of your network to HashiCorp or clients.
  Some enterprise features are only available with HCP Boundary. Review the [Get
-  started with HCP Boundary](/docs/getting-started/deploy-and-login) page to
+  started with HCP Boundary](/boundary/docs/getting-started/deploy-and-login) page to
  learn more.
 - **Boundary OSS** is an open source distribution of Boundary that users can run
  in their own environments. The [Getting Started with Boundary
-  OSS](/docs/oss/installing/dev-mode) page discusses running Boundary
+  OSS](/boundary/docs/oss/installing/dev-mode) page discusses running Boundary
  in Dev mode on your local machine, allowing you to get started with the OSS distribution quickly.

 We recommend you use the Boundary model that best meets your intended use case.
 If you’re not sure what’s best for you, we recommend reviewing the [Getting
-started with HCP Boundary](/docs/getting-started/deploy-and-login) page.
+started with HCP Boundary](/boundary/docs/getting-started/deploy-and-login) page.

 # Key Concepts

 Before getting started with Boundary, it's important to understand a few key
-concepts. Please consult our [Boundary concepts](/docs/concepts) page to
+concepts. Please consult our [Boundary concepts](/boundary/docs/concepts) page to
 familiarize yourself with Boundary's architecture and terminology.

@@ -8,6 +8,6 @@ description: Boundary reference documentation

 Welcome to the Boundary reference documentation! The documentation is reference material for Boundary's concepts and available features.

- Get started using Boundary with our [step-by-step onboarding tutorial](https://learn.hashicorp.com/boundary) at HashiCorp Learn.
- Install Boundary by using a precompiled binary or building from source with the documentation [here](/docs/getting-started/)
- Learn about Boundary's [core concepts](/docs/concepts/) for how identities, permissions, and resources are organized.
+- Get started using Boundary with our [step-by-step onboarding tutorial](/boundary/tutorials) at HashiCorp Learn.
+- Install Boundary by using a precompiled binary or building from source with the documentation [here](/boundary/docs/getting-started/)
+- Learn about Boundary's [core concepts](/boundary/docs/concepts/) for how identities, permissions, and resources are organized.
@@ -28,4 +28,4 @@ Boundary does not require an agent to be installed on the end host.

 ## Tutorial

-Refer to the [Get Started with self-hosted Boundary](https://learn.hashicorp.com/collections/boundary/oss-getting-started) tutorial series to learn how to install and configure Boundary.
+Refer to the [Get Started with self-hosted Boundary](/boundary/tutorials/oss-getting-started) tutorial series to learn how to install and configure Boundary.
@@ -30,7 +30,7 @@ boundary connect -target-id ttcp_0987654321

 For the purpose of this guide, both of these targets accomplish the same goal,
 however they have different purposes. Refer to the
-[domain](/docs/concepts/domain-model/index) documentation for more information.
+[domain](/boundary/docs/concepts/domain-model/index) documentation for more information.

 For the rest of this guide, assume the default is used.

@@ -216,5 +216,5 @@ proxy details.
 ## Next Steps

 See our [basic administration
-workflows](https://learn.hashicorp.com/collections/boundary/oss-administration)
+workflows](/boundary/tutorials/oss-administration)
 for in depth discussion on managing scopes, targets, identities, and sessions.
@@ -7,14 +7,14 @@ description: Getting started with Boundary OSS in Dev mode
 # What is Dev Mode?

 Before getting started with Boundary OSS, it's important to understand a few key
-concepts. Please consult our [Boundary concepts](/docs/concepts) page to
+concepts. Please consult our [Boundary concepts](/boundary/docs/concepts) page to
 familiarize yourself with Boundary's architecture and terminology.

 Dev mode is a method for getting started with Boundary quickly for testing and
 learning purposes. As the name implies, dev mode is not a production
 installation method, and provides a way to get Boundary running with a Postgres
 database easily. Do not use dev mode in a production environment, see the
-[Production Installation](/docs/oss/installing/high-availability) section for
+[Production Installation](/boundary/docs/oss/installing/high-availability) section for
 production-ready deployment methods.

 Dev mode brings up a fully-functioning instance of Boundary, including:
@@ -28,22 +28,22 @@ across dev mode restarts. Along with these external components, dev mode also
 creates several resources within Boundary to make it easier and faster to
 connect to your first target:

-1. An org [scope](/docs/concepts/domain-model/scopes) and a project scope with a
+1. An org [scope](/boundary/docs/concepts/domain-model/scopes) and a project scope with a
   default ID of `o_1234567890` and `p_1234567890` respectively.
-1. A password [auth method](/docs/concepts/domain-model/auth-methods) with a
+1. A password [auth method](/boundary/docs/concepts/domain-model/auth-methods) with a
   default auth method ID of `ampw_1234567890`.
-1. An OIDC [auth method](/docs/concepts/domain-model/auth-methods) with a
+1. An OIDC [auth method](/boundary/docs/concepts/domain-model/auth-methods) with a
   default auth method ID of `amoidc_1234567890`.
 1. An admin user with login name `admin` and password `password`.
 1. An unprivileged user with login name `user` and password `password`.
-1. A static [host catalog](/docs/concepts/domain-model/host-catalogs) with a
+1. A static [host catalog](/boundary/docs/concepts/domain-model/host-catalogs) with a
   default ID of `hcst_1234567890`.
-1. A static [host](/docs/concepts/domain-model/hosts) and [host
-   set](/docs/concepts/domain-model/host-sets) with default ID's of
+1. A static [host](/boundary/docs/concepts/domain-model/hosts) and [host
+   set](/boundary/docs/concepts/domain-model/host-sets) with default ID's of
   `hst_1234567890` and `hsst_1234567890` respectively.
-1. A TCP [target](/docs/concepts/domain-model/targets) with a default ID of
+1. A TCP [target](/boundary/docs/concepts/domain-model/targets) with a default ID of
   `ttcp_1234567890`, directly set-up with an address and port.
-1. A TCP [target](/docs/concepts/domain-model/targets) with a default ID of
+1. A TCP [target](/boundary/docs/concepts/domain-model/targets) with a default ID of
   `ttcp_0987654321` using the previously mentioned static host set.

 The default ID suffixes can be overwritten or randomly generated, and there are
@@ -64,7 +64,7 @@ There are a few requirements for running dev mode:
 - A route to download the [Postgres Docker
   image](https://hub.docker.com/_/postgres) is available or a local image cache
   is available
- A [Boundary binary](https://www.boundaryproject.io/downloads) in your `$PATH`
+- A [Boundary binary](/boundary/downloads) in your `$PATH`
 - _Optionally_, an [installation of Boundary
-   Desktop](https://learn.hashicorp.com/tutorials/boundary/oss-getting-started-desktop-app)
+   Desktop](/boundary/tutorials/oss-getting-started/oss-getting-started-desktop-app)
   if you want to use the desktop examples
@@ -46,4 +46,4 @@ For general configuration, we recommend the following:

 When running Boundary controller as a service we recommend storing the file at `/etc/boundary-controller.hcl`. A `boundary` user and group should exist to manage this configuration file and to further restrict who can read and modify it.

-For detailed configuration options, see our [configuration docs](/docs/configuration).
+For detailed configuration options, see our [configuration docs](/boundary/docs/configuration).
@@ -9,6 +9,6 @@ description: |-

 This section covers installing Boundary for different modes of operation and across different environments

-For community-supported reference architectures, please see [Reference Architectures](/docs/oss/installing/reference-architectures).
+For community-supported reference architectures, please see [Reference Architectures](/boundary/docs/oss/installing/reference-architectures).

 ![Boundary Architecture](/img/architecture-overview.png)
@@ -47,7 +47,7 @@ kms "aead" {
 ```

 In this example, we're using hardcoded AEAD keys, but in a real world non-dev deployment, you
-should use your cloud provider's KMS such as [AWS KMS](/docs/configuration/kms/awskms) to manage the keys Boundary
+should use your cloud provider's KMS such as [AWS KMS](/boundary/docs/configuration/kms/awskms) to manage the keys Boundary
 uses to encrypt sensitive information.

 The KMS block we're focused on is the `recovery` block. This block specifies the key used to "recover" Boundary
@@ -17,7 +17,7 @@ Boundary has only been tested on Postgres 11 or greater.

 Boundary controllers must be able to reach Postgres.
 In non-HA configurations, this means Boundary servers;
-if you're running in [high availability](/docs/oss/installing/high-availability),
+if you're running in [high availability](/boundary/docs/oss/installing/high-availability),
 then the controllers need access to the Postgres server infrastructure.
 Worker nodes never need access to the database.

@@ -111,5 +111,5 @@ the Boundary server does not use TLS in development mode.
 ## Next Steps

 See [connecting to your first
-target](/docs/oss/installing/connect-to-dev-target) for how to use Boundary to
+target](/boundary/docs/oss/installing/connect-to-dev-target) for how to use Boundary to
 run your first SSH session.
@@ -15,7 +15,7 @@ This section covers how to install Boundary under the [systemd](https://systemd.

 1. `/etc/boundary-${TYPE}.hcl`: Configuration file for the boundary service.

-2. `/usr/local/bin/boundary`: The Boundary binary, which can be built from the [source](https://github.com/hashicorp/boundary) or downloaded from our [release page](https://www.boundaryproject.io/downloads).
+2. `/usr/local/bin/boundary`: The Boundary binary, which can be built from the [source](https://github.com/hashicorp/boundary) or downloaded from our [release page](/boundary/downloads).

 3. `/etc/systemd/system/boundary-${TYPE}.service`: Systemd unit file for the Boundary service.

@@ -59,7 +59,7 @@ All responses return empty bodies. `GET /health` does not support any input.

 Health checks are available for a controller defined with a `purpose = "ops"`
 listener stanza. For details on what fields are allowed in this stanza, refer to
-the documentation about [TCP Listener](/docs/configuration/listener/tcp).
+the documentation about [TCP Listener](/boundary/docs/configuration/listener/tcp).

 An example listener stanza:

@@ -96,5 +96,5 @@ controller {
 ```

 A complete example can be viewed under the [Controller
-configuration](/docs/configuration/controller#complete-configuration-example)
+configuration](/boundary/docs/configuration/controller#complete-configuration-example)
 docs.
@@ -21,7 +21,7 @@ used. Additionally, the health of controllers can be monitored using the
 Boundary's configuration file, and a health response may be configured to add a
 shutdown grace period process.

-* Refer to the [Metrics](/docs/oss/operations/metrics) documentation to learn
+* Refer to the [Metrics](/boundary/docs/oss/operations/metrics) documentation to learn
  more about Boundary metrics.
-* Refer to the [Health Endpoint](/docs/oss/operations/health) documentation to
+* Refer to the [Health Endpoint](/boundary/docs/oss/operations/health) documentation to
  learn more about Boundary health endpoints.
@@ -83,7 +83,7 @@ measurements collected.
 Defining a listener stanza in the config file is sufficient for enabling metrics
 reporting in Boundary. For details on what fields are allowed in this stanza,
 refer to the documentation about [TCP
-Listener](/docs/configuration/listener/tcp).
+Listener](/boundary/docs/configuration/listener/tcp).

 An example listener stanza:

@@ -97,5 +97,5 @@ listener "tcp" {
 ## Tutorial

 Refer to the [Prometheus
-Metrics](https://learn.hashicorp.com/tutorials/boundary/prometheus-metrics)
+Metrics](/boundary/tutorials/oss-configuration/prometheus-metrics)
 tutorial for a step-by-step introduction to metrics.
@@ -6,7 +6,7 @@ description: A list of Boundary use cases

 # Use Cases

-Before understanding use cases, it's useful to know [what Boundary is](/docs/overview/what-is-boundary). This page lists some concrete use cases for Boundary, but the possible use cases are much broader than what we cover.
+Before understanding use cases, it's useful to know [what Boundary is](/boundary/docs/overview/what-is-boundary). This page lists some concrete use cases for Boundary, but the possible use cases are much broader than what we cover.


 ## Zero Trust access
@@ -12,7 +12,7 @@ Is one a replacement for another?
 Are they complementary?
 In this section, we compare Boundary to other available security solutions.

-We also recommend referring to [What is Boundary](/docs/overview/what-is-boundary) and [Why Boundary](/docs/overview/what-is-boundary#why-boundary) for a better understanding of Boundary and the problems that it solves.
+We also recommend referring to [What is Boundary](/boundary/docs/overview/what-is-boundary) and [Why Boundary](/boundary/docs/overview/what-is-boundary#why-boundary) for a better understanding of Boundary and the problems that it solves.

 Use the navigation to the left to read the comparison of Boundary to specific technologies.

@@ -18,11 +18,11 @@ Where Boundary differs from traditional PAM solutions is in its automation-frien
 Boundary is instrumented programmatically via REST, CLI, and [Terraform](https://registry.terraform.io/providers/hashicorp/boundary/latest/docs).
 It provides automation-friendly workflows for managing users and credentials, as well as the discovery and configuration of new services:

- **Automated credential management**: Boundary and Vault can create workflows with automated credential management in which user sessions are secured with [single-use dynamic credentials that are injected into sessions](https://developer.hashicorp.com/boundary/tutorials/access-management/hcp-private-vault-cred-injection) such that secrets are never returned to users.
+- **Automated credential management**: Boundary and Vault can create workflows with automated credential management in which user sessions are secured with [single-use dynamic credentials that are injected into sessions](/boundary/tutorials/access-management/hcp-private-vault-cred-injection) such that secrets are never returned to users.
 - **Context-based access**: When users' business context changes, you want to ensure their permissions reflect the new business context.
 As an example, on-call engineers might require different permissions than when they end their on-call shifts.
-[Boundary's managed groups](https://developer.hashicorp.com/boundary/tutorials/access-management/oidc-idp-groups) enable user permission workflows to be assigned dynamically based on identity provider MFA checks, group memberships, and other IDP-level context.
- **[Service discovery](docs/concepts/service-discovery)**: Boundary's [dynamic host catalogs](https://developer.hashicorp.com/boundary/tutorials/access-management/aws-host-catalogs) are advanced workflows for automating the process of onboarding new or changed infrastructure resources and their connection information, and applying pre-configured security policies.
+[Boundary's managed groups](/boundary/tutorials/access-management/oidc-idp-groups) enable user permission workflows to be assigned dynamically based on identity provider MFA checks, group memberships, and other IDP-level context.
+- **[Service discovery](/boundary/docs/concepts/service-discovery)**: Boundary's [dynamic host catalogs](/boundary/tutorials/access-management/aws-host-catalogs) are advanced workflows for automating the process of onboarding new or changed infrastructure resources and their connection information, and applying pre-configured security policies.

 _Can Boundary replace a PAM solution?_

@@ -8,4 +8,4 @@ description: Compares Boundary to using a Software Defined Perimeter solution

 Software Defined Perimeter (SDP) solutions secure access to applications and infrastructure based on user identity.
 Boundary is fundamentally an SDP solution that takes a zero trust approach to security design for system access; access to services is granted based on the scoped identity and intent of a user.
-Boundary is a scalable proxy that enables identity-based access with multiple layers of security controls including [dynamic credentials](https://developer.hashicorp.com/boundary/tutorials/hcp-administration/hcp-ssh-cred-injection), [context-based access](https://developer.hashicorp.com/boundary/tutorials/access-management/oidc-idp-groups), [automated service discovery](docs/concepts/service-discovery), and [access auditing](https://developer.hashicorp.com/hcp/docs/boundary/audit-logging) to name a few.
+Boundary is a scalable proxy that enables identity-based access with multiple layers of security controls including [dynamic credentials](/boundary/tutorials/hcp-administration/hcp-ssh-cred-injection), [context-based access](/boundary/tutorials/access-management/oidc-idp-groups), [automated service discovery](/boundary/docs/concepts/service-discovery), and [access auditing](/hcp/docs/boundary/audit-logging) to name a few.
@@ -53,45 +53,45 @@ The key features and concepts of Boundary include:
 Identity is a core concept in Boundary. Identity is represented by two types of
 resources, mapping to common security principals:

- [Users](/docs/concepts/domain-model/users), which represent distinct entities
+- [Users](/boundary/docs/concepts/domain-model/users), which represent distinct entities
  that can be tied to authentication accounts
- [Groups](/docs/concepts/domain-model/groups), which are collections of users
+- [Groups](/boundary/docs/concepts/domain-model/groups), which are collections of users
  that allow for easier access management

-[Roles](/docs/concepts/domain-model/roles) map users and groups to a set of
-[grants](/docs/concepts/security/permissions), which provides the ability to
+[Roles](/boundary/docs/concepts/domain-model/roles) map users and groups to a set of
+[grants](/boundary/docs/concepts/security/permissions), which provides the ability to
 perform actions within the system.

 ### Resource Management

 Boundary enables flexible management of the hosts and services to
 broker access. Boundary administrators define [host
-catalogs](/docs/concepts/domain-model/host-catalogs) containing information
-about [hosts](/docs/concepts/domain-model/hosts). The cataloged hosts are collected
-into [host sets](/docs/concepts/domain-model/host-sets) that represent sets of
-equivalent hosts. Finally, [targets](/docs/concepts/domain-model/targets) tie
+catalogs](/boundary/docs/concepts/domain-model/host-catalogs) containing information
+about [hosts](/boundary/docs/concepts/domain-model/hosts). The cataloged hosts are collected
+into [host sets](/boundary/docs/concepts/domain-model/host-sets) that represent sets of
+equivalent hosts. Finally, [targets](/boundary/docs/concepts/domain-model/targets) tie
 together host sets with connection information. Access to a resource is
-granted via [roles](/docs/concepts/domain-model/roles) that provide
+granted via [roles](/boundary/docs/concepts/domain-model/roles) that provide
 authorization to create sessions against these targets.

 ### Filtering

 Parts of Boundary support filters for various purposes. For a description
-of the filter syntax, see the [filtering](/docs/concepts/filtering) page. See
+of the filter syntax, see the [filtering](/boundary/docs/concepts/filtering) page. See
 the docs pages for the individual resources or capabilities where filters are
 supported for the specific inputs and examples with those inputs.

-> **Tip**: Learn more about Boundary [use cases](/docs/overview/use-cases).
+-> **Tip**: Learn more about Boundary [use cases](/boundary/docs/overview/use-cases).

 ## What is HCP Boundary?

-Boundary offers two types of deployment options. A first option is an *OSS self-managed* deployment solution as discussed above. A self-managed approach enables organizations to proxy all session data through their own network while still providing the convenience of a managed service. A second option is an *HCP-managed* deployment solution where both the control plan and worker nodes are managed by HashiCorp. With this managed solution, an option of private workers is offered. **HCP Boundary** is a fully-managed, cloud-based workflow that enables secure connections to remote hosts and critical systems across cloud and on-premise environments. Refer to the [HCP Boundary](https://cloud.hashicorp.com/docs/boundary) documentation to learn more.
+Boundary offers two types of deployment options. A first option is an *OSS self-managed* deployment solution as discussed above. A self-managed approach enables organizations to proxy all session data through their own network while still providing the convenience of a managed service. A second option is an *HCP-managed* deployment solution where both the control plan and worker nodes are managed by HashiCorp. With this managed solution, an option of private workers is offered. **HCP Boundary** is a fully-managed, cloud-based workflow that enables secure connections to remote hosts and critical systems across cloud and on-premise environments. Refer to the [HCP Boundary](/hcp/docs/boundary) documentation to learn more.

-> **Hands On:** Try the [Create a Boundary Instance on HCP](https://learn.hashicorp.com/tutorials/boundary/hcp-getting-started-create?in=boundary/hcp-getting-started) tutorial to deploy an HCP Boundary instance.
+-> **Hands On:** Try the [Create a Boundary Instance on HCP](/boundary/tutorials/hcp-getting-started/hcp-getting-started-create) tutorial to deploy an HCP Boundary instance.

 ## Tutorial

-Refer to the [Boundary tutorials](https://learn.hashicorp.com/boundary) to learn how to set up, configure, and administer Boundary.
+Refer to the [Boundary tutorials](/boundary/tutorials) to learn how to set up, configure, and administer Boundary.

 ## Community

@@ -5,13 +5,13 @@ description: |-
  Boundary release notes for v0.10.0
 ---

-# [Boundary v0.10.0](https://www.boundaryproject.io/downloads)
+# [Boundary v0.10.0](/boundary/downloads)

 The release notes below contain information about new functionality available in the Boundary v0.10.0 release.
 To see a granular record of when each item was merged into the Boundary project, please refer to the [Changelog](https://github.com/hashicorp/boundary/blob/main/CHANGELOG.md).
-To learn about what Boundary consists of, we highly recommend you start at the [Getting Started Page](/docs/getting-started).
+To learn about what Boundary consists of, we highly recommend you start at the [Getting Started Page](/boundary/docs/getting-started).

-Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.10.0, please review Boundary's [general upgrade guide](https://learn.hashicorp.com/tutorials/boundary/upgrade-version).
+Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.10.0, please review Boundary's [general upgrade guide](/boundary/tutorials/oss-configuration/upgrade-version).

 ## Boundary v0.10.0 Highlights

@@ -25,7 +25,7 @@ without having to manually enter their brokered credentials.
 project scope to resources such as group members and principals that reside in other scopes.

 **SSH Credential Injection via Password and Public Key Authentication:** HCP Boundary now supports SSH Credential Injection, an active method of injecting credentials into an 
-established connection, so that credentials are never exposed to users. [Learn more here](https://learn.hashicorp.com/tutorials/boundary/hcp-ssh-cred-injection?in=boundary/hcp-administration).
+established connection, so that credentials are never exposed to users. [Learn more here](/boundary/tutorials/hcp-administration/hcp-ssh-cred-injection).



@@ -5,14 +5,14 @@ description: |-
  Boundary release notes for v0.11.0
 ---

-# [Boundary v0.11.0](https://www.boundaryproject.io/downloads)
+# [Boundary v0.11.0](/boundary/downloads)

 The release notes below contain information about new functionality available in the Boundary v0.11.0 release. To see a granular record of when each item was 
 merged into the Boundary project, please refer to the [Changelog](https://github.com/hashicorp/boundary/blob/main/CHANGELOG.md). To learn about what Boundary 
-consists of, we highly recommend you start at the [Getting Started Page](/docs/getting-started).
+consists of, we highly recommend you start at the [Getting Started Page](/boundary/docs/getting-started).

 Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.11.0, please review Boundary's 
-[general upgrade guide](https://learn.hashicorp.com/tutorials/boundary/upgrade-version).
+[general upgrade guide](/boundary/tutorials/oss-configuration/upgrade-version).

 ## Boundary v0.11.0 Highlights

@@ -22,10 +22,10 @@ connect to hosts and critical systems across Kubernetes clusters, cloud service

 **Private Vault Access:** HCP Boundary users are now able to integrate their on-premises instance of Vault without having to publicly expose Vault. This is 
 accomplished by deploying a Boundary worker binary within the same private network as the Vault instance and peering with the HCP Boundary control plane. 
-[Learn more here](https://learn.hashicorp.com/tutorials/boundary/hcp-vault-cred-brokering-quickstart).
+[Learn more here](/boundary/tutorials/access-management/hcp-vault-cred-brokering-quickstart).

 **SSH Credential Injection:** SSH Targets can now be set up through the Admin UI, making the Credential Injection workflow more seamless and easy to use. 
-[Learn more here](https://learn.hashicorp.com/tutorials/boundary/hcp-ssh-cred-injection?in=boundary/hcp-administration).
+[Learn more here](/boundary/tutorials/hcp-administration/hcp-ssh-cred-injection).

 **Improved Worker Management:** Administrators are now able to register and manage Boundary workers through the Admin UI. Admin users can view session counts, 
 IP addresses and release versions of all registered workers through the 'Workers' tab.
@@ -5,19 +5,19 @@ description: |-
  Boundary release notes for v0.1.0
 ---

-# [Boundary v0.1.0](https://www.boundaryproject.io/downloads)
+# [Boundary v0.1.0](/boundary/downloads)

-v0.1.0 is the first release of Boundary. As a result there are no changes, improvements, or bugfixes from past versions. To learn about what Boundary consists of, we highly recommend you start at the [Getting Started Page](/docs/getting-started).
+v0.1.0 is the first release of Boundary. As a result there are no changes, improvements, or bugfixes from past versions. To learn about what Boundary consists of, we highly recommend you start at the [Getting Started Page](/boundary/docs/getting-started).

 ## Boundary v0.1.0 Highlights

 In this initial release, Boundary provides:

 - Password-based authentication
- Authenticated and authorized [TCP-based sessions](/docs/common-workflows/manage-sessions).
- Identity and access management providing [role-based controls](/docs/common-workflows/manage-roles) for principals.
+- Authenticated and authorized [TCP-based sessions](/boundary/docs/common-workflows/manage-sessions).
+- Identity and access management providing [role-based controls](/boundary/docs/common-workflows/manage-roles) for principals.
 - A user interface for administration of Boundary resources.
 - A [Terraform provider](https://github.com/hashicorp/terraform-provider-boundary) for managing Boundary resources.
 - A fully instrumented command line interface for managing Boundary and for establishing and managing sessions.
- A fully instrumented [Boundary golang SDK](/docs/api-clients/go-sdk).
+- A fully instrumented [Boundary golang SDK](/boundary/docs/api-clients/go-sdk).
 - A log of Boundary sessions exposed through Boundary's administrator UI and postgres database.
@@ -5,18 +5,18 @@ description: |-
  Boundary release notes for v0.2.0
 ---

-# [Boundary v0.2.0](https://www.boundaryproject.io/downloads)
+# [Boundary v0.2.0](/boundary/downloads)

-The release notes below contain information about Boundary v0.2.0 as well as new features since Boundary's 0.1.0 that became available in 0.1.x releases. To see a granular record of when each item was merged into the Boundary project, please refer to the [Changelog](https://github.com/hashicorp/boundary/blob/main/CHANGELOG.md). To learn about what Boundary consists of, we highly recommend you start at the [Getting Started Page](/docs/getting-started).
+The release notes below contain information about Boundary v0.2.0 as well as new features since Boundary's 0.1.0 that became available in 0.1.x releases. To see a granular record of when each item was merged into the Boundary project, please refer to the [Changelog](https://github.com/hashicorp/boundary/blob/main/CHANGELOG.md). To learn about what Boundary consists of, we highly recommend you start at the [Getting Started Page](/boundary/docs/getting-started).

-Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.2.0, please review Boundary’s [general upgrade guide](https://learn.hashicorp.com/tutorials/boundary/upgrade-version).
+Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.2.0, please review Boundary’s [general upgrade guide](/boundary/tutorials/oss-configuration/upgrade-version).

 ## Boundary v0.2.0 Highlights

 **Open ID Connect (OIDC) Authentication**: Boundary 0.2 adds support for OIDC authentication methods, which allow users to delegate authentication to an OIDC provider.
 This feature enables Boundary to integrate with popular identity providers like Microsoft Azure Active Directory, Okta,
 cloud identity management systems such as AWS IAM, and others. To get started with creating OIDC auth methods to log into Boundary with common OIDC providers,
-get started with the new [Boundary OIDC learn tutorial](https://learn.hashicorp.com/boundary).
+get started with the new [Boundary OIDC learn tutorial](/boundary/tutorials).

 **Boundary Desktop for MacOS:** Boundary Desktop enables users to use Boundary to access resources through a convenient GUI application. Boundary Desktop enables users to

@@ -26,15 +26,15 @@ get started with the new [Boundary OIDC learn tutorial](https://learn.hashicorp.
 - **Manage sessions:** Users can manage all of their active sessions or drill down to sessions associated with a specific target.
 - **AutoUpdate:** AutoUpdate the Boundary Desktop app as new versions become available.

-**Worker tags & filters (0.1.5):** Enable target traffic to be effectively “tied” to a given set of workers with [worker tags](https://www.boundaryproject.io/docs/concepts/filtering/worker-tags), forcing the session to occur through specified workers for a specific target.
+**Worker tags & filters (0.1.5):** Enable target traffic to be effectively “tied” to a given set of workers with [worker tags](/boundary/docs/concepts/filtering/worker-tags), forcing the session to occur through specified workers for a specific target.

 Improvements to list actions:\*\* There have been numerous improvements to listing actions since Boundary 0.1.0.

- **Resource filtering (0.1.8):** allows users to navigate their resources more easily by [filtering list actions based on resource information](https://www.boundaryproject.io/docs/concepts/filtering/resource-listing).
+- **Resource filtering (0.1.8):** allows users to navigate their resources more easily by [filtering list actions based on resource information](/boundary/docs/concepts/filtering/resource-listing).
 - **Recursive listing (0.1.5):** allows users to recursively list resources across a scope.
 - **List authorizations (0.1.5):** allows users to see what actions they’re authorized to perform against the resources returned in a list command.

-**Database migrations (0.1.5):** Boundary provides an [easy upgrade path](https://learn.hashicorp.com/tutorials/boundary/upgrade-version) with fail-safes in the event of migration issues.
+**Database migrations (0.1.5):** Boundary provides an [easy upgrade path](/boundary/tutorials/oss-configuration/upgrade-version) with fail-safes in the event of migration issues.
 This includes support for database upgrades in a single transaction.

 ## What's Changed
@@ -5,11 +5,11 @@ description: |-
  Boundary release notes for v0.3.0
 ---

-# [Boundary v0.3.0](https://www.boundaryproject.io/downloads)
+# [Boundary v0.3.0](/boundary/downloads)

-The release notes below contain information about Boundary v0.3.0, Boundary Desktop v1.1.0, as well as new features since Boundary's 0.2.0 that became available in 0.2.x releases. To see a granular record of when each item was merged into the Boundary project, please refer to the [Changelog](https://github.com/hashicorp/boundary/blob/main/CHANGELOG.md). To learn about what Boundary consists of, we highly recommend you start at the [Getting Started Page](/docs/getting-started).
+The release notes below contain information about Boundary v0.3.0, Boundary Desktop v1.1.0, as well as new features since Boundary's 0.2.0 that became available in 0.2.x releases. To see a granular record of when each item was merged into the Boundary project, please refer to the [Changelog](https://github.com/hashicorp/boundary/blob/main/CHANGELOG.md). To learn about what Boundary consists of, we highly recommend you start at the [Getting Started Page](/boundary/docs/getting-started).

-Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.3.0, please review Boundary’s [general upgrade guide](https://learn.hashicorp.com/tutorials/boundary/upgrade-version).
+Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.3.0, please review Boundary’s [general upgrade guide](/boundary/tutorials/oss-configuration/upgrade-version).

 ## Boundary v0.3.0 Highlights

@@ -5,19 +5,19 @@ description: |-
  Boundary release notes for v0.4.0
 ---

-# [Boundary v0.4.0](https://www.boundaryproject.io/downloads)
+# [Boundary v0.4.0](/boundary/downloads)

-The release notes below contain information about new functionality available in Boundary v0.4.0. To see a granular record of when each item was merged into the Boundary project, please refer to the [Changelog](https://github.com/hashicorp/boundary/blob/main/CHANGELOG.md). To learn about what Boundary consists of, we highly recommend you start at the [Getting Started Page](/docs/getting-started).
+The release notes below contain information about new functionality available in Boundary v0.4.0. To see a granular record of when each item was merged into the Boundary project, please refer to the [Changelog](https://github.com/hashicorp/boundary/blob/main/CHANGELOG.md). To learn about what Boundary consists of, we highly recommend you start at the [Getting Started Page](/boundary/docs/getting-started).

-Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.4.0, please review Boundary’s [general upgrade guide](https://learn.hashicorp.com/tutorials/boundary/upgrade-version).
+Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.4.0, please review Boundary’s [general upgrade guide](/boundary/tutorials/oss-configuration/upgrade-version).

 ## Boundary v0.4.0 Highlights

 **Session Credential Brokering:** Boundary 0.4, adds a Vault integration for the brokering of [Vault](https://www.vaultproject.io/) secrets to Boundary clients (both command line and desktop clients) for use
-in Boundary sessions. Brokering of Vault secrets is the foundation of Boundary’s larger credential-management story for seamless single sign-on to infrastructure targets. This feature introduces new Boundary resources - [credential stores](https://www.boundaryproject.io/docs/concepts/domain-model/credential-stores), [credential libraries](https://www.boundaryproject.io/docs/concepts/domain-model/credential-libraries), and [credentials](https://www.boundaryproject.io/docs/concepts/domain-model/credentials) -
+in Boundary sessions. Brokering of Vault secrets is the foundation of Boundary’s larger credential-management story for seamless single sign-on to infrastructure targets. This feature introduces new Boundary resources - [credential stores](/boundary/docs/concepts/domain-model/credential-stores), [credential libraries](/boundary/docs/concepts/domain-model/credential-libraries), and [credentials](/boundary/docs/concepts/domain-model/credentials) -
 to support binding credentials with user sessions, as well as surfacing those credentials during session initialization on the command line and in Boundary Desktop.

-**`boundary connect` Credential Brokering Integration:** Additionally, we have started integration into the [boundary connect helpers](https://www.boundaryproject.io/docs/getting-started/connect-to-target), starting in this release with the Postgres helper; if the credential contains a username/password and boundary connect postgres is the helper being used, the command will automatically pass the credentials to the psql process.
+**`boundary connect` Credential Brokering Integration:** Additionally, we have started integration into the [boundary connect helpers](/boundary/docs/getting-started/connect-to-target), starting in this release with the Postgres helper; if the credential contains a username/password and boundary connect postgres is the helper being used, the command will automatically pass the credentials to the psql process.

 **Session Security Improvements:** Boundary workers will now close any existing proxy connections they're handling when they cannot make a status request to the worker. The timeout for this behavior is currenly 15 seconds.

@@ -5,13 +5,13 @@ description: |-
  Boundary release notes for v0.5.0
 ---

-# [Boundary v0.5.0](https://www.boundaryproject.io/downloads)
+# [Boundary v0.5.0](/boundary/downloads)

 The release notes below contain information about new functionality available in Boundary v0.5.0.
 To see a granular record of when each item was merged into the Boundary project, please refer to the [Changelog](https://github.com/hashicorp/boundary/blob/main/CHANGELOG.md).
-To learn about what Boundary consists of, we highly recommend you start at the [Getting Started Page](/docs/getting-started).
+To learn about what Boundary consists of, we highly recommend you start at the [Getting Started Page](/boundary/docs/getting-started).

-Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.5.0, please review Boundary’s [general upgrade guide](https://learn.hashicorp.com/tutorials/boundary/upgrade-version).
+Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.5.0, please review Boundary’s [general upgrade guide](/boundary/tutorials/oss-configuration/upgrade-version).

 ## Boundary v0.5.0 Highlights

@@ -19,7 +19,7 @@ Lastly, for instructions on how to upgrade an existing Boundary deployment to v0
 When enabled, event logs are the only type of logging Boundary performs, meaning standard system information and debug logs will no longer appear in stdout.
 The new structured event logs are filterable by event type and other expressions that users define. Legacy HCLog output is still supported through a user-configurable setting.

-For more about event logging usage, see our [documentation](/docs/configuration/events/overview).
+For more about event logging usage, see our [documentation](/boundary/docs/configuration/events/overview).

 **Credential CRUD operations for Administrative Console:** The 0.5.0 release enables administration to configure Vault credential libraries and Vault credential set resources through the administrative console.
 Vault credential resources allows users to create Boundary sessions with credentials brokered by a Vault deployment.
@@ -5,13 +5,13 @@ description: |-
  Boundary release notes for v0.6.0
 ---

-# [Boundary v0.6.0](https://www.boundaryproject.io/downloads)
+# [Boundary v0.6.0](/boundary/downloads)

 The release notes below contain information about new functionality available in Boundary v0.6.0 and the corresponding Boundary Desktop v1.3.0 and Boundary Terraform Provider v1.0.5 releases.
 To see a granular record of when each item was merged into the Boundary project, please refer to the [Changelog](https://github.com/hashicorp/boundary/blob/main/CHANGELOG.md).
-To learn about what Boundary consists of, we highly recommend you start at the [Getting Started Page](/docs/getting-started).
+To learn about what Boundary consists of, we highly recommend you start at the [Getting Started Page](/boundary/docs/getting-started).

-Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.6.0, please review Boundary’s [general upgrade guide](https://learn.hashicorp.com/tutorials/boundary/upgrade-version).
+Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.6.0, please review Boundary’s [general upgrade guide](/boundary/tutorials/oss-configuration/upgrade-version).

 ## Boundary v0.6.0 Highlights

@@ -5,13 +5,13 @@ description: |-
  Boundary release notes for v0.7.0
 ---

-# [Boundary v0.7.0](https://www.boundaryproject.io/downloads)
+# [Boundary v0.7.0](/boundary/downloads)

 The release notes below contain information about new functionality available in Boundary v0.7.0 and the corresponding Boundary Desktop v1.4.0 release.
 To see a granular record of when each item was merged into the Boundary project, please refer to the [Changelog](https://github.com/hashicorp/boundary/blob/main/CHANGELOG.md).
-To learn about what Boundary consists of, we highly recommend you start at the [Getting Started Page](/docs/getting-started).
+To learn about what Boundary consists of, we highly recommend you start at the [Getting Started Page](/boundary/docs/getting-started).

-Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.7.0, please review Boundary’s [general upgrade guide](https://learn.hashicorp.com/tutorials/boundary/upgrade-version).
+Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.7.0, please review Boundary’s [general upgrade guide](/boundary/tutorials/oss-configuration/upgrade-version).

 ## Boundary v0.7.0 Highlights

@@ -5,23 +5,23 @@ description: |-
  Boundary release notes for v0.8.0
 ---

-# [Boundary v0.8.0](https://www.boundaryproject.io/downloads)
+# [Boundary v0.8.0](/boundary/downloads)

 The release notes below contain information about new functionality available in the Boundary v0.8.0 release.
 To see a granular record of when each item was merged into the Boundary project, please refer to the [Changelog](https://github.com/hashicorp/boundary/blob/main/CHANGELOG.md).
-To learn about what Boundary consists of, we highly recommend you start at the [Getting Started Page](/docs/getting-started).
+To learn about what Boundary consists of, we highly recommend you start at the [Getting Started Page](/boundary/docs/getting-started).

-Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.8.0, please review Boundary’s [general upgrade guide](https://learn.hashicorp.com/tutorials/boundary/upgrade-version).
+Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.8.0, please review Boundary’s [general upgrade guide](/boundary/tutorials/oss-configuration/upgrade-version).

 ## Boundary v0.8.0 Highlights

-**Metrics and Health Endpoint:** Boundary is adding [Prometheus metrics](/docs/oss/operations/metrics) to monitor the operations of workers and controllers, 
-as well as a [health endpoint](/docs/oss/operations/health) for controllers. 
+**Metrics and Health Endpoint:** Boundary is adding [Prometheus metrics](/boundary/docs/oss/operations/metrics) to monitor the operations of workers and controllers, 
+as well as a [health endpoint](/boundary/docs/oss/operations/health) for controllers. 

-**Audit Event Logs:** We are expanding the audit event logs by increasing the captured [audit events](/docs/configuration/events/overview), 
+**Audit Event Logs:** We are expanding the audit event logs by increasing the captured [audit events](/boundary/docs/configuration/events/overview), 
 with support for sanitizing sensitive information from audit events. All of the events are now classified and events contain more usable data, with sensitive information redacted by default. 

-**UI Support for Worker Tags:** Users can now set and edit [worker tag](/docs/concepts/filtering/worker-tags) filters in the Boundary admin console.
+**UI Support for Worker Tags:** Users can now set and edit [worker tag](/boundary/docs/concepts/filtering/worker-tags) filters in the Boundary admin console.

 **Performance Improvements:** We have implemented changes to improve performance on larger deployments; such as adding a refresh button in the admin console and desktop client,
 and improving response times listing sessions and targets. We plan to continue these efforts as Boundary users grow their deployments!
@@ -5,31 +5,31 @@ description: |-
  Boundary release notes for v0.9.0
 ---

-# [Boundary v0.9.0](https://www.boundaryproject.io/downloads)
+# [Boundary v0.9.0](/boundary/downloads)

 The release notes below contain information about new functionality available in the Boundary v0.9.0 release.
 To see a granular record of when each item was merged into the Boundary project, please refer to the [Changelog](https://github.com/hashicorp/boundary/blob/main/CHANGELOG.md).
-To learn about what Boundary consists of, we highly recommend you start at the [Getting Started Page](/docs/getting-started).
+To learn about what Boundary consists of, we highly recommend you start at the [Getting Started Page](/boundary/docs/getting-started).

-Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.9.0, please review Boundary's [general upgrade guide](https://learn.hashicorp.com/tutorials/boundary/upgrade-version).
+Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.9.0, please review Boundary's [general upgrade guide](/boundary/tutorials/oss-configuration/upgrade-version).

 ## Boundary v0.9.0 Highlights

 **HCP Boundary Public Beta:** Boundary is coming to the HashiCorp Cloud Platform! HCP Boundary provides an easy way to securely access 
 critical systems with fine-grained authorizations based on trusted identities. Boundary on HashiCorp Cloud Platform provides a fully managed, 
 single workflow to securely connect to hosts and critical systems across Kubernetes clusters, cloud service catalogs, and on-premises infrastructure.
-You can now [try HCP Boundary](https://learn.hashicorp.com/collections/boundary/hcp-getting-started) for free during our [Public Beta](https://cloud.hashicorp.com/products/boundary).
+You can now [try HCP Boundary](/boundary/tutorials/hcp-getting-started) for free during our [Public Beta](https://cloud.hashicorp.com/products/boundary).

 **Self-Managed Workers:** With HCP Boundary, administrators have the option of setting up private, self-managed workers for infrastructure access. This provides the 
 security of having privately managed workers while providing the low overhead of a managed service. Learn more about setting up self-managed workers
-[here](https://learn.hashicorp.com/tutorials/boundary/hcp-manage-workers).
+[here](/boundary/tutorials/hcp-administration/hcp-manage-workers).

 **Worker Registration Enhancements:** Administrators now have a second method of authenticating workers, and we call these PKI Workers (the original 
 authentication method is now called KMS Workers). PKI Workers authenticate to Boundary using a new certificate-based method, allowing for worker deployment 
 without using a shared KMS.

 **Static Credential Store:** In Boundary 0.9.0, we are introducing the static credential store, a basic 
-[credential store](https://www.boundaryproject.io/docs/concepts/domain-model/credential-stores) that is native to Boundary. These credentials
+[credential store](/boundary/docs/concepts/domain-model/credential-stores) that is native to Boundary. These credentials
 are encrypted and stored directly in Boundary. For users interested in integrated secrets management to Boundary targets, the new basic 
 credential store removes the dependency on HashiCorp Vault. Currently, the static credential store only supports username/password type credentials. Note: If you 
 wish to use the Desktop Client for credential brokering, version 1.4.4 and up is required.
@@ -25,7 +25,7 @@ Error information:

 This error message indicates the user does not have permission to access the requested target. Ensure the right IAM policies are configured for the 
 user attempting to create a session. Users need to belong to a role in the target's scope with an authorize-session grant to access the target. 
-[Resource table](https://www.boundaryproject.io/docs/concepts/security/permissions/resource-table) page is a great reference for how to configure 
+[Resource table](/boundary/docs/concepts/security/permissions/resource-table) page is a great reference for how to configure 
 the right permission grants for Boundary roles.

 #### Error from controller when performing authorize-session action against given target
@@ -10,7 +10,7 @@ description: |-
 Boundary workers require inbound access from clients. This does not necessarily require that workers be exposed to the public internet. 
 If the client is coming from a private network (eg a corporate network), the worker needs to allow connectivity from the private network. 
 If the client is coming from the public internet, the worker needs to allow connectivity from the public internet. For more information, 
-check out the [worker networking requirements](https://cloud.hashicorp.com/docs/boundary/self-managed-workers).
+check out the [worker networking requirements](/hcp/docs/boundary/self-managed-workers).

 #### Q: Does Boundary require Vault? What is the integration story?
 While Vault isn't a *required* secrets backend for Boundary sessions, the potential for Boundary | Vault integration is a core part of Boundary's overall 
@@ -19,38 +19,38 @@ value proposition for identity-based access.There are three primary points of in
 [0.4 announcement](https://www.hashicorp.com/blog/announcing-hashicorp-boundary-0-4) and there are ample 
 [tutorials](/boundary/tutorials/access-management/oss-vault-cred-brokering-quickstart) of this scenario. 
 2. Boundary can use Vault as an OIDC provider to enable sign-in with Vault's supported auth methods (even non-OIDC auth methods like Active Directory kerberos/LDAP). 
-This scenario is walked through in this [tutorial](https://learn.hashicorp.com/tutorials/vault/oidc-identity-provider).
+This scenario is walked through in this [tutorial](/vault/tutorials/auth-methods/oidc-identity-provider).
 3. OSS Boundary can use Vault as the external KMS that serves as Boundary's root of trust. More information on this use case can be found 
-[here](https://www.boundaryproject.io/docs/configuration/kms/transit).
+[here](/boundary/docs/configuration/kms/transit).

 #### Q: What Identity Providers does Boundary Support?
-Boundary supports [OIDC authentication](https://learn.hashicorp.com/tutorials/boundary/oidc-auth), which allows support for many popular IdPs 
+Boundary supports [OIDC authentication](/boundary/tutorials/access-management/oidc-auth), which allows support for many popular IdPs 
 like Okta, Azure AD, Auth0, etc. For non-OIDC authentication protocols (such as LDAP), users can also log in with an OIDC bridge identity provider 
-such as [Vault's OIDC bridge](https://www.vaultproject.io/docs/concepts/oidc-provider) capabilities released in 1.9, [Dex](https://dexidp.io), or various others.
+such as [Vault's OIDC bridge](/vault/docs/concepts/oidc-provider) capabilities released in 1.9, [Dex](https://dexidp.io), or various others.

 #### Q: Does Boundary support Multi-factor Authentication (MFA)
 Boundary Open-ID Connect (OIDC)-based authentication supports MFA if the IdP being used enforces MFA. This allows users to authenticate with an identity 
 provider supporting MFA, such as Azure AD, Okta, Auth0, etc.
 Boundary also supports syncing permission claims between an IDP-managed identity and Boundary. This can be very useful when you want to sync group memberships 
-from an IDP to Boundary to assign role assignments dynamically. See Boundary's [managed groups capabilities](https://learn.hashicorp.com/tutorials/boundary/oidc-idp-groups?in=boundary/configuration).
+from an IDP to Boundary to assign role assignments dynamically. See Boundary's [managed groups capabilities](/boundary/tutorials/configuration/oidc-idp-groups).

 #### Q: Does Boundary automate the discovery and configuration of new targets (e.g. servers)? What happens if a host IP address changes?
 Yes, this is one of the core competencies of Boundary. Boundary can discover new targets in two primary ways
 1. Boundary's [Terraform provider](https://registry.terraform.io/providers/hashicorp/boundary/latest/docs) supports discovery of targets provisioned by Terraform
-2. Boundary's [dynamic host catalog](https://learn.hashicorp.com/tutorials/boundary/aws-host-catalogs?in=boundary/oss-access-management) 
+2. Boundary's [dynamic host catalog](/boundary/tutorials/oss-access-management/aws-host-catalogs) 
 agentlessly queries infrastructure providers to automate the onboarding and configuration of hosts

 All of these methods will automate the discovery and configuration of targets when their ip addresses change. Of course, static hosts can still be manually added via Boundary admin UI and CLI.

 For more information on dynamic host catalogs, please see:
- [Dynamic Host Catalog on AWS](https://learn.hashicorp.com/tutorials/boundary/aws-host-catalogs?in=boundary/access-management)
- [Dynamic Host Catalogs on Azure](https://learn.hashicorp.com/tutorials/boundary/azure-host-catalogs?in=boundary/access-management)
+- [Dynamic Host Catalog on AWS](/boundary/tutorials/access-management/aws-host-catalogs)
+- [Dynamic Host Catalogs on Azure](/boundary/tutorials/access-management/azure-host-catalogs)

 #### Q: Session management capabilities - Does Boundary support live session monitoring and termination?
 **Session Logging/Monitoring:** Supported. Boundary creates a session log of all sessions created between identities and targets that have been onboarded to 
-Boundary. You can learn how to monitor these sessions in this [tutorial](https://learn.hashicorp.com/tutorials/boundary/getting-started-connect?in=boundary/getting-started#manage-sessions). 
-Boundary supports audit logs for [Boundary OSS](https://learn.hashicorp.com/tutorials/boundary/event-logging) and [audit log streaming](https://cloud.hashicorp.com/docs/boundary/audit-logging) 
+Boundary. You can learn how to monitor these sessions in this [tutorial](/boundary/tutorials/getting-started/getting-started-connect#manage-sessions). 
+Boundary supports audit logs for [Boundary OSS](/boundary/tutorials/oss-configuration/event-logging) and [audit log streaming](/hcp/docs/boundary/audit-logging) 
 for HCP Boundary. Audit logs for both distributions can be exported to SIEM or BI tools.

 **Session Termination:** Supported. Session termination for Boundary administrators is a supported capability, as demonstrated in this 
-[tutorial](https://learn.hashicorp.com/tutorials/boundary/getting-started-connect?in=boundary/getting-started#manage-sessions).
+[tutorial](/boundary/tutorials/getting-started/getting-started-connect#manage-sessions).