ISV Release Dashboard

Independent Software Vendor (ISV) Partners can distribute their products via Broadcom’s Support portal. The ISV Release Dashboard allows partners to manage their products on the support portal.

Additional Resources

Login / Access

Email [email protected] to obtain a Broadcom partner account for the ISV Release Dashboard. Login to the site at: https://auth.isv.ci

Work with your Broadcom partner representative to establish your list of products. Once completed, you will be able to upload files and create releases.

Viewing Products

Product metadata allows your product to be visible on the Broadcom support portal

Login to the ISV Release Dashboard
Click My Products and Releases at the top of the page.

Uploading Product Files

The ISV Release Dashboard allows uploading files associated with your product. Later, when you manage a release, you map specific files to a release.

Navigate to the My Products and Releases page.
Click on a Product.
Click the Upload Product File button.
Choose a file to upload. Press Upload Product File.

Uploaded files will be listed on your product’s page.

Creating a Release

Releases appear on Broadcom’s support portal. Releases are linked to Products and contain a subset of the product’s list of files.

To Define a Release

Navigate to the My Products and Releases page.
Click on a Product.
Click the Releases button to view the current set of releases.
Click the Create Release button.
Specify a version and click Submit.

You’ll see the new release version listed with other releases.

To configure your Release

Navigate to the My Products and Releases page.
Click on a Product.
Click the Releases button to view the current set of releases.
Click the Edit button to open the release.
Update fields per the definitions below and click Update

Release Data Definitions

Version

Semantic versions are required.

Release Date

Date of release. Not downloadable from support site until this date.

End of Support Date

End of Support date that is listed in the Product Lifecycle at support.broadcom.com. This date should be the same as the EOS date for the version of Elastic Application Runtime (EAR) that your tile or artifact is compatible with. As of 10-June-2026, - EAR 10.2 has an EOS date of 30-June-2027 - EAR 10.4 has an EOS date of 30-April-2028

Release Notes URL

A URL to the documentation for this release.

Product Dependency Constraints

Most tiles should specify a constraint on elastic-runtime LTS versions. Add a new row for each version that is compatible. Tiles should be compatible with multiple versions to enable upgrades. As of 10-June-2026, all tiles should be compatible with both elastic-runtime 10.2 and 10.4 If your tile depends on a stemcell, the stemcell version can also be set here. It is not necessary to put a version constraint on Operations Manager, as OpsMan 3.x is compatible with all tiles.

Release Upgrade Constraints

Indicate previous releases of this product from which you can upgrade to this release. You need to have at least one, unless this is your first release. You need to add individual rows for each different release lines that product can upgrade from.

Version Constraint Behavior

Version constraint behavior works only on a given release line. You need to add individual dependency specifier rules for each different release lines that product depends.

Choice	Definition
Float on a Version Line	Pick from the list of versions for the targeted product slug. This indicates any patch version of the dependency within the major version or minor specified is compatible with this release. For example, if you specify 4.1, you are indicating compatibility >= 4.1 and < 4.2.
Greater Than or Equal to a Patch Version	Pick from the list of versions for the targeted product slug. x.y.z Matches releases within the given minor that have the given patch number or greater. For example, if you specify 4.0.24, any version >= 4.0.24 and < 4.1.0 is compatible.

Product Release Files

Select the specific files to include in this release.

To Publish your Release

Publishing a release means that it moves from being staged in the ISV Release Dashboard to being available to customers in Broadcom’s support portal. You can only publish your release once. (If the release needs updating, create another release)

Navigate to the My Products and Releases page.
Click on a Product.
Click the Releases button
Click the View button for the specific release you wish to publish.
Press the Request Publication button.

You will be provided with a URL to the product on the Broadcom Support portal, but may need to wait awhile before it appears.

Connecting to Self-Service SRT Environments

Use the BOSH CLI to manage your SRT environment through an SSH tunnel to the Ops Manager VM. You can also SSH into individual deployment VMs or Ops Manager.

Before you start

You need:

A claimed SRT environment from Self Service.
The environment’s hammer file, a JSON file downloaded from its self-service page.
Three command-line tools: om, the BOSH CLI, and jq.

Run the commands below in a Bash or Zsh terminal on macOS or Linux. If you use Homebrew, install the tools with:

brew tap pivotal-cf/om https://github.com/pivotal-cf/om
brew install jq om bosh-cli

Homebrew core names the BOSH CLI executable bosh-cli. The examples below use that name. If your executable is named bosh, replace bosh-cli with bosh in those commands.

Step 1: Set the hammer file path

Replace the example path with the path to your downloaded hammer file, then run:

export HAMMER_FILE="$HOME/Downloads/your-hammer-file.json"

Step 2: Configure BOSH access

Run the following block in the same terminal. It reads the credentials from your hammer file, saves the SSH private key to a temporary file, configures the SSH proxy, and loads the BOSH environment variables. No edits to the block are needed.

# Save the Ops Manager private key to a temporary file with restricted permissions
export OM_KEY_FILE="$(mktemp)"
jq -r '.ops_manager_private_key' "$HAMMER_FILE" > "$OM_KEY_FILE"
chmod 600 "$OM_KEY_FILE"

# Route BOSH CLI traffic through the Ops Manager VM over SSH
export BOSH_ALL_PROXY="ssh+socks5://ubuntu@$(jq -r '.ops_manager_dns' "$HAMMER_FILE"):8022?private-key=${OM_KEY_FILE}"

# Authenticate with Ops Manager and load the BOSH environment variables
export OM_TARGET="$(jq -r '.ops_manager.url' "$HAMMER_FILE")"
export OM_USERNAME="$(jq -r '.ops_manager.username' "$HAMMER_FILE")"
export OM_PASSWORD="$(jq -r '.ops_manager.password' "$HAMMER_FILE")"
eval "$(om -k bosh-env)"

To inspect the environment variables returned by Ops Manager, run om -k bosh-env.

Step 3: Verify the connection

List the deployments in your environment:

bosh-cli deployments

If the connection succeeds, the output looks similar to this:

Using environment '10.0.0.5' as client 'ops_manager'

Name                     Release(s)                       Stemcell(s)                                   Team(s)
cf-9f3f192a9cb9a765b554  backup-and-restore-sdk/1.19.45   bosh-google-kvm-ubuntu-jammy-go_agent/1.954   -
...

Step 4 (optional): SSH into a VM

Choose a deployment from the previous command’s output. Replace <deployment-name> with its name to list its VMs:

bosh-cli -d <deployment-name> instances

Then connect to a VM. Replace <instance-group>/<index> with an instance from the list, such as router/0:

bosh-cli -d <deployment-name> ssh <instance-group>/<index>

To connect directly to the Ops Manager VM, run:

ssh -p 8022 -i "$OM_KEY_FILE" ubuntu@"$(jq -r '.ops_manager_dns' "$HAMMER_FILE")"

Troubleshooting and notes

Cleanup: When you finish using BOSH or SSH, delete the temporary private key with rm -- "$OM_KEY_FILE". Repeat step 2 before connecting again.
Terminal session: The environment variables apply to the current terminal session. If you open a new terminal, repeat steps 1 and 2.
Missing values or JSON errors: Confirm that HAMMER_FILE points to the downloaded hammer file. Run ls "$HAMMER_FILE" to check that the file exists.
Connection timeout: Check the self-service page to confirm that your SRT environment is still claimed and running.
Private key permissions error: Run chmod 600 "$OM_KEY_FILE" again.
TLS certificates: The om -k flag skips TLS certificate validation, as expected for SRT environments.
Corporate firewalls: Connections to your environment use SSH on port 8022. Many corporate firewalls and VPNs block outbound SSH or non-standard ports. If commands time out even though your environment is running, ask your network team to allow outbound TCP traffic on port 8022, or connect from a network that permits it.

ISV Dashboard