Storage

Active:

Cloud object storage for the dashboard's playbooks, scripts, and other assets. Configure one or more backends; pick one as active. Use Migrate to copy assets between backends — the source is preserved so you can verify before deleting.

Backend

The active backend is what new uploads write to, what features (such as Ansible) read from, and where Terraform state for provisioned resources is now kept. Backends with required fields filled in will show configured; the active one is highlighted.

AWS S3

Azure Blob Storage

Google Cloud Storage

OCI Object Storage

image hub only

Credentials come from the OCI setup wizard — only the bucket is set here. Can host the image-registry hub, but cannot be the active backend: the active backend also decides where Terraform state lives, and Terraform has no OCI state backend.

Local Filesystem / UNC

local runner only

Either a path inside the dashboard container (typically a bind-mounted host directory) or a UNC share like \\fileserver\share\playbooks. UNC reads go through the SMB protocol — no host-side mount needed. Username / password / domain are only used for UNC.

Terraform state

The active backend above also stores the Terraform state for everything you provision (VMs, cloud databases, EKS). State is written under a fixed terraform-state/ prefix at the bucket / container root — this is separate from the asset Key / Blob / Object Prefix and is not affected by it. Keeping state on a cloud backend means it survives container recreates. Switching the active backend while live state exists will prompt you to migrate that state to the new backend (the old copy is kept as a backup).

Heads up: with no cloud backend active, Terraform state stays on the container's ephemeral deploy disk and is lost if the container is recreated. Select a cloud backend (S3, Azure Blob, or GCS) above to keep state safe.

Image-registry hub

The single backend that holds the canonical VHD/raw artefact for every registered image. Leave on Same as active backend for single-backend installs — only change this if you want the image hub to live on a different cloud than your day-to-day uploads.

BeyondTrust EPM-L packages

Pull the EPM for Linux agent packages from BeyondTrust into this backend. Once here they're ordinary assets: installable at image-build time from the Install EPM-L option on the AWS / Azure / GCP build pages, or by a config-management playbook. No active backend selected. Choose one above first.

Build status:

BeyondTrust has no built packages yet — use Build packages, then check again. A build takes a few minutes.

Upload an asset

Pick a playbook or script — it goes straight into the active backend and becomes available on /config-mgmt for runs against your VMs and cloud instances. No active backend selected. Choose one above before uploading.

Ready:

Allowed types: .yml .yaml .sh .ps1 .rpm .deb. Scripts and packages are auto-wrapped in a generated playbook at run time; .ps1 targets Windows hosts (the host's Ansible inventory must set ansible_connection=winrm).

Stored assets

Showing assets across every configured backend. Use Move to relocate a playbook from the local filesystem to a cloud backend so the cloud-side Ansible runner can fetch it. Tick rows and click Delete N selected to clean up multiple assets in one shot.

No assets yet. Upload a playbook or script using the form above.
Name Backend Type Size Actions

Move asset

Move from to:

The asset is copied first, then deleted from the source. If the copy succeeds but the delete fails, the asset will exist on both backends and you'll be asked to clean up the source manually.

Migrate between backends

Copy every asset from a source backend to a target backend. The source is preserved — verify the target is healthy, then delete from the source manually if you want a clean cutover. Files already present in the target are skipped unless you tick Overwrite existing.

Copied ()
Skipped ()
Failed ()