Curiosity CLI

upload-front-end

Uploads a compiled custom front-end bundle to a workspace. The bundle becomes the active UI the next time a user loads the workspace.

The folder you point at must look like a compiled Mosaik.FrontEnd bundle — the CLI checks for a mosaik.app marker file in the root.

Usage

curiosity-cli upload-front-end \
  --server https://my-workspace.example.com/ \
  --token  $CURIOSITY_TOKEN \
  --path   ./MyApp/bin/Release/netstandard2.0/h5/

Options

Flag Alias Default Description
--server -s - Workspace URL.
--token -t - Library Token with permission to manage interfaces.
--path -p pwd Local path to the compiled h5/ folder.
--auto-patch -a false Rewrite asset URLs at upload time. Set when assets are served from a different prefix than the workspace.
--ignore-certificate-errors -i false Disable TLS validation. Dev only.
--timeout 90 Per-request timeout in seconds — bump it for large bundles.

Permissions

The token must belong to a user (or service account) that can manage workspace interfaces. If you see 401/403 errors, recreate the token with Admin rights under Manage → Tokens → Library.

CI / promotion pattern

Build once, upload many times — treat the bundle as a build artifact and promote the same bytes through environments:

dotnet build -c Release

# Dev
curiosity-cli upload-front-end -s $DEV_URL     -t $DEV_TOKEN     -p ./bin/Release/netstandard2.0/h5
# Staging
curiosity-cli upload-front-end -s $STAGING_URL -t $STAGING_TOKEN -p ./bin/Release/netstandard2.0/h5
# Production
curiosity-cli upload-front-end -s $PROD_URL    -t $PROD_TOKEN    -p ./bin/Release/netstandard2.0/h5

Don't rebuild between staging and production — re-upload the byte-identical bundle so the only variable is the target workspace's data.

See also

Referenced by

© 2026 Curiosity CLI. All rights reserved.