Docker Compose Stacks

Docker Compose Stacks let you deploy a whole multi-service application from a single compose.yaml 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.

Miget recognizes your compose file under any of the standard Docker Compose names, so an existing project works without renaming anything:

compose.yaml / compose.yml - the current Compose defaults
docker-compose.yaml / docker-compose.yml - the legacy defaults

The examples below use compose.yaml, but any of these names is detected the same way.

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.

Tuning Your Stack for Miget (`compose.miget.yaml`)

A plain compose.yaml describes your services, but it says nothing about how much memory each one needs, which one is public, or how large a volume should be. Miget reads those platform details from an optional compose.miget.yaml placed next to your compose file. Miget automatically layers it on top of the base compose at detect and deploy time - plain docker compose up ignores it, so your repo still runs locally unchanged. The overlay mirrors your service and volume names and carries only an x-miget block on each:

# compose.miget.yaml - layered onto compose.yaml at deploy time; plain docker compose ignores it
services:
  web:                    # the public HTTP entry - must listen on port 5000
    x-miget:
      ram: "1024"         # memory: plain MB, or a unit like "1Gi"
  worker:
    x-miget:
      ram: "512"
      private: true       # internal only, not exposed to the internet
  db:                     # provision a managed database instead of a container
    x-miget:
      managed: postgres
      cpu: "500m"
      ram: "1Gi"
      storage: "5Gi"
      extensions: [vector]
  cache:
    x-miget:
      managed: valkey
      ram: "256Mi"

volumes:
  webdata:
    x-miget: { size: "5000", type: RWO }   # persistent disk: plain MB, or a unit

`x-miget` reference

On a service:

Key	Meaning
`ram`	Memory for the service - plain MB (`"1024"`) or a unit (`"1Gi"`, `"256Mi"`). Set one on every service.
`cpu`	CPU in millicores (`"500m"`, `"1000m"`). Optional; a default is applied when omitted.
`private: true`	Keep the service internal - reachable by the rest of the stack but not exposed to the internet. Mark every service except the single public entry.
`managed: <type>`	Provision the service as a managed Miget add-on instead of a raw container (such as `postgres` or `valkey`). Miget runs it, backs it up, and injects its connection variables automatically - you never supply them. See Databases.
`storage`	Disk size for a managed service (`"5Gi"`).
`extensions`	Postgres extensions to enable on a managed `postgres` (e.g. `[vector]`, `[citext]`, `[hstore]`).

On a named volume:

Key	Meaning
`size`	Volume size - MB (`"5000"`) or a unit (`"5Gi"`).
`type`	Access mode: `RWO` (per-node block volume - the default) or `RWX` (shared across replicas).

Conventions

Port 5000 for the public entry. Miget’s ingress only reaches port 5000, so the one service you expose must listen on 5000. Mark everything else private: true.
One block per node, not replicas. For clustered software (databases, brokers) each node needs its own identity and volume - add a service block per node rather than scaling with replicas.
Configure image-only services via environment variables. Compose command: overrides don’t reach per-app deploys, so image-only services must be configurable through env vars.

No compose.miget.yaml yet? Add one next to your compose file: give every service an x-miget.ram, mark internal services private: true, flag managed databases/caches with managed:, size your named volumes, and make sure the public service listens on port 5000 - then re-run analyze to confirm the detected resources.

Ready-made Stacks (deployable.sh)

Miget publishes a catalogue of ready-to-run, already-tuned stacks - WordPress, Ghost, n8n, Kafka, Supabase, and many more - at deployable.sh (source: deployable-sh/stacks). Each ships a base compose.yaml plus a compose.miget.yaml with the overrides above, so it deploys correctly out of the box. To deploy one, create a stack pointed at the deployable-sh/stacks repository and set the compose path to the stack’s directory (for example wordpress). Prefer the catalogue over an arbitrary compose file found on the web - a random compose.yaml won’t carry Miget’s overrides and is likely to fail.

Creating a Stack

The stack wizard walks through three steps:

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).
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.
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

Add a one-click Deploy to Miget button to any repository with a single link:

https://miget.com/deploy?repo=<github-url-or-slug>&branch=<branch>&path=<compose-path>

miget.com/deploy auto-detects the right flow from the repo: a Compose Stack when a compose file is present, a container image when you pass image, otherwise a plain app. It then forwards you to the matching wizard with the Source step prefilled. Supported parameters:

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)
image - a container image to deploy instead of a repo (optional)
type - force stack, app, or image to skip auto-detection (optional)

Drop the button straight into a README with the Markdown badge:

[![Deploy to Miget](https://miget.com/deploy-to-miget.svg)](https://miget.com/deploy?repo=https://github.com/OWNER/REPO)

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.

Getting Started

Overview

Languages

Deployments

Databases

Persistent Storage

Networking

Monitoring

How-to

Troubleshooting

Pricing

Security

Docker Compose Stacks

Why Use a Stack?

How It Works

Tuning Your Stack for Miget (`compose.miget.yaml`)

`x-miget` reference

Conventions

Ready-made Stacks (deployable.sh)

Creating a Stack

Required Environment Variables

Deploying and Auto-Deploy

Deploy Buttons

Managing Stacks via the API

Next Steps

GitHub Integration

Databases

​Why Use a Stack?

​How It Works

​Tuning Your Stack for Miget (compose.miget.yaml)

​x-miget reference

​Conventions

​Ready-made Stacks (deployable.sh)

​Creating a Stack

​Required Environment Variables

​Deploying and Auto-Deploy

​Deploy Buttons

​Managing Stacks via the API

​Next Steps

GitHub Integration

Databases

Why Use a Stack?

How It Works

Tuning Your Stack for Miget (`compose.miget.yaml`)

`x-miget` reference

Conventions

Ready-made Stacks (deployable.sh)

Creating a Stack

Required Environment Variables

Deploying and Auto-Deploy

Deploy Buttons

Managing Stacks via the API

Next Steps