Download YAML File Samples

Sample YAML files serve as realistic test inputs any time you need a real YAML document without writing one from scratch. The most common use cases are testing YAML parser libraries (PyYAML, js-yaml, go-yaml, SnakeYAML), developing CI/CD pipeline configs before connecting to a real runner, validating Kubernetes manifest schemas with tools like kubeval or kustomize, testing Helm chart rendering, building YAML-driven configuration systems, and providing example fixtures in developer documentation.

The DevOps templates are especially practical — a Docker Compose file or GitHub Actions workflow that's syntactically correct but contains no real credentials is exactly what you need when testing a pipeline linter or config validator without touching production files.

There is no technical difference — both extensions refer to exactly the same format and are parsed identically. The .yml extension became common in the early days because some older systems had a four-character extension limit. Today, .yaml is the officially recommended extension per the YAML specification, but .yml is widely used in practice and accepted by every tool. GitHub Actions workflows use .yml by convention; Kubernetes manifests commonly use .yaml; Docker Compose accepts both. Use whichever your project or tool ecosystem standardizes on.

Anchors and aliases are YAML's built-in mechanism for reusing a value or block without repeating it. You define an anchor with &name on a value, then reference it elsewhere with *name. For example, in a GitLab CI config you might define a common job template as &default_job and then reuse it in multiple jobs with <<: *default_job (a merge key). This keeps the file DRY and is heavily used in complex CI/CD configs. Parsers that don't support anchors will fail on files that use them, which makes the anchor-enabled templates useful for testing parser conformance.

The --- line explicitly marks the beginning of a YAML document. In a single-document file it is optional but considered good practice — many tools (kubectl, Ansible, Helm) expect it to be present. In a multi-document file (multiple documents in one .yaml file) it is required as the separator between documents. The Kubernetes Full Stack template uses this to put a Deployment, a Service, and a ConfigMap in a single file, which is standard practice for shipping related resources together. Parsers that handle the stream correctly will split on --- and return each document separately.

Yes. All templates are generated to be compliant with YAML 1.2, which is the current specification and the version implemented by most modern libraries (PyYAML 6+, js-yaml 4+, go-yaml v3). A few important YAML 1.2 vs 1.1 differences to be aware of: in YAML 1.2, bare yes, no, on, and off are no longer parsed as booleans — only true and false are. The files here use explicit true/false throughout to avoid ambiguity. All strings that could be misinterpreted as other types are quoted.

A single .yaml file can contain multiple independent documents, each separated by a --- line. This is widely used in Kubernetes, where it is standard practice to ship a Deployment and its associated Service in a single manifest file. When you run kubectl apply -f manifest.yaml, kubectl reads the entire file and applies each document separately. The Kubernetes Full Stack template demonstrates this — it contains a Deployment, a Service, and a ConfigMap separated by --- markers. YAML parsers that support streams (most do) expose each document as a separate parsed object.

YAML tries to infer types from bare values: 42 becomes an integer, 3.14 becomes a float, true becomes a boolean, null becomes null. This is convenient but causes bugs when a value looks like another type — for example, a port number like 8080 will be parsed as an integer (usually fine) but a version string like 1.10 will be parsed as the float 1.1 (usually not fine). Quote anything that should stay a string: version numbers ("1.10.0"), values containing colons or special characters, and any value that begins with @, |, >, !, or %. The templates here quote all values where type ambiguity could cause a problem.

Yes. The Kubernetes Deployment, Service, and Full Stack templates are structured to match real manifests — correct apiVersion, kind, metadata, and spec hierarchy, valid label selectors, proper container port definitions, and resource request/limit blocks. They will pass schema validation with kubeval, kubeconform, and similar tools. They intentionally use placeholder image names (myapp:1.0.0) and non-real namespaces so they are safe to use in any environment without accidentally referencing a real registry or cluster resource.