JEKYO: Stop doing ops

One file describes an app end to end: what to run or build, how it is configured, where it is reachable, what it stores.

A complete example

app: acme
services:
  api:
    build:
      context: .
    env:
      DB_URL: postgres://db:5432/acme
      API_KEY: ${API_KEY}
    port: 8080
    http:
      domain: api.acme.com
    resources:
      cpu: 500m
      memory-max: 1Gi
    replicas: 2
    health:
      path: /healthz
  db:
    image: pgvector/pgvector:pg16
    port: 5432
    volumes:
      pgdata: /var/lib/postgresql/data
volumes:
  pgdata:
    size: 10Gi
    backup:
      schedule: "0 3 * * *"

Top-level keys

Key	Type	Required	Description
`app`	string	yes	App name. Lowercase letters, digits, dashes. The namespace becomes `jekyo-<app>`.
`services`	map	yes	The containers to run. See Services.
`volumes`	map		Persistent storage. See Volumes & state.
`description`	string		One-line description. Shown in catalogs and dashboards.
`icon`	string		Logo URL. Shown in catalogs and dashboards.
`inputs`	map	templates only	Template parameters, resolved by `jekyo init`.

The rules that matter

Services find each other by name. db:5432 works inside the app. No links, no network configuration.
Volumes imply state. A service that mounts volumes becomes stateful; its data survives jekyo down and redeploys.
http implies a certificate. Set a domain and TLS is issued and renewed automatically.
Validation is strict. Unknown keys are errors, not warnings. ${VAR} interpolation fails loudly on unset variables.
Nothing is implicit. No default resource limits, no hidden sidecars, no magic labels.

Check before you ship

jekyo render     # the exact Kubernetes YAML this file compiles to
jekyo schema     # JSON Schema, for editors and validation

If jekyo render is happy, jekyo up will be too.