Configuring Your App with app.yml

Every application published to the Pennsieve App Store must include an app.yml file at the root of the repository. This file declares the app's metadata, runtime requirements, parameters, and inputs/outputs. Pennsieve reads it on every release to build, register, and run your app.

This guide covers the full file layout, with a focus on two features:

Parameter defaults — pre-populating processor parameters in the workflow builder.
GPU compute — requesting GPU compute and what that changes about the build.

File layout

schemaVersion: 1.0.0
application:
  id: my-processor
  name: my-processor
  description: Short description shown in the App Store.
  version: 1.0.0
  type: processor
  maintainers:
    - name: Jane Doe
  tags:
    - demo
runtime:
  cpu: 1024
  memory: 2048
  computeTypes:
    - standard
  timeoutSeconds: 300
parameters:
  - name: threshold
    type: number
    description: Detection threshold.
    defaultValue: "0.5"
    validValues:
      - "0.1"
      - "0.5"
      - "0.9"
inputs:
  - name: package_file
    description: Pipeline package file.
    mediaTypes:
      - application/octet-stream
    cardinality: one
    required: true
outputs:
  - name: package_file
    description: Pipeline package file.
    mediaTypes:
      - application/octet-stream

Top-level sections

Section	Purpose
`schemaVersion`	Version of the app.yml schema (currently `1.0.0`).
`application`	Identity and catalog metadata: id, name, description, version, type, maintainers, tags.
`runtime`	Compute requirements: `cpu`, `memory`, `computeTypes`, `timeoutSeconds`. Note: only `computeTypes` currently affects deployment — `cpu` and `memory` are not surfaced as workflow builder defaults; those dropdowns stay on "Default" regardless of app.yml.
`parameters`	Runtime parameters the app accepts, with optional defaults and allowed values.
`inputs` / `outputs`	Files the app consumes and produces: name, description, media types, cardinality.

Parameters

Each entry in parameters declares a runtime parameter. Declared parameters are stored with the application and surfaced to the workflow builder, which pre-populates each processor's parameter panel from them.

Field	Required	Meaning
`name`	yes	Parameter name. Entries without a name are ignored.
`type`	no	Informational type hint (`string`, `number`, `boolean`, ...).
`description`	no	Help text shown under the parameter name in the workflow builder.
`defaultValue`	no	Value pre-filled in the workflow builder. Always written as a string (quote numbers and booleans: `"0.5"`, `"false"`).
`validValues`	no	Allowed values. When present, the parameter renders as a dropdown restricted to these values.

How each combination renders in the workflow builder

Declaration	Result
`defaultValue` + `validValues`	Dropdown limited to `validValues`, with `defaultValue` pre-selected.
`defaultValue` only	Free-text field pre-filled with the default.
Neither	Free-text field marked REQUIRED — the user must supply a value before running.

Example covering all three:

parameters:
  - name: threshold
    type: number
    description: Detection threshold.
    defaultValue: "0.5"
    validValues:
      - "0.1"
      - "0.5"
      - "0.9"
  - name: verbose
    type: boolean
    description: Enable verbose logging.
    defaultValue: "false"
  - name: channel
    type: string
    description: Channel to analyze.

An app with no configurable parameters should declare parameters: [].

GPU apps

runtime.computeTypes declares the compute your app needs. Most apps use standard. To request GPU compute:

runtime:
  computeTypes:
    - gpu

The value is matched case-insensitively and surrounding whitespace is ignored (gpu, GPU, and Gpu all work).

Declaring gpu changes two things:

Execution target — the app is registered as a GPU app and runs on GPU compute when executed in a workflow.
Build storage — the image build task's ephemeral storage is raised from the Fargate default of 20 GiB to 100 GiB. GPU apps typically pull large dependencies (e.g. torch with CUDA support) that exhaust the default and fail the build with out-of-space errors.

Apps that only declare standard build with the default storage and run on standard compute.

When app.yml is read, and what happens if it's missing

Pennsieve reads app.yml from the release tag being published (defaulting to the main branch when no tag is given). Values are re-read on every deployment, so a new release with an updated app.yml updates the stored parameters and compute settings.

A missing or malformed app.yml never blocks a deployment: the deploy proceeds and previously stored values are left untouched. A warning is logged, so if new parameter defaults don't show up in the workflow builder after a release, check the deployment logs for a warning: unable to read/parse message — it usually means a YAML syntax error.

Common YAML pitfalls:

Unquoted values that YAML re-types: write defaultValue: "false" and defaultValue: "0.5", not the bare values.
validValues entries must also be strings — quote numeric options.
The file must be named exactly app.yml and live at the repository root.