K8s Manifest Splitter

K8s Manifest Splitter

Split a multi-document YAML file into separate manifests and download them as a ZIP.

Multi-Document YAML

Paste multi-doc YAML to split

Documents should be separated by ---

Tip: Files are named {kind}-{name}.yaml. Duplicates are automatically numbered.

Features

  • Split a multi-document YAML file into individual resource files
  • Name output files by resource Kind and metadata.name (e.g., <code>deployment-my-app.yaml</code>)
  • Filter by Kind: extract only Deployments, Services, ConfigMaps, etc.
  • Download individual resources or all as a ZIP archive
  • Preview each split document before downloading
  • Count of resource types found in the input

Common Use Cases

  • Break a large Kubernetes manifest bundle into per-resource files for GitOps workflows
  • Extract specific resource types from a Helm-rendered output
  • Reorganize a monolithic <code>all-in-one.yaml</code> into a structured directory layout
  • Separate Secrets from other resources for different access controls
  • Prepare resources for import into ArgoCD or Flux as individual files

Multi-Document YAML in Kubernetes

Kubernetes tooling supports multi-document YAML files: multiple resources separated by --- in a single file. This is convenient for bundling related resources (e.g., a Deployment, Service, and ConfigMap for one app), which can be applied together with kubectl apply -f bundle.yaml.

However, as applications grow, monolithic bundle files become hard to manage. GitOps practices (ArgoCD, Flux) and most team workflows prefer one resource per file, organized in directories. The splitter automates the tedious work of extracting each resource from a bundle into its own file.

A common pattern: use a monolithic file during development for quick iteration, then split before committing to a GitOps repository.

Examples

Valid - Multi-doc input
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
---
apiVersion: v1
kind: Service
metadata:
  name: my-app-svc
Valid - Split output 1
# deployment-my-app.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app

Frequently Asked Questions

What naming convention does the splitter use?

Files are named {kind}-{name}.yaml (lowercase). For example, a Deployment named my-api becomes deployment-my-api.yaml. If namespace is set, it is included: deployment-my-api-production.yaml. All names are kebab-cased and lowercased.

Can I filter by resource type?

Yes. Use the Kind filter to extract only specific resource types — for example, extract all Secret resources from a large bundle to manage them separately (e.g., with Sealed Secrets or External Secrets).

What about resources with no name?

Resources without a metadata.name field (uncommon in practice) are named sequentially: deployment-1.yaml, deployment-2.yaml. Review these files manually before using them.

How do I apply split files with kubectl?

Apply an entire directory: kubectl apply -f ./manifests/. Apply recursively: kubectl apply -R -f ./manifests/. This is the standard GitOps pattern where each resource lives in its own file under a structured directory.

Related Tools

K8s Inspector

Inspect split resources

Try it

K8s API Checker

Check APIs in each file

Try it

YAML Formatter

Format individual files

Try it

Helm Templater

Render and then split charts

Try it

💡 Tips

  • After splitting, organize files into subdirectories by resource type: <code>deployments/</code>, <code>services/</code>, <code>configmaps/</code>, <code>secrets/</code>.
  • Never store raw Kubernetes Secret resources in git — use Sealed Secrets or External Secrets Operator instead.
  • Run the API Checker on the split files to verify all resources use current API versions before applying.
  • Use the filter feature to extract only Secrets for separate handling with restricted access controls.