Micro, manifest and stack
Microservice (micro)
Section titled “Microservice (micro)”A micro is a launchable repository. In MicroLab you add it once —choosing its folder or cloning it from Git— and from then on it is described by a manifest that MicroLab generates for you.
Manifest
Section titled “Manifest”The manifest is the description of how to start a micro: its technology, its ports,
the infrastructure it needs, its dependencies on other cores and its startup recipe.
MicroLab autodetects it when you add the micro (from files like pom.xml,
application.yml or package.json); you just review it.
The manifest is portable: the path to the repo is stored relative to the workspace, not absolute, so it works across machines. It can be edited from the app (Micros section) or from the CLI.
If you switch branches in the repo, its ports or dependencies may change; MicroLab detects this (drift) and offers to update the manifest from the repository while keeping what you curated by hand. See Switching branches and drift.
The stack is the micro’s technology. Today MicroLab supports:
quarkus · spring-boot · node · angular · python
The stack determines three things: how the micro starts (its command), where its
health is (to know when it’s healthy) and how configuration is injected into it
(-D system properties in the JVM family, environment variables in Node/Python, etc.).
That knowledge lives in a registry of profiles per technology inside MicroLab, not
in the manifest: the manifest only declares stack.kind (quarkus, node…) and, if
needed, some specific tweak. Adding support for a new technology means adding a profile,
not rewriting anything in your micros.