Skip to content

How projects fit together

Projects, services, environments, and the few terms you need to configure mm.

An mm project is a repository with a .config/mm.yaml file. That file connects your application code and Compose services to the environments where you run them.

The main pieces

For a project with an API and a database:

TermMeaningExample
ProjectThe whole applicationshop
ModuleA directory of code or configurationservices/api
ServiceA container service declared in Composeapi or postgres
StackA set of Compose files deployed togethercompose.yaml
EnvironmentSettings for one use of the projectlocal or production
TargetThe machine where services runYour workstation
RuntimeThe container tool mm uses thereDocker Compose

A module can contain several services. For example, a Laravel module might run both a web service and a queue worker from the same image.

Two configuration files

  • Compose describes how containers run: commands, health checks, ordinary volumes, and third-party images such as PostgreSQL.
  • .config/mm.yaml connects those services to image builds, environments, secret references, managed networks, and HTTP routes.

See which settings go where for an example.

Environment values and secrets

A binding connects a name used by an environment template to a value. The value can be public configuration, such as a database hostname, or a reference to a secret, such as its password. Secret values live in a separate store.

An ingress route connects an HTTPS hostname and path to a service. Local HTTP services can receive automatic addresses such as https://api.shop.test.

Build, review, run

  1. Validate the project with mm config validate.
  2. Build and publish application images, if the project has its own builds.
  3. Run mm deploy plan to see the changes.
  4. Apply the plan using the hash it prints.

Read builds and deployments for the commands. Jobs, schedules, and access gates are optional; add them when your project needs background tasks or restricted routes.