Skip to main content
A service is described by one TOML file at .claude/skills/devboxes/<service>.toml. The filename is the service name, which may contain lowercase letters, digits, -, and _. Service names are shared across the org. A manifest holds facts about the service: where its code lives, what ports it listens on, how to set it up and start it, how to tell that it is healthy, and what it depends on. Decisions such as when to restart, when to run tests, or what else to install are made at the command line, not in the manifest.

Minimal

All fields

Field by field

Rules

  • Bind declared ports however the app prefers — 127.0.0.1 or 0.0.0.0 both work, and Tesser never binds them itself. Other boxes reach a declared port only through the box’s mesh ingress, and the org’s network exposes nothing else, so an all-interfaces bind is not public. Pin the port in the dev server’s config so a collision fails loudly instead of silently drifting to the next port and breaking routing.
  • The service’s own ports and its [deps] keys share the box’s loopback port space, so a port cannot appear in both.
  • When a repository has several manifests, dev and make require the service name. When it has one, that service is the default.
  • Unknown keys are rejected, and the error message lists the keys that exist.
  • Secret values do not belong in a manifest. The [env] table holds names and file lists only, because the manifest is committed to the repository.
  • Dependencies are names, never addresses. Which box a name reaches is decided for each box at run time, as described in Connect a frontend to a backend.