Skip to content

A micro's manifest

The manifest describes how to start a micro. MicroLab autodetects it when you add the micro and keeps it up to date with “Update from the repository”. You rarely edit it by hand; to see the real one of a micro, microlab service show <id>.

These are the things it declares. Identifiers and keys are in English (project standard).

  • stack — the technology: kind (quarkus, spring-boot, node, angular, python) plus some specific tweak (for example the startup command, which accepts ${port}). The rest of the per-technology knowledge (health path, injection style) MicroLab supplies from the kind.
  • Ports — the port(s) the micro declares (MicroLab remaps them to effective ports at startup).
  • Infrastructure — what it needs from the common compose (Kafka, Redis, Postgres).
  • datasource — its database, with an optional devUrl for the “cloud” mode.
  • Dependencies — for each core it calls: its identifier, the property that is rewritten on injection, the cloud URL and the OpenAPI specification (to generate the mock template).
  • requirements — what a micro requires beyond its stack (another tool or a path that must exist), with optional to make it a warning instead of a failure.
  • Quick toggles — booleans declared by the micro (for example “no authentication”) that are activated as checkboxes and expand to properties at startup.
  • run.native.preCommands — what runs before starting (versioned, of the team). It accepts ${mvn} and can be disabled without deleting:
run:
native:
preCommands:
- command: ${mvn} -pl bootstrap -am install -DskipTests -T 1C
- command: npx ng build shared-ui
enabled: false # declared but off
  • prepSteps — bespoke steps of the micro (for example a database seed) that run on demand or after the first migration (“Prepare database”).

Your machine’s startup customization (individual properties, chosen database, free command) does not live in the manifest: it lives in settings.local.yml, outside Git. See Customize startup.