The Manifest

The runnables.yaml manifest describes your app. This page documents its structure: the top-level fields, each runnable’s fields, resource defaults, and the requirements system. Parameters are large enough to warrant their own page — see Parameters & Command Building.

Top-Level Fields

Field	Type	Required	Description
name	string	yes	Display name shown in the Fileglancer UI
description	string	no	Short description of the app
repo_url	string	no	GitHub URL of a separate repository containing the tool code (see Separate Tool Repo). Must be a valid GitHub repository URL — the manifest is rejected at load time otherwise
requirements	list of strings	no	Tools that must be available in the job environment (see Requirements)
runnables	list of objects	yes	One or more runnable definitions (see Runnables). A manifest with an empty runnables list is rejected

Runnables

Each runnable defines a single command that users can launch. If a manifest has multiple runnables, the user selects which one to run before the launch form opens.

Field	Type	Required	Description
id	string	yes	Unique identifier (used in CLI flags and URLs, should be URL-safe)
name	string	yes	Display name shown in the UI
type	string	no	"job" (default) for batch jobs or "service" for long-running services (see Services)
description	string	no	Longer description of what this runnable does
command	string	yes	Base shell command to execute (see Command Building)
parameters	list of objects	no	Parameter definitions shown in the Parameters tab (see Parameters)
env_parameters	list of objects	no	Parameter definitions shown in the Environment tab instead of the Parameters tab (e.g. a Nextflow -profile selector). Same structure as parameters (see Parameters)
resources	object	no	Default cluster resource requests (see Resources)
env	object	no	Default environment variables to export (see Environment Variables)
pre_run	string	no	Shell script to run before the main command (see Pre/Post-Run Scripts)
post_run	string	no	Shell script to run after the main command (see Pre/Post-Run Scripts)
conda_env	string	no	Conda environment name or absolute path to activate (see Conda Environments)
container	string	no	Container image URL for Apptainer (see Containers)
bind_paths	list of strings	no	Additional paths to bind-mount into the container (requires container)
container_args	string	no	Default extra arguments for container exec (e.g. --nv), overridable at launch time
working_dir	string	no	Where the command runs: repo (the cloned project, optionally the manifest’s subdirectory) or work (the job’s work directory). Defaults to work for container runnables and repo otherwise (see Execution Environment)
auto_url	boolean	no	Service runnables only. When true, Fileglancer publishes the service URL for you once $FG_SERVICE_PORT is accepting connections — bind your service to $FG_SERVICE_PORT and you need no URL-writing code (see Services)
service_url_suffix	string	no	Service runnables with auto_url. Text appended to http://$FG_HOSTNAME:$FG_SERVICE_PORT when publishing — a path and/or query, e.g. /?access_token=${FG_SERVICE_TOKEN} for one-click auth. May contain literal URL text and the placeholders ${FG_SERVICE_TOKEN}, ${FG_SERVICE_PORT}, ${FG_HOSTNAME} (braces required); nothing else (see Services)
requirements	list of strings	no	Additional tool requirements specific to this runnable, merged with manifest-level requirements

A manifest with two runnables:

runnables.yaml

name: Image Toolkit
description: Convert and inspect microscopy images

runnables:
  - id: convert
    name: Convert to OME-Zarr
    command: python convert.py
    parameters:
      - flag: --input
        name: Input
        type: file
        required: true

  - id: inspect
    name: Inspect Metadata
    command: python inspect.py
    parameters:
      - flag: --path
        name: Path
        type: directory
        required: true

Resources

Default resource requests for the cluster scheduler. Users can override any of these in the UI before submitting.

Field	Type	Description
cpus	integer	Number of CPUs to request
memory	string	Memory allocation, e.g. "16 GB"
walltime	string	Wall clock time limit, e.g. "04:00" (hours:minutes)
queue	string	Cluster queue/partition name to submit to

resources:
  cpus: 4
  memory: "16 GB"
  walltime: "24:00"

If a field is omitted, the server’s global default is used. The precedence is: user override (highest) → runnable default → server default (lowest).

Requirements

The requirements field lists tools that must be installed in the job execution environment. Requirements can be specified at two levels:

• Manifest-level (requirements on the top-level manifest): apply to all runnables by default. Use this for tools needed by every entry point.
• Entry-point-level (requirements on a runnable): additional requirements specific to that runnable. These are merged with manifest-level requirements when submitting a job. If the same tool appears at both levels, the entry-point version spec takes precedence.

runnables.yaml

name: My App
requirements:
  - "pixi>=0.40"        # needed by all runnables
runnables:
  - id: run
    name: Run with Pixi
    command: pixi run demo
    # effective requirements: [pixi>=0.40]

  - id: container-run
    name: Run in Container
    command: cowsay
    container: godlovedc/lolcow
    requirements:
      - apptainer          # only needed by this runnable
    # effective requirements: [pixi>=0.40, apptainer]

Each entry is a tool name with an optional single version constraint:

requirements:
  - "pixi>=0.40"
  - npm
  - "maven>=3.9"
  - miniforge

Supported tools: pixi, npm, maven, miniforge, apptainer, nextflow

Supported version operators: >=, <=, !=, ==, >, <

One comparison per tool

Compound, comma-separated, or chained version constraints such as "pixi>=0.40,<0.60" or "pixi>=0.40<0.60" are not supported. Use at most one comparison per tool.

How Requirements Are Checked

A requirement check is included in the generated job script and runs at job runtime on the compute node, in the job’s actual execution environment — after the script preamble, $PATH additions, conda activation, and environment-variable exports, but before any pre_run script and the main command. If a requirement is unmet — the tool is missing or its version is too old — the job fails early with a descriptive message in stderr.

• Only requirements relevant to the selected entry point are checked. Unmet requirements for other entry points do not block submission.
• If requirements is omitted or empty at both levels, no checks are performed.

The version of each tool is detected with its standard version command (e.g. pixi --version, nextflow -version, mvn --version, conda --version for miniforge).