Skip to content

Micros section

The Micros section is the home of your micros: on the side, the list; in the center, the editor of the selected micro.

  • + Add micro — you choose the repo’s folder and MicroLab autodetects its stack, ports, infrastructure and dependencies, shows you the warnings and, after confirming, generates its manifest.
  • Import micro from Git — clones the repo (using your Git connection for private hosts) and detects it in one step.

Adding shows you what was detected before saving; an existing manifest is not overwritten (to regenerate it, use “Update from repository”).

Display name, default mode (native/container) and startup profile.

The technical data of each dependency on another core: its identifier, the property that is rewritten on injection, the cloud URL and the OpenAPI specification (source to generate the mock template). Where each one points —local, cloud or mock— is decided in the scenario, not here.

Non-versioned customization of this micro’s native startup (saved in your settings.local.yml). At the top, the day-to-day:

  • Database — point the micro at another DB (default, local, cloud or custom). See Point at another DB.
  • Startup script/command according to the stack (npm script, Angular configuration, stack command…).
  • Pre-commands — what runs before starting (build workspace libraries, install sibling modules of a Maven multi-module…). They live in the manifest: valid for the whole team.

And a collapsible advanced block: extra arguments, system properties, environment variables, full startup command and a preview of the effective command. All of this can be imported/exported per micro. See Customize startup.

The final value of each of the micro’s properties and which layer it comes from: the repo’s application.yml, the remote configuration or what MicroLab injects at startup. Useful to understand why a property ends up with a specific value.

If the micro is a Git repo: switch branches, do fetch and pull (--ff-only), see how many commits you are ahead/behind the remote, and —when the repo differs from the manifest— update it from the repository while keeping what you curated by hand (drift). Git access is read-only; it never does push. See Switching branches and drift.

  • Update manifest from the repository — refreshes the detected fields without losing your customization.
  • Locate folder — if the repo moved, you repoint its path.
  • Delete micro — removes the manifest (doesn’t touch the repo); asks for confirmation.
  • Export / Import micros — self-contained .micro.yml files.