Overview

mecapy.yml sits at the root of your repository and tells MecaPy how to package, build, and run your code. It is the single source of truth for the platform — everything else (function versions, workflow ports, schedule, resources) is derived from it.

Top-level shape

A v1 manifest has four required blocks plus one optional:

version: "1"            # frozen at "1" — the format version

package:                # identity, metadata, default resources
  name: bolt-sizing
  version: 0.1.0
  visibility: private
  resources:
    tier: nano

runtime:                # how the code runs (mode A, B, or C)
  kind: python
  version: "3.12"

functions:              # the entries the platform exposes
  size:
    handler: bolts:size
    inputs:
      diameter: { type: Length }
      load:     { type: Force }
    outputs:
      stress:   { type: Stress }

quality:                # optional — testcase gating, etc.
  validation_testcases:
    on_deployment: true

Block	Required	What it does
version	yes	Manifest format version. Always "1".
package	yes	Name, semver, visibility, default resources, tags.
runtime	yes	Discriminator (kind: python | dockerfile | image) + per-mode fields.
functions	yes	One entry per exposed callable. At least one.
quality	no	Testcase / validation hooks consumed at deploy time.

That’s it — there is no flat name: at the top level, no inputs_schema: under functions, no init: for class methods, no separate tests: block. Anything you saw in older docs that contradicts this page is stale.

What each block buys you

Package carries the identity that’s stable across versions — name + visibility + tags + author + license, plus the default resources every function inherits unless it overrides them. The version is semver and bumps on every deploy that changes the code.

Runtime picks one of three execution modes that map to the runtime contract:

• python (mode A) — managed image built by MecaPy from your handler.
• dockerfile (mode B) — image built by MecaPy from your Dockerfile.
• image (mode C) — image pulled as-is from a registry.

Mode A introspects the handler’s signature; modes B/C are language-agnostic and require explicit typed I/O. See runtime modes for the per-mode fields.

Functions is a dict of named entries. Each one declares either handler (mode A) or entrypoint (modes B/C), plus typed I/O ports and per-function resource overrides. Multiple functions in one package share the same image — see handlers for the options.

Quality is a free-form bucket for cross-cutting deployment hooks. The only consumer today is validation_testcases.on_deployment which runs the test cases referenced by each function’s testcases: field at deploy time and gates the deploy if any fail.

Where next

Full syntax reference

Every field, every type, every default in one place.

Runtime modes

Choosing between Python, Dockerfile, and pre-built image.

Handlers vs. entrypoints

What goes in handler: (mode A) vs. entrypoint: (modes B/C).

Typed I/O ports

The inputs: / outputs: declaration and the type catalog.

Examples

Complete real manifests for each mode.

Runtime contract

What the worker reads and writes inside the container.