how-to · Reviewed 2026-09-17

Bring Your Own Software (BYOS)

Rescale Software Publisher (sometimes called Publisher or Spub) is the self-service way to install, package, version, and publish your own software on Rescale. You use it when the commercial or open-source package you need is not already in the catalog, when you need a custom build or patch of something that is, or when your organization has in-house codes that you want to make available to the rest of your workspace. This page walks through when to use BYOS, how to publish a tile, how to version it, how to wire up licensing, and the most common issues we see.

When to use BYOS

Reach for Software Publisher when any of the following is true:

• The product you need is not in the Rescale software catalog.
• You need a specific version, patch, or plugin set of a catalog product that is not offered as a stock tile.
• You have internally developed or customer-proprietary code that must run on Rescale compute.
• You need to bundle additional tooling (Python environments, compilers, runtime libraries, containers) with a packaged solver.
• You want to standardize a build across your organization so every engineer runs the same binary and modules.

If you only need to tweak runtime parameters or swap input files, BYOS is probably overkill. Most catalog tiles accept environment-variable overrides, custom command lines, and pre- or post-process scripts at job submission time.

Software Publisher is an optional feature. If the Publisher link does not appear in your left navigation, contact your Rescale account team to have it enabled.

For a worked example, see publishing a custom ParaView version with Software Publisher in the Rescale Help Center.

Prerequisites

Before you start publishing, confirm:

• Access. Your Rescale account has the Software Publisher feature enabled. A workspace or organization admin can confirm.
• Permissions. You have permission on the target workspace to create tiles. If you plan to publish org-wide, you need the appropriate admin role.
• Storage quota. Your workspace has enough storage for the sandbox volumes used during packaging. Sandboxes grow with installed binaries.
• Source material. You have installer packages, license-server details, and any custom scripts staged locally or in Rescale-accessible storage.
• A license plan. If the software is license-server-backed, you know whether you will point at an on-premises server through a Company License Proxy (CLP), a cloud-hosted server, or bundled license files.

How publishing works

Software Publisher uses two concepts:

• Software Tile. The product-level container. A tile is what your users see in the catalog. Each tile has a name, description, and optional icon.
• Software Version. A specific build of that tile. Versions are what actually get installed and run. You iterate on a version inside a sandbox (a temporary Linux machine with the tile's file system mounted at $RESCALE_MOUNT_BASE), and publish when it is ready.

The general flow is:

1. Create a new tile (or pick an existing one).
2. Create a new version under that tile.
3. Launch a sandbox and install the software into $RESCALE_MOUNT_BASE.
4. Validate the install using spub_validate and by running a test job.
5. Publish the version, choosing a visibility (Admin Private, Workspace Private, or Organization Private).

Creating a tile

From Software Publisher, click New Software Tile and supply:

• Name and display label.
• Description shown in the catalog.
• Optional icon.
• Default command template (what runs when a user submits a job without overriding the command).

Keep the name stable. Users and scripts will refer to it.

Creating a version in a sandbox

From a tile, click New Software Version to launch a sandbox. The sandbox starts in the Create state while resources come up and transitions to Active when it is ready. You can then connect over:

• DCV, a browser-based desktop session for GUI installers.
• SSH, for CLI-driven installs.

Everything you write under $RESCALE_MOUNT_BASE is preserved as the published artifact. Anything installed under system paths like /opt or /usr/local outside that mount is lost when the sandbox is torn down. Source the packaged environment with:

source $RESCALE_MOUNT_BASE/rescale_env.sh

Add any custom environment variables your software needs to rescale_env.sh so they get picked up automatically on future job launches.

Spub helper tools

Software Publisher provides a set of spub_* helpers that package common install tasks into portable steps. Use them instead of one-off yum or pip commands to make the install reproducible:

• spub_yum_install <packages>: install system packages into the sandbox, recording them for portability.
• spub_add_python_venv <name>: create a Python virtual environment inside the sandbox.
• spub_update_gcc <version>: install or switch the GCC toolchain.
• spub_validate: run a final validation pass on the sandbox before publishing. Use this before clicking Publish.

The KB article How to Source Intel Compilers for Custom Software Installations covers the pattern for picking up Intel compilers and MPI inside a sandbox, which is a common need for HPC builds.

Updating a version

If you need to iterate after starting the sandbox, use the Update action on the version to relaunch the sandbox with the installed artifacts preserved. You can keep updating until the version is published.

Publishing and visibility

When the sandbox is installed, validated, and your test job passes, click Publish. Pick one of three visibility levels:

• Admin Private. Only Software Publisher admins can see the tile. Use this for tiles that are still in progress after the sandbox is shut down, or for internal-only test builds.
• Workspace Private. Members of the current workspace can use the tile. This is the most common setting when a team wants a shared build.
• Organization Private. Everyone in your Rescale organization can use the tile. Pick this for blessed, org-wide builds.

A published version is locked. To change anything, create a new version under the same tile.

Deleting and preserving sandboxes

You can delete a tile or an individual version if it is not referenced by an active job. You can also preserve a sandbox after publishing so you can spin it back up later to iterate. Preserved sandboxes continue to consume storage; remove them when they are no longer needed.

Versioning

A few conventions keep versioning sane across an organization:

• Match the upstream version number (2024R1, 22.3, 7.3.4) when you are packaging a commercial product. Do not invent your own scheme.
• Add a short suffix when you deviate from the stock install, such as -mkl, -cuda, or -hotfix.
• Treat the tile name as stable. New installs go into new versions, not new tiles, so users keep running the same submit flow.
• If you need to retire a version, publish a new one as the recommended default and leave the old one Admin Private so in-flight jobs keep working.

Because a version is frozen once published, you can safely pin jobs to a specific version of a tile the same way you would pin a container image.

Licensing your BYOS package

Three licensing patterns cover almost all BYOS cases:

• On-premises license server (most common). Your customers install a Company License Proxy (CLP) in their workspace. BYOS jobs pick up LM_LICENSE_FILE, CDLMD_LICENSE_FILE, ANSYSLMD_LICENSE_FILE, or similar license environment variables pointing at the CLP. Configure the license environment in rescale_env.sh so end users do not have to set it per job.
• Cloud-hosted license server. You or your vendor hosts a license server reachable from the Rescale cluster. Same pattern: set the license environment in rescale_env.sh.
• Bundled license files. For products that ship with a node-locked or floating license file, copy the license file into the sandbox under $RESCALE_MOUNT_BASE and point the relevant environment variable at it. Never bundle licenses you do not have the right to distribute.

Document your licensing assumption in the tile description so users know what to configure in their job's Software Settings.

Containers and ParaView

Two tutorials cover publisher patterns that come up often:

• Tutorial: Publish a Containerized App with Software Publisher and Run It on a Workstation walks through packaging a Docker or Singularity image inside a sandbox, wiring up the runtime, and launching it on a Rescale Workstation.
• Tutorial: Publish a Custom ParaView Version with Software Publisher on Rescale shows how to deliver a specific ParaView build that Rescale Desktops can open, which is useful when your results rely on plugins not present in the stock ParaView tile.

Troubleshooting

Most issues fall into a small set of buckets:

• Missing files after publish. Anything outside $RESCALE_MOUNT_BASE is not preserved. If your install script writes to /opt, /usr/local, or a home directory, relocate the install to the mount.
• Environment not picked up. Confirm rescale_env.sh sources everything your solver needs and that the default command on the tile sources it. Use spub_validate to surface environment issues before publishing.
• Shared libraries not found. Either install missing libraries with spub_yum_install or bundle the libraries under $RESCALE_MOUNT_BASE and extend LD_LIBRARY_PATH in rescale_env.sh.
• MPI or compiler mismatch. Install Intel or GCC toolchains using spub_update_gcc or the Intel compiler pattern. Pinning the MPI runtime used at build time avoids ABI mismatches with the host cluster's MPI.
• Cannot publish. spub_validate must pass. Re-run it, fix reported issues, and retry. Sandboxes that fail to publish can be updated instead of being torn down.
• Job runs locally but not under Rescale. Confirm the command on the tile matches how you tested in the sandbox and that any host-specific paths have been replaced with $RESCALE_MOUNT_BASE references.

Known limitations

• Software Publisher sandboxes run Linux. Windows is not supported.
• Software Publisher is not available on ITAR or government platforms.
• Publisher is UI-driven. There is no public CLI or API for creating and publishing tiles programmatically.
• Certain installers that require interactive root access on the host do not work inside a sandbox. Containerize these with the pattern in the containerized-app tutorial above.
• Tiles cannot be renamed after publish. Plan the name carefully.

Related

• Browsing the Catalog for how published tiles surface to end users.
• Ansys and Siemens for catalog-backed equivalents of vendor tiles you might otherwise build in BYOS.
• Tutorials for broader platform walkthroughs, including custom workflows.