Kubernetes YAML generator online

Build Kubernetes manifests with guided forms and a live preview

Pick a resource type, fill in its real fields, and copy or download the formatted YAML.

100% private No sign-up 13 resource types

Deployment

🔒 100% private — all the YAML is generated in your browser, nothing is uploaded to any server. An honest limit: this generator does not validate against a real cluster, and does not replace kubectl apply --dry-run=server or a linter such as kubeval/kubeconform.
How it works

From a form to a manifest ready to apply

1

Pick the resource type

Deployment, Service, Ingress, Secret, CronJob… choose the tab for the resource you need to create.

2

Fill in the real fields

Each form shows only the fields that belong to that resource: replicas and image for a Deployment, host and paths for an Ingress, a cron schedule for a CronJob.

3

Watch the live preview

The YAML updates on every keystroke, with the right indentation and the required fields for the correct apiVersion.

4

Copy, download or combine

Copy the YAML, download it as .yaml, or add it to a bundle with other resources for a single kubectl apply -f.

Kubernetes YAML manifest generator: why writing them by hand goes wrong so often

A Kubernetes manifest is a YAML file describing the desired state of a resource: how many replicas of your app you want, which image to use, which ports to expose, or how traffic should reach it from the internet. Writing them by hand invites small but fatal mistakes: an indent made with a tab instead of spaces, a selector that doesn't match the Pod's labels, an obsolete apiVersion your cluster no longer supports. K8sCreation solves this with a guided form per resource type: you only see the fields that actually exist in its spec, and the YAML is built with correct indentation automatically.

Broad coverage: from workloads to security

We cover the resources people use daily: Deployment and StatefulSet for stateless and stateful applications, DaemonSet for agents running on every node, CronJob for scheduled tasks, Service and Ingress to expose your app inside and outside the cluster, ConfigMap and Secret for configuration and sensitive data, PersistentVolumeClaim for persistent storage, HorizontalPodAutoscaler for autoscaling, NetworkPolicy to segment traffic, and Role + RoleBinding for RBAC permissions. Each one uses the current stable apiVersion: apps/v1, networking.k8s.io/v1, batch/v1, autoscaling/v2 and rbac.authorization.k8s.io/v1.

Real privacy, not just a marketing promise

A manifest generator tends to handle delicate information: internal service names, private images and, in the case of a Secret, passwords or tokens. That is why K8sCreation generates absolutely everything — including the base64 encoding of Secrets — inside your browser, in vanilla JavaScript, with no backend and no calls to any server. You can check it yourself: open your browser's developer tools and watch the network tab while you use the generator. There are no outgoing requests.

A limit we would rather state loudly

This generator builds YAML that is syntactically correct and carries the usual fields for each resource, but it is not a cluster validator. It doesn't check whether your exact Kubernetes version supports a particular field, whether a custom CRD exists, or whether the resources you reference (a Service, a TLS Secret, a StorageClass) actually exist. Before applying any manifest in production, always validate with kubectl apply --dry-run=server -f file.yaml or a dedicated linter such as kubeconform.

Common questions

Frequently asked questions about Kubernetes manifests

Does this generator validate the YAML against a real cluster?
No. K8sCreation produces a syntactically valid manifest with the usual fields for each resource, but it does not replace kubectl apply --dry-run=server or a linter such as kubeval or kubeconform, which check the manifest against the exact schema of your Kubernetes version and your CRDs. Always validate with those tools before applying in production.
Is my data sent to any server?
No. The whole generator runs inside your browser in JavaScript. The fields you fill in, including the values of a Secret, never leave your device: the base64 encoding of a Secret also happens locally.
What is the difference between a ConfigMap and a Secret?
Both store key-value pairs a Pod can consume as environment variables or mounted files. The difference is purpose: a ConfigMap is for non-sensitive data (a URL, a log level) and is stored in plain text; a Secret is for sensitive data (passwords, tokens, certificates) and Kubernetes stores it base64-encoded — which is an encoding, not encryption — so it remains good practice to protect access with RBAC.
Why does my Service find no Pods?
Almost always because the Service's selector doesn't exactly match the labels on the Pods (the ones from the Deployment's template.metadata.labels). Check that keys and values are identical character for character — it is the number one cause of a Service with no endpoints.
Do I need an Ingress if I already have a LoadBalancer Service?
Not necessarily. A LoadBalancer exposes a single Service directly with an external IP (and bills you for one balancer per Service in the cloud). An Ingress lets you route several hosts and paths to several different Services through a single entry point, applying host/path rules and TLS. For several apps or domains, an Ingress usually works out cheaper and more flexible.
Which apiVersion should I use for each resource?
This generator already uses the current stable apiVersions: apps/v1 for Deployment, StatefulSet and DaemonSet; v1 for Service, ConfigMap, Secret, PersistentVolumeClaim and Namespace; networking.k8s.io/v1 for Ingress and NetworkPolicy; batch/v1 for CronJob; autoscaling/v2 for HorizontalPodAutoscaler; and rbac.authorization.k8s.io/v1 for Role and RoleBinding.
Can I combine several resources in a single file?
Yes. Use the "Add to bundle" button on each form: generate the YAML for each resource (say a Deployment, a Service and an Ingress for the same app) and add it. At the end you download a single .yaml file with every document separated by ---, ready for kubectl apply -f.
What happens if I leave a required field empty?
The generator flags fields with an invalid value in red (an uppercase name, for instance) and won't let you copy or download until they are fixed. Kubernetes names only accept lowercase letters, digits and hyphens, and must start and end with an alphanumeric character.
Learn Kubernetes

Quick guides to understand what you're generating

Deployment

The Kubernetes Deployment YAML template explained

What every field of a Deployment means: replicas, selector, template, resources and the rollout strategy.

 ConfigMap vs Secret

ConfigMap vs Secret in Kubernetes

When to use each, how Secrets are encoded, and why base64 is not encryption.

 Ingress

How to expose an app in Kubernetes with Ingress, step by step

From a ClusterIP Service to a public domain with TLS, explained with a full example.