Skip to main content
A microservice is a self-contained module that runs as its own process. A regular feature module is registered into AppModule or SharedModule and served by the API; a microservice has its own entrypoint, its own start hook, its own Dockerfile, and its own port. The generator creates all of that and wires the service into your project’s config so it is reachable as soon as the command finishes. microservice:create scaffolds the module folder, picks a free port, and updates the app config, env config, and tsconfig aliases so nothing is left dangling.

​
What the generator does

It scaffolds a standalone module under modules/<kebab-name>/ with everything it needs to boot on its own, then picks a free port: microservices start at 8030, and the generator scans every modules/*/.env.yml for ports already in use and takes the next one that is free. It declares the service in the app module config and the root env so other parts of the system can resolve its URL. One thing it deliberately skips is the registry, since a microservice is never added to AppModule or SharedModule; it runs standalone.

​
Command

​
Examples

​
Options

See microservice:create for the full command reference.

​
What gets generated

Running the command against a name like billing creates a complete module under modules/billing/: For a full walkthrough of the layout and what each file is responsible for, see Structure.

​
Networking it wires

Because a microservice runs as its own process, the rest of the system needs to know how to reach it. The generator wires that up automatically, updating these files when they exist: The URL is resolved through an env var (e.g. MICROSERVICE_BILLING_URL), so each environment can point at a different host without code changes. See Networking for how services find and call one another.

​
Next: compose the service

The scaffold gives you a running, reachable shell. The next step is to fill it with artifacts — controllers, services, repositories, and the rest — so the microservice actually does its work. Generators like the controller and service commands target the new module by name, the same way they target any other module. See Composition for building out the service with artifacts.

​
Start and stop the microservice

A microservice runs as its own process. Start it from the project root with app:start. Use --modules/--packages (aliases, comma-separated module names) to narrow the run to it:
app:start brings up the shared Docker stack first (when an api or microservice module is in scope), then serves each selected microservice’s entrypoint with hot reload. To stop the running services, interrupt the process with Ctrl+C. app:stop always brings down the app module’s shared Docker stack — it has no way to target a microservice’s individual docker-compose.yml. --modules/--packages only narrow whether the stop proceeds at all (it requires an api or microservice module in scope):
Running talos app:start with no flag starts every discovered module — api, microservice, spa, storybook, and swagger — together, the quickest way to bring the whole system up.

​
Use with Claude and Codex

The generator ships a matching microservice:create skill. It runs the scaffold and then guides your AI agent through the follow-up of confirming the networking wiring and composing the service with its first artifacts. Initialize the skills once for your agent:
Then ask Claude in natural language, and it maps the request to the generator and runs it:
Prompt
For example, the prompt above maps to microservice:create --name=billing, scaffolds the standalone module on the next free port, and wires it into the app config, env, and tsconfig aliases.