Documentation
Audience: operator · Profile:
both· Read this when: you are looking for a page and do not yet know which one.
Every page here opens with the same one-line block: who it is for, which install profile it applies to, and the situation that should send you to it. This index is the same information collected in one place.
The profile matters more than it looks. install_profile is demo or pov and the
two are mutually exclusive, so a page marked pov describes features an estate instance
does not have, and the reverse. demo is a config value naming one BeyondTrust tenant of
your own, not a claim about what you are doing with the instance — a page marked demo
applies just as much to infrastructure you run in production. See
Demo and POV profiles.
Start here
| You are… | Go to |
|---|---|
| installing or running the dashboard — an operator | Onboarding, then the platform reference below |
| running your own infrastructure with it | the platform reference below — you want the demo profile, whatever its name suggests |
| showing it to someone — a presenter | Demo profile |
| running customer proof-of-value work | POV profile |
| evaluating a POV somebody handed you — a customer | What the customer sees |
| changing the code — a contributor | Design notes, runbooks, notes, and CONTRIBUTING.md |
Platform reference
What the dashboard does, and the discipline it expects from you. These are written once and shared: the page describing how to deploy a cloud VM is the same page whether you are demoing, running a lab, or running production.
Each group below is a section: a hub page that says which page answers what, and a folder of the pages themselves. A page that stands alone is a row on its own.
Get started
| Page | Read this when |
|---|---|
| Onboarding Guide | you are setting the dashboard up for the first time and want the shortest path to a running instance. The per-cloud setup pages are under onboarding/. |
Cloud
| Page | Read this when |
|---|---|
| Cloud | you are putting workloads on AWS, Azure, GCP or OCI and want to know which page covers which part. |
| Infrastructure as Code | you are about to deploy your first cloud resource and want to know what is actually running underneath. |
| Cloud Sandbox | you want an isolated cloud account for the dashboard's labs, bootstrapped rather than hand-built. |
| Cloud VMs | you are deploying cloud VMs, or want the dashboard to see and power ones it did not deploy. |
| Windows servers | you are deploying a Windows server on AWS, Azure or GCP: where its administrator password goes, how PRA reaches it, and joining Entra ID or Active Directory. |
| Cloud Containers | you want a containerised app on a cloud runtime without standing up Portainer. |
| Virtual Desktops | you need a pool of private desktop VMs that reps reach through the PRA Gateway rather than over the internet. |
| Image Management | you are about to build a custom image and need to know how it will reach the other clouds. |
| Cloud Costs | you want month-to-date cloud spend on the dashboard, a budget alert, or a budget in the cloud that alerts while the dashboard is down. |
Platforms and workloads
| Page | Read this when |
|---|---|
| Databases | you are standing up a managed database, or want to manage one you already run. |
| Kubernetes | you are managing Kubernetes clusters and the privileged access into them, and want to know which of the three kinds the dashboard builds you need. |
| Managed Kubernetes | you are provisioning an EKS, AKS, GKE or OKE cluster from the dashboard, or registering one you already run in a cloud. |
| k3s | you are building an on-prem cluster with the dashboard, or working with the k3s it creates in the OT demo cell or the Workload Lab. |
| KubeSolo | you need the Entitle agent on an edge or plant-floor host that will not carry a real cluster. |
| Inventory | you want one list of everything across every cloud and hypervisor, to filter it by tag or Password Safe attribute, or to act on a selection. |
| Remote Agents | your hypervisors, databases or clusters live somewhere the dashboard cannot reach. The pages are under remote-agents/. |
Identity and access
| Page | Read this when |
|---|---|
| Identity and access | you are deciding who and what may use the dashboard, how it keeps credentials, or how you would prove what happened. |
| Permissions | you are deciding what a user may see or do — and especially before ticking "Full access", or handing a POV to a customer stakeholder. |
| Service Accounts | something that is not a person — a CI job, an MCP agent, a script — needs to call the API, and you would otherwise hand it a PAT. OAuth 2.0 client credentials, built in, no IdP needed. |
| Secrets Management | you are deciding where to store cloud credentials, and how to evolve that over time. |
| Audit Log | you need to show who did what, or to satisfy yourself that the record has not been edited. |
| Directories | you want Windows servers joined to an Active Directory domain (built in a cloud, one you already run, or your on-premises domain), want to manage an on-prem AD or LDAP directory through a remote agent, or want to browse and change group membership in Entra ID, Okta or PingOne. The pages are under directories/. |
| OIDC and single sign-on | you want single sign-on, Dex in front of your clusters, Entra federation to Kubernetes, or the dashboard reaching AWS, Azure, GCP and k3s with its own short-lived identity instead of a stored key. The pages are under oidc/. |
| SPIFFE and SPIRE | you are running the dashboard's own SPIRE server — on Docker Compose or as a sidecar on Azure Container Apps, Cloud Run, ECS or Kubernetes — or want the map of every feature that uses SPIFFE: agent attestation, the dashboard's own identity, service accounts, demo cells and the Workload Lab. |
| Workload Lab | something that is not a person needs a credential — a certificate, a SPIFFE identity, a cluster token or a cloud key — and you want to pick the mechanism before reading any one guide. The per-tab guides, the Workload Credentials product pages and the register of what consumes each credential are all under workload-lab/. |
Operations
| Page | Read this when |
|---|---|
| Operations | the dashboard is installed and you are running it day to day: managing the infrastructure that already exists and what you built with it, and keeping the dashboard itself healthy. |
| Config Management | you are about to run an Ansible job and want to know how the runner handles secrets and isolation. |
| Scheduling | you want a change to run later, run repeatedly, or run only inside an approved window, or it has to wait for a second person to sign it off. The hub tells the three kinds of "schedule" apart; the full reference, Change Windows, and its other half, Action Guardrails — disallowed changes blocked before they start — are under scheduling/. |
| Storage Management | you are enabling a feature that needs a storage backend, which several of them do. |
| Cloud Hosting | you want the dashboard reachable from outside your LAN, or fronting remote agents. |
| Job Worker | a long job is sitting queued, or you are sizing the worker for more of them. |
| Notifications | you want to hear about expiring resources and failed jobs without opening the dashboard. |
| Auto-delete Timer | you want lab resources to clean themselves up — read it before enabling it, because it deletes infrastructure. |
| Config Migration | you are standing up a second instance and do not want to re-type months of configuration. |
Editions
| Page | Read this when |
|---|---|
| Editions | you are choosing between running the dashboard yourself and a hosted edition, or want to know why a feature is not in this one. |
| Community vs. hosted | you are choosing between running this yourself and a managed edition. |
| SaaS Roadmap | you want to know which capabilities are reserved for the hosted edition, and why. |
The rest of the tree
Two kinds of folder, indexed two ways. A section (a feature with several pages) is
indexed by a hub page of the same name beside it, so cloud.md indexes cloud/, and the
hub is also the section's own entry page. A collection (pages that share a kind, not a
feature) is indexed by its own README.md.
| Folder | What's in it |
|---|---|
| profiles/ | The demo / pov gate, the per-feature matrix, and everything specific to one profile or the other. |
| integrations/ | One page per external system the dashboard talks to — the BeyondTrust products, the hypervisors, the runners. |
| design/ | Why a subsystem is shaped the way it is. Facts that are not recoverable from reading the code. |
| runbooks/ | Procedures to run against a real instance, usually to prove a phase of work landed. |
| notes/ | Dated investigations, kept for their conclusions rather than their narrative. |
The sections — onboarding/, cloud/, access/,
oidc/, directories/, workload-lab/, remote-agents/,
operations/ (with operations/scheduling/ inside it), kubernetes/
and editions/ — are listed with their hubs above.
Outside docs/: CONTRIBUTING.md, SECURITY.md, and
a README.md beside most directories that ships something —
runners/, examples/,
scripts/sandbox/.
Reading these in the app
The dashboard serves this tree at /docs, rendered, with no internet access required —
so an operator does not need the repo open to follow a setup instruction a Settings panel
gave them. That shell is public and unauthenticated, and it lists both profiles' sections
to everybody: making the index vary with the instance's own configuration would leak that
configuration to anyone who asked.