Application management

This chapter will contain a description of how to upload and manage applications for a service provider. UCloud provides a catalog of applications which a service provider can subscribe to, assuming that they live up to certain infrastructure requirements.

The Application Catalog

The UCloud application catalog enables users to browse a comprehensive list of available software. Each application within the catalog is a UCloud abstraction that defines a piece of software, its parameters, and its startup process.

UCloud maintains an up-to-date catalog of applications commonly used in high-performance computing systems. The entire application catalog is automatically available when using the Kubernetes integration. You do not need to configure the service provider for this. Images will automatically be pulled from the UCloud Docker registry.

The Structure of an Application

UCloud applications describe how to obtain, load and invoke a piece of software. This information is supplied in a YAML document which has several sections. These sections are illustrated in the diagram below.

Metadata

All applications contain a small section of metadata. This metadata includes an application name and version. These together form a unique identifier, which is transmitted to the service provider letting it know which application is being started.

The UCloud user-interface allows users to quickly swap between versions of the same application, as shown in the screenshot below. This also means that the name of an application should be considered stable. The name of an application is generally not shown directly to end-users.

Versions are ordered in UCloud based entirely on when they are uploaded to the platform. Thus the newest version is always considered to be the most recently uploaded version.

Input Parameters

The input parameters of an application describe the input which a user can feed into it. Each input parameter type has an associated widget in UCloud specialized for that type of input. The exact types supported are listed in the reference. Input parameters can be either optional or mandatory. Their values are partially validated by UCloud before being forwarded to the service provider.

The values of the input parameters are fed into the invocation sections.

Invocation

The invocation sections accept the user input and produce output in the job submission script. This includes changes to the sbatch directives, binding environment variables and finally invoking the actual software. The invocation sections are written using Jinja2 templates. Refer to the reference and examples for details on how to write these.

Interactive Properties

Applications can also declare support for various interactive application backends. This includes web-based applications and remote desktop applications. These are shown in some of the examples below, but are not covered in this chapter.

Examples

# yaml-language-server: $schema=https://launcher-assets.cloud.sdu.dk/schemas/app
application: v2

name: "example-application"
version: "2026.1.0"

title: "My example"
documentation: "https://docs.cloud.sdu.dk/"
description: "My example applications"

software:
  type: "Container"
  image: "dreg.cloud.sdu.dk/ucloud-apps/example:2026.1.0" # This does not exist

features:
  multiNode: true
  links: false
  folders: true
  jobLinking: true
  ipAddresses: true

web:
  enabled: true
  port: 7681

ssh:
  mode: "Optional"

extensions: [".txt", ".md"]

parameters:
  shell:
    type: "Enumeration"
    title: "My preferred shell"
    description: "Select your preferred shell."
    defaultValue: "bash"
    options:
      - title: "Bash"
        value: "bash"
      - title: "Zsh"
        value: "zsh"
      - title: "Fish"
        value: "fish"
    optional: true

  feature:
    type: "Boolean"
    title: "Enable feature"
    description: "Do you want the feature? (default: false)."
    defaultValue: false
    optional: true

  modules:
    type: "Directory"
    title: "Modules path"
    description: "Import environment modules folder."
    optional: true

  initScript:
    type: "File"
    title: "Initialization"
    description: "Shell script to run during startup. File format: Bash script (.sh)."
    optional: true

invocation: |
  echo "Did you want the feature?" {{ feature }}
  echo "Your preferred shell is: " {{ shell }}

Reference

Metadata

The metadata section provides basic metadata about the document and the application contained within. This section is mandatory and placed at the top-level.

Parameters

The parameters section contains the input parameters for a given application. Parameters are supplied in the parameters top-level section. The top-level section has a type of map<string, parameter> where the key is the name of the parameter. The parameter type is defined in this section.

Software

The software section contains information about how to retrieve the required software. This is supplied in the software top-level section.

Variables

All input parameters submitted to the job are available at the top-level using the same name as described in the parameters section of the application. If a variable has a default value and none was supplied, then the default value is made available. It is not possible to detect directly if a user supplied no value if a default is available. Normal variables can be accessed with the following snippet:

{{ myParameter }}

Optional parameters for which the user did not supply a value, and the parameter has no default, will not be made available in the template. It is possible to detect if no value is supplied with the following snippet:

{% if optionalParameter == None %}
The optional parameter was not supplied
{% else %}
The optional parameter is {{optionalParameter}} 
{% endif %}

Metadata about the job is made available through the ucloud top-level property. The properties in the ucloud property are also automatically bound to environment variables using the same name but in UPPER_SNAKE_CASE. Thus ucloud.machine.memoryInGigs becomes UCLOUD_MACHINE_MEMORY_IN_GIGS. The contents of the ucloud property is defined in the table below:

Filters

The standard built-in filters of Jinja2 are supported along with the following custom filters:

boolean_expression | flag(onFlag[, offFlag]) -> string

{{ True | flag("--yes", "--no") }}            -> "--yes"
{{ False | flag("--yes", "--no") }}           -> "--no"
{{ True | flag("--yes") }}                    -> "--yes"
{{ False | flag("--yes") }}                   -> ""

expression | option(optionFlag[, addSpace]) -> string

{{ None | option("--an-optional-option") }}   -> ""
{{ 42 | option("--count") }}                  -> "--count '42'"
{{ 42 | option("--count=") }}                 -> "'--count=42'"
{{ 42 | option("--count", false) }}           -> "'--count42'"
{{ 42 | option("--count=", true) }}           -> "--count= '42'"
{{ "/path/with spaces" | option("--file") }}  -> "--file '/path/with spaces'"

Methods

The standard built-in methods Jinja2 are supported along with the following custom methods:

Control Structures

The templating engine supports the control structures of Jinja2, with the following exceptions:

• {% extends ... %} has been disabled
• {% from ... %} has been disabled
• {% import ... %} has been disabled
• {% include ... %} has been disabled

Web Applications

The web-based interactive applications can be configured in the web top-level property. It has the following options available to it:

Remote Desktop Environments (VNC)

Remote desktop environments (via VNC) can be configured through the vnc top-level section. It has the following properties available to it:

Features

Various optional features can be enabled through the features top-level section. These properties are described by the table below. All properties in the features section have a default value.