Docker Compose Stacks let you deploy a whole multi-service application from a single docker-compose.yml in a Git repository. Point Miget at a GitHub or public Git repo, and Miget detects each service in the compose file and provisions it — build-backed apps, standalone images, and managed databases/caches — as one coordinated Stack.

​
Why Use a Stack?

  • One repo, many services — deploy an API, a worker, a database, and a cache together from a single compose file
  • Git-driven — the stack tracks a branch; every deploy re-reads the compose file and reconciles what changed
  • Managed services detected automatically — databases and caches declared in compose are provisioned as managed Miget services, not raw containers
  • No orchestration to wire up — Miget derives resources, environment variables, volumes, and health checks from the compose file

​
How It Works

A Stack is pinned to a Resource (Miget) and belongs to a Project. Each service in the compose file becomes an item in the stack:
  • A service with a build: section becomes a buildable app
  • A service with only an image: becomes a standalone app
  • A service with an image: plus an x-miget.managed: <type> hint (e.g. postgres, redis) becomes a managed service (database/cache) with credentials injected automatically
Every deploy re-reads the compose file on the tracked branch and reconciles the cluster to match it — new services are added, changed services are updated, and removed services are cleaned up. The stack’s overall state and each service’s status are computed from the underlying apps and services.
Managed services (databases and caches) are configured for you — you never supply their connection environment variables. Miget injects them automatically.

​
Creating a Stack

The stack wizard walks through three steps:
  1. Source — choose a GitHub or public Git repository, the branch to track, and the path to the compose file (use the compose path for monorepos, e.g. services/api).
  2. Review — Miget analyzes the compose file and shows the detected services. Any required environment variables (declared in compose with no value) are surfaced here; the wizard pre-fills them with random values, which you can overwrite.
  3. Details — name the stack, pick the project, and choose the target Resource. Miget pre-selects a Resource with enough RAM for the detected services and blocks creation if the selected Resource is over capacity.
On create, Miget validates capacity, provisions each detected service, and runs the initial build.

​
Required Environment Variables

When a compose service declares an environment variable with no value (for example SECRET_KEY:), Miget treats it as required and asks you to provide it during the Review step. Supplying every required variable is what lets the stack build successfully.

​
Deploying and Auto-Deploy

Use the Deploy button on the stack page to re-read the compose file and reconcile the stack. There is no separate “re-analyze” action — every deploy refreshes the manifest. If the stack’s Git configuration has auto-deploy enabled and the tracked branch matches, a push to that branch triggers an automatic deploy using the same pipeline.

​
Deploy Buttons

You can deep-link the stack wizard so a “Deploy to Miget” button lands on a prefilled Source step: 
https://app.miget.com/stacks/new?repo=<github-url-or-slug>&branch=<branch>&path=<compose-path>
  • repo — the repository (a GitHub owner/repo slug or a full HTTPS Git URL)
  • branch — the branch to track (optional)
  • path — the compose file’s subdirectory for monorepos, e.g. path=kafka (optional)

​
Managing Stacks via the API

Stacks are fully manageable over the Miget API. Always call the analyze endpoint first to discover services and required variables before creating:
  • POST /api/v1/stacks/analyze — detect compose services and required env vars from a repo (creates nothing)
  • POST /api/v1/stacks — create a stack (analyzes server-side, then provisions the apps/services)
  • GET /api/v1/stacks / GET /api/v1/stacks/{uuid} — list stacks / get stack details
  • PUT /api/v1/stacks/{uuid} — update label or compose_path
  • POST /api/v1/stacks/{uuid}/deploy — trigger a redeploy
  • PUT /api/v1/stacks/{uuid}/deployment — update the Git deployment config (branch, auto-deploy, repository)
  • GET /api/v1/stacks/{uuid}/deployments — list deployment history
  • DELETE /api/v1/stacks/{uuid} — delete a stack (cascades to its apps and services)
To deploy from a private repository, pass a stored Git credential’s UUID as credential_id. See Registry Credentials for container images and your workspace Git credentials for private repos.

​
Next Steps

GitHub Integration

Connect GitHub for private repos and auto-deploy

Databases

Learn how managed databases work on Miget