Skip to main content
Enterprise registries let your team publish and share dotbot workflows, stacks, tools, and skills through a standard git repository or a local directory path. Any team member can link to your registry with a single command and then install content from it by name. Registries work with public and private git hosts — GitHub, Azure DevOps, and GitLab are all supported — and local paths are available for inner-loop development.

​
Add a registry

1

Register a remote git repository

Run dotbot registry add with a short name and the repository URL:
dotbot registry add myorg https://github.com/myorg/dotbot-extensions.git
dotbot clones the repository and validates registry.yaml. The name you provide (myorg) must match the name field inside registry.yaml — dotbot exits with an error if they do not match.
2

Register a local path (optional)

Local paths are linked rather than cloned, so they always reflect the current state of the directory. Use this during development before pushing to a remote:
dotbot registry add myorg C:\repos\myorg-dotbot-extensions

​
List registry content

See all registered registries and the content they declare: 
dotbot registry list
The output shows each registry’s name, source URL or path, type (git or local), and the workflows, stacks, tools, skills, and agents it provides.

​
Install from a registry

Pass the registry name and content name separated by a colon: 
dotbot init -Workflow myorg:custom-workflow
You can combine registry content with other flags to set up a full project in one command: 
dotbot init -Workflow myorg:custom-workflow -Stack dotnet

​
Update registries

Pull the latest content from all registered registries: 
dotbot registry update
Update a single registry by name: 
dotbot registry update myorg
Local-path registries are linked rather than cloned, so they always reflect the current state of the local directory. Running registry update has no effect on local registries.

​
registry.yaml manifest

Place a registry.yaml at the root of your registry repository. dotbot validates this file during registry add:
registry.yaml
name: myorg                          # Must match the name used in dotbot registry add
display_name: "My Org Extensions"   # Human-readable label shown in dotbot registry list
description: "Shared workflows and stacks for the platform team"
version: "1.0.0"
min_dotbot_version: "3.5.0"         # Minimum dotbot version required to use this registry

content:
  workflows: ["custom-workflow", "release-pipeline"]
  stacks:    ["my-stack"]
  tools:     ["internal-api-caller"]
  skills:    ["coding-standards"]
  agents:    []
Each value in content must have a corresponding directory in the registry repository. For example, workflows: ["custom-workflow"] requires workflows/custom-workflow/workflow.yaml to exist. dotbot performs these checks during validation:
  1. registry.yaml exists at the repository root.
  2. The YAML parses without syntax errors.
  3. The name field matches the name provided on the command line.
  4. The content section lists at least one item.
  5. Each declared item has a matching directory (non-fatal warning if missing).
  6. min_dotbot_version is read and compared against your installed version (warning if your version is older).

​
Authentication for private registries

If your registry is hosted on a private git repository, dotbot relies on your existing git credential configuration. When a clone fails due to an authentication error, dotbot prints provider-specific hints. 
gh auth login
git credential-manager configure
Make sure your PAT or SSH key has at least read access to the registry repository. dotbot does not store credentials — it delegates entirely to your git credential helper.