CloudBolt Content Navigator

Browse and sync CloudBolt content by human-readable name instead of Global ID.

CloudBolt stores content in git using ID-based directory names like BP-50pq8bqg/. This extension reads the metadata files in your local repo and shows content by name in the VS Code sidebar, so you can find and sync items without cross-referencing the CloudBolt UI.

Requirements

• A local clone of a CloudBolt content repository
• A dedicated CloudBolt development instance — it is recommended that each developer has their own instance to avoid conflicts when pushing content changes
• A personal access token or username/password credentials for that instance

Setup

1. Open your CloudBolt content repository in VS Code.
2. Set your instance URL: open the Command Palette (Cmd+Shift+P) and run CloudBolt: Set API Token (or CloudBolt: Set Password for username/password auth).
3. Set cloudbolt.instanceUrl in VS Code settings to your CloudBolt instance URL.
4. Run CloudBolt: Select Source Code Repository to link the extension to the correct repo configured in CloudBolt.

The CloudBolt panel will appear in the Activity Bar once a content repo is detected.

Python Typings

CloudBolt ships a set of .pyi stub files that enable type checking and autocompletion for CloudBolt APIs in your scripts and plugins. The latest version is always available on your development instance at /var/opt/cloudbolt/proserv/typings.

Download the typings from your instance

1. SSH into your CloudBolt instance and create an archive, following the symlink to capture the actual files.

Mac / Linux:

tar -chzf /tmp/cloudbolt-typings.tar.gz -C /var/opt/cloudbolt/proserv typings/

Windows:

cd /var/opt/cloudbolt/proserv && zip -r /tmp/cloudbolt-typings.zip typings/

2. Download the archive to your local machine (run from your content repo root):

Mac / Linux:

scp root@<instance-ip>:/tmp/cloudbolt-typings.tar.gz ./cloudbolt-typings.tar.gz

Windows (PowerShell):

scp root@<instance-ip>:/tmp/cloudbolt-typings.zip ./cloudbolt-typings.zip

3. Extract into your content repository:

Mac / Linux:

tar -xzf cloudbolt-typings.tar.gz && rm cloudbolt-typings.tar.gz

Windows (PowerShell):

Expand-Archive cloudbolt-typings.zip . && Remove-Item cloudbolt-typings.zip

This creates a typings/ directory in your repo root. It is excluded from git via .gitignore.

Note: Repeat steps 1–3 when you upgrade your CloudBolt instance to pick up any new or updated stubs.

Configure VS Code

Pylance's default stub path is typings, so no configuration should be required. To verify, open VS Code settings and confirm that python.analysis.stubPath is either not set or set to typings. Once the typings/ directory exists in the repo root, VS Code will pick up the stubs automatically on the next reload — providing type checking and autocompletion for CloudBolt APIs across all scripts in the repository.

Since the stubs do not include the underlying .py or .pyc source files, Pylance will raise a missing module source warning without the following setting in .vscode/settings.json:

{
    "python.analysis.diagnosticSeverityOverrides": {
        "reportMissingModuleSource": "none"
    }
}

Workspace Settings (.vscode/settings.json)

When the extension activates for the first time, it automatically adds file and search exclusions to .vscode/settings.json in your content repository:

{
    "files.exclude": {
        "**/*_metadata.json": true,
        "**/*.jpeg": true,
        "**/*.jpg": true,
        "**/*.png": true
    },
    "search.exclude": {
        "**/*_metadata.json": true,
        "**/*.jpeg": true,
        "**/*.jpg": true,
        "**/*.png": true
    }
}

These hide CloudBolt metadata files and embedded images from the Explorer and search results — the extension surfaces that information through the tree view instead.

We recommend committing .vscode/settings.json to your content repository. This ensures every developer on the team gets the same file hiding behavior from the moment they open the repo, without needing to activate the extension first. It also prevents the file from showing up as an untracked change after first activation.

Configuration

Supported Content Types

• Blueprints
• Plugins
• Shared Modules
• Resource Actions
• Server Actions
• Orchestration Actions
• Flow Control Actions
• Recurring Jobs
• Webhooks
• Continuous Infrastructure Tests
• UI Extensions

Source Code Repository

CloudBolt uses a Source Code Repository (SCR) to know where to pull content from when syncing. The SCR must be configured in your CloudBolt instance before using this extension, and it must point to the same remote git repository as your local clone.

To configure the SCR in CloudBolt:

1. In the CloudBolt admin UI, go to Admin → Source Code Repositories
2. Add a repository entry pointing to your content repo's remote URL (e.g. your GitHub/GitLab remote)
3. Ensure your CloudBolt development instance has network access to that remote

Once the SCR exists in CloudBolt, link the extension to it:

1. Open the Command Palette and run CloudBolt: Select Source Code Repository
2. Pick the repository from the list — the extension saves the selection and shows it in the status bar

When you sync, the extension tells CloudBolt to pull from the current branch of that remote repository. This means your changes must be committed and pushed to the remote before syncing — local-only changes will not be included. The extension will warn you if it detects unpushed commits before proceeding.

Dependency Tree

Content items are expandable in the tree to show their dependencies:

• Blueprints expand into labeled sections — Deployment Items, Management Actions, Teardown Items, Discovery Plugin, and Parameter Generated Options. Each section lists its named items, which expand further to show the individual plugins or actions they reference.
• Actions and other types expand to a flat list of their dependent plugins and modules, grouped by content type.
• Plugins and Shared Modules are leaves — they appear as dependencies of other items but do not expand further.

All dependencies are resolved from your local repo and shown by human-readable name. If a dependency exists in CloudBolt but not in the local repo, it is shown as [Unknown: <global-id>].

Refresh All Content

Refresh All Content pushes every item in your local repo to CloudBolt in a single job. It is most useful in two situations:

Setting up a new development instance When you first configure a development instance, it will not have any of the content from your repo. Running Refresh All populates the instance with everything on the current branch, giving you a consistent baseline to develop and test against.

Starting work on a new feature branch (optional) When you check out a new branch, your development instance may still reflect the previous branch. Running Refresh All at the start of your session ensures the instance is in sync with the branch you are working on before you begin making changes. This step is optional — it is only necessary if the branch contains content differences that would affect your testing.

In both cases, the current branch must exist on the remote before running Refresh All — push it first with git push -u origin <branch> if you have not already.

Commands

Right-click any content item in the tree to Sync to CloudBolt, or use the sync button in the toolbar to push all pending changes at once.

Decorations

Items that differ from CloudBolt (modified locally or remotely) are highlighted in the tree with a badge. The badge propagates up to parent sections so you can see at a glance which content types have pending changes.