Skip to content

Micro, manifest and stack

A micro is a launchable repository. In Aseptic you add it once —choosing its folder or cloning it from Git— and from then on it is described by a manifest that Aseptic generates for you.

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. Aseptic 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; Aseptic 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 Aseptic supports:

quarkus · spring-boot · node · angular · python · go · dotnet

Each stack keeps its configuration somewhere different, and Aseptic reads it there to autodetect ports, database and dependencies: application.yml in the JVM family, .env in Node, Python and Go (plus config.yaml in Go) and appsettings.json in .NET. The active profile’s files (application-local.yml, .env.local, appsettings.Local.json) override the base ones, just as the framework itself would.

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, Go and .NET, flags in Angular).

That knowledge lives in a registry of profiles per technology inside Aseptic, 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.