DevBolt
Processed in your browser. Your data never leaves your device.

How do I validate a Docker Compose file online?

Paste your docker-compose.yml and click Validate to check for syntax errors, invalid service configurations, undefined networks, circular dependencies, and best practice violations. The tool formats your compose file and highlights issues with fix suggestions. Everything runs in your browser.

Validate docker-compose.yml
Input
version: "3.8"
services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: secret
Output
✓ Valid Docker Compose file
Services: 2 (web, db)
Networks: 1 (default)
Volumes: 0
Version: 3.8
← Back to tools

Docker Compose Validator

Validate and format Docker Compose files. Checks YAML syntax, service structure, network and volume references, dependency chains, and common misconfigurations.

About Docker Compose Validation

Docker Compose is a tool for defining and running multi-container applications. Compose files use YAML to configure your app's services, networks, and volumes.

What we check:

  • Valid YAML syntax with precise error locations
  • Top-level structure (services, networks, volumes, configs, secrets)
  • Service keys against the Compose specification
  • Every service has an image or build directive
  • Network and volume references resolve to declared resources
  • depends_on references exist and don't self-reference
  • Port format validity and restart policy values
  • Unused declared volumes and networks

Format: Re-serializes your Compose file with consistent indentation and optionally sorted keys, making it easier to review and compare in version control.

Everything runs in your browser — no data is sent over the network.

Tips & Best Practices

Pro Tip

Always pin image versions — never use :latest in production

image: postgres:latest means your dev, staging, and production environments can run different Postgres versions. Pin to a specific version (postgres:16.2-alpine) for reproducible builds. Use Docker Compose's extends feature or .env files to manage version numbers centrally.

Common Pitfall

depends_on only waits for container start, not readiness

depends_on: [db] starts the database container before your app, but doesn't wait for it to accept connections. Your app will crash connecting to a database that's still initializing. Use healthcheck + condition: service_healthy, or add retry logic in your app's database connection code.

Real-World Example

Use named volumes for database persistence across restarts

Without a named volume, docker compose down destroys your database data. Define volumes: db-data: and mount it with volumes: - db-data:/var/lib/postgresql/data. Named volumes persist across container lifecycle changes. Use docker compose down -v only when you intentionally want to reset data.

Security Note

Never hardcode secrets in docker-compose.yml

Environment variables with passwords (POSTGRES_PASSWORD: mysecret) get committed to version control. Use env_file: .env with .env in .gitignore, or Docker Secrets for Swarm mode. For local development, docker compose supports a .env file that's automatically loaded.

Frequently Asked Questions

How do I validate a Docker Compose file?
Paste your Docker Compose YAML into DevBolt's validator and it checks the structure against the Compose specification. The tool identifies syntax errors, invalid service options, incorrect port mapping formats, undefined network or volume references, and type mismatches. Common issues include YAML indentation errors, duplicate service names, invalid environment variable syntax, and referencing undefined volumes or networks. The validator provides specific error messages with line numbers so you can fix issues before running docker compose up. This is faster than waiting for Docker to fail at runtime.
What is the difference between Docker Compose v2 and v3 file formats?
Version 2.x was designed for single-host deployments with features like mem_limit, cpu_shares, and the extends keyword. Version 3.x was designed for Docker Swarm compatibility, moving resource configuration under the deploy key. As of Docker Compose V2 (the Go rewrite), the version field is optional. The Compose Specification now unifies features from both versions as the canonical reference. For new projects, omit the version field and use the latest Compose Specification features. DevBolt's validator supports both format versions.
How do I define health checks and service dependencies in Docker Compose?
Use the healthcheck key on a service to define how Docker determines readiness: a test command, interval, timeout, start_period, and retries. Then reference that health status in dependent services using depends_on with condition: service_healthy. The basic depends_on only waits for container start, not service readiness. Health-based dependencies ensure your application does not attempt database connections before PostgreSQL is accepting queries. For production reliability, also implement connection retry logic in your application code.

Related Inspect Tools

DKR

Dockerfile Validator

Validate and lint Dockerfiles for syntax errors, security issues, best practices, and layer optimization

K8s

Kubernetes YAML Validator

Validate Kubernetes manifests for syntax, required fields, best practices, security, and resource limits

API

OpenAPI / Swagger Validator

Validate OpenAPI 3.x and Swagger 2.0 specs for structure, paths, schemas, security, and best practices

ENV

.env File Validator

Validate .env files for syntax errors, duplicate keys, security risks, and best practices — export .env.example templates