¿Odias los anuncios? Ir Sin publicidad Hoy 

Docker Compose YAML Formatter

DatosDesarrollador

ANUNCIO · ¿ELIMINAR?

APORTE

Proceso automático

PROD.

Lado cliente

ANUNCIO · ¿ELIMINAR?

Guía

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.

Cómo Usar

Pega tu docker-compose.yml into 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.

Características

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 version key, links, external_links, and v2-era resource limits that should move under deploy.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, o provider, and that restart uses one of the four valid policies.
Port + healthcheck sanity – Catches malformed port strings, missing target in long-form ports, and healthchecks without a test.
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.

 Preguntas frecuentes

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.