← devnestio

Docker Compose Validator YAML

docker-compose.yml

0 lines

Results

—

Paste your docker-compose.yml and click Validate

What is Docker Compose Validator?

Docker Compose Validator checks your docker-compose.yml files for syntax errors, schema violations, and common configuration mistakes. Paste or upload a compose file to validate it against the Compose Specification schema, detect undefined services in depends_on, find missing environment variables, check for insecure default configurations, and get suggestions for best practices (non-root users, resource limits, health checks).

Docker Compose files use YAML format with a defined schema (compose-spec.io). The top-level keys: version (deprecated in Compose V2), services (the containers), networks (custom networks), volumes (persistent storage), configs (configuration files), secrets (sensitive data). Each service can define: image or build, ports, environment, volumes, networks, depends_on, healthcheck, restart policy, resource limits (mem_limit, cpus), and user (for non-root containers).

Common docker-compose issues: missing depends_on causing services to start before their dependencies, using latest tag for images in production (pin to a specific version for reproducibility), exposing ports on all interfaces (0.0.0.0) instead of localhost (127.0.0.1), running containers as root (security risk), no restart policy (containers do not recover from crashes), and no memory limits (one container can OOM the host).

How to Use

  1. Paste your docker-compose.yml content into the input panel.
  2. Click 'Validate' to check schema conformance and run best-practice lint rules.
  3. See errors (schema violations), warnings (best practice issues), and info.
  4. Click any issue to jump to the affected service or key in the YAML.
  5. Use 'Format' to apply consistent YAML indentation to your compose file.

Examples

Missing dependency

Result: depends_on: [db] but no 'db' service defined -> Error: Service 'db' in depends_on is not defined

Unpinned image

Result: image: postgres:latest -> Warning: Use a specific version tag (e.g., postgres:16) for reproducibility

Exposed to all interfaces

Result: ports: - '5432:5432' -> Warning: Binds to 0.0.0.0, exposes port to all network interfaces

Frequently Asked Questions

What is the difference between Docker Compose V1 and V2?

Docker Compose V1 (docker-compose, Python): installed separately, used the version: field in docker-compose.yml (version: '3.8'), slower, now deprecated. Docker Compose V2 (docker compose, Go): integrated into Docker CLI (docker compose up), ignores the version: field (uses Compose Specification instead), faster, actively maintained. The Compose Specification (compose-spec.io) is the schema that V2 implements. Switch: use docker compose (space, not hyphen) for V2. Most modern Docker installations include Compose V2 by default. The version: key at the top of the file is now obsolete -- you can safely remove it.

How does depends_on work in Docker Compose?

depends_on: [service-name] ensures the named service is started before this service. In Compose V2 with conditions: depends_on: db: condition: service_healthy waits until the db service's healthcheck reports healthy (not just started). Without condition, depends_on only waits for the container to start -- not for the application inside to be ready. For databases: add a healthcheck to your db service: healthcheck: test: ['CMD', 'pg_isready', '-U', 'postgres']. Then use service_healthy in depends_on. This prevents the common 'database not ready' race condition on startup.

How do I use Docker secrets for sensitive values?

Docker Swarm secrets: define in secrets section of docker-compose.yml. Services access them as files at /run/secrets/secret_name. For non-Swarm (development): use environment variables from .env file (docker compose uses .env automatically). For production without Swarm: use a secret manager (AWS Secrets Manager, HashiCorp Vault) and inject as environment variables at runtime. Never hardcode secrets in docker-compose.yml or Dockerfiles -- they end up in image layers and version control. docker compose config shows the resolved config with substituted variables.

What are Compose health checks and why are they important?

Health checks verify that a container's application is ready (not just running). Syntax: healthcheck: test: ['CMD', 'curl', '-f', 'http://localhost:8080/health']. Or: test: ['CMD-SHELL', 'pg_isready -U postgres']. interval (how often to check, default 30s), timeout (check timeout, default 30s), retries (failures before unhealthy, default 3), start_period (grace period during startup). Health checks enable: depends_on condition: service_healthy, automatic restarts on failure (with restart: policy), and better visibility in docker ps (shows health status). Essential for reliable multi-service startup ordering.

How do I limit container resources in Docker Compose?

In Compose V2, use the deploy section: services: web: deploy: resources: limits: cpus: '0.5' memory: 512M reservations: memory: 256M. Note: deploy.resources is only honored in Swarm mode by default. For standalone containers, use: mem_limit: 512m, cpus: 0.5 at the service level (Compose V2 honors these in standalone mode). Why limit resources: prevents one container from consuming all host memory (OOM kill). cpus: limits CPU shares proportionally. mem_limit causes the container to be killed if it exceeds the limit (instead of crashing the host).

Related Tools