Docker Compose YAML Formatter
指导
Docker Compose YAML Formatter
Paste a docker-compose.yml and instantly get a clean, consistently formatted file with services, networks, and volumes ordered the way Docker Compose conventions expect. The formatter validates the file against the modern Compose Spec, flags deprecated keys like the old top-level version field or legacy links, and warns about unknown service options before they cause runtime failures.
如何使用
- 将您的
docker-compose.ymlinto the input area, or click one of the example links to load a sample stack. - Pick a key order — Compose convention sorts services in the order Compose users expect (image, restart, environment, ports, volumes, …), Alphabetical sorts strictly A-Z, or Preserve keeps your original order.
- Choose 2 or 4 space indentation and toggle Compose Spec validation on or off.
- Read the validation panel for errors, warnings about deprecated keys, and info notices about implicit network references.
- Copy the result or download it as
docker-compose.yml.
特征
- Compose Spec validation – Recognizes top-level
services,networks,volumes,configs,secrets,profiles,include, and extension fields (x-*); flags anything else. - Deprecation warnings – Highlights the legacy top-level
versionkey,links,external_links, and v2-era resource limits that should move underdeploy.resources. - Service-aware key ordering – Reorders each service so identifying keys (
image,build,container_name) come first, runtime config (environment,ports,volumes) sits in the middle, and ops concerns (healthcheck,logging,deploy) land at the bottom. - Reference checks – Detects services that depend on undefined services and warns when a service uses a network that isn’t declared at the top level.
- Service requirements – Verifies every service has at least one of
image,build,extends， 或者provider, and thatrestartuses one of the four valid policies. - Port + healthcheck sanity – Catches malformed port strings, missing
targetin long-form ports, and healthchecks without atest. - Three working examples – A Node + Postgres web app, a WordPress + MySQL + Redis stack, and a multi-service build with profiles and resource limits.
- Local + private – All parsing, sorting, and validation runs in your browser. Your Compose file never leaves the page.
常问问题
-
Why is the top-level version key deprecated?
The version key was used in legacy Compose v1, v2, and v3 to select a schema for the docker-compose CLI. The current Compose Specification merged those schemas into a single, continuously evolving spec, so a version declaration no longer changes anything — recent Docker Compose releases simply ignore it and print a warning. Removing it shrinks the file and avoids confusion when readers assume v3 features are gated by the declaration.
-
What is the Compose Specification and how does it differ from older Compose file formats?
The Compose Specification is the open, vendor-neutral schema that replaces the per-version schemas Docker Compose used through 2020. It is maintained at github.com/compose-spec/compose-spec and is implemented by Docker Compose, Podman Compose, and other runners. Compared to v2 and v3, the spec drops the version field, makes services the only required top-level key, and absorbs Swarm-only fields like deploy as optional metadata that orchestrators may consume.
-
Why prefer a shared network over the links keyword?
links was inherited from Docker's pre-network era and only sets up DNS aliases between containers on the default bridge. Modern user-defined networks already give every service automatic DNS resolution by service name, support multiple isolated networks per stack, and let you control DNS aliases with the aliases option. Because of this, the Compose Spec marks links as legacy and recommends explicit network membership instead.
-
What does each restart policy actually do?
no never restarts the container. always restarts it whenever it stops, including after a daemon restart. on-failure restarts only when the container exits with a non-zero status, optionally bounded by a max-retries count. unless-stopped behaves like always, except a container that was manually stopped before a daemon restart stays stopped. The four values are case-sensitive strings — anything else is rejected by the Compose engine.
-
How does Compose decide whether to pull or build an image?
Compose looks at pull_policy, build, and image together. With pull_policy: always Compose pulls before every up. With missing or if_not_present (the default when only image is set) it pulls only if the image is absent locally. With never it never pulls. When build is present alongside image, pull_policy: build forces a rebuild and tags the result as image, while pull_policy: missing rebuilds only when the image is not yet present locally.
