No. Every manifest is generated by plain JavaScript in your browser. Image names, domains, passwords and cluster details never leave your machine — a full set of manifests is a complete map of your deployment.
Free Server Tool — 100% In-Browser
Kubernetes Manifest Generator
Generate production-grade YAML for Deployments, Services, Ingress, PVCs, ConfigMaps, Secrets and HPA — with rolling-update strategy, probes, resource limits and nodeSelector baked in. Plus an optimization checklist and a self-contained performance monitoring script for kubectl. Built entirely in your browser.
Nobody Hand-Writes YAML From Memory at 2 AM
Kubernetes manifests fail in specific, repeatable ways: a missing readiness probe that routes traffic to a cold pod, no resource requests so the scheduler over-packs a node, a rolling update with maxUnavailable=25% that drops capacity mid-deploy, an Ingress annotation for the wrong controller class. This builder emits the manifest with those decisions already made — and the Optimize tab adds the checklist and monitoring script that keep the workload healthy after day one.
Every byte is produced by JavaScript in your browser. Image names, domains, passwords and cluster details are never uploaded — manifests are a complete map of your deployment, and they stay on your machine.
How It Works
1. Name the Workload
App name, image and tag, namespace, replicas, container port.
2. Pick the Quality Bits
Probes, resource requests and limits, security context, update strategy, node placement.
3. Add the Layers
Ingress with TLS, PVC storage, ConfigMap/Secret configuration, HPA autoscaling.
4. Deploy & Watch
Copy the YAML, kubectl apply, then run the monitoring script from the Optimize tab on a cron.
Kubernetes Manifest Generator
Basics (apply to every manifest)
Deployment options
Ingress options
Storage options
ConfigMap / Secret
ConfigMaps are for non-sensitive config; Secrets are for credentials — but base64 is an encoding, not encryption, so never commit either to a public repo.
HPA options
HPA needs the metrics-server installed — the output includes the check and install commands. Note: HPA and a fixed replica count in the Deployment conflict — apply the HPA and let it own the replica field.
Optimize & monitor
Generates two things: an optimization checklist as kubectl commands (right-sizing requests from real usage, PDB, topology spread, termination tuning), and a self-contained monitoring script — one file, no dependencies, cron it on any node with kubectl.
Everything above runs in JavaScript in your browser. Image names, domains, credentials and cluster details you enter are never uploaded — manifests are a complete map of your deployment, and they stay on your machine.
Manifest Defaults, Explained
| Decision | Default in the output | Why |
|---|---|---|
| Update strategy | RollingUpdate, maxSurge 1 / maxUnavailable 0 | Never drops capacity mid-deploy — one extra pod spins up before any old one dies. |
| Readiness probe | On before liveness, generous failure threshold | Traffic only reaches pods that answer; a premature liveness probe restart-loop is a classic outage. |
| Resource requests | Set (CPU 100m, memory 128Mi defaults) | Without requests the scheduler blind-packs nodes and pods get OOMKilled under pressure. |
| securityContext | runAsNonRoot, drop ALL capabilities, seccomp RuntimeDefault | Container escape hardening for free — no reason to skip it in 2026. |
| Pod anti-affinity | Preferred, spread across nodes | One node failure should not take out all replicas. |
| PDB | minAvailable matches replica minus one | Node drains during upgrades do not take the service below capacity. |
| Secrets | stringData, plain values | Kubernetes base64-encodes for you; editing plain values avoids the classic double-encoding bug. |
| HPA | Owns the replica count | A hardcoded replicas field in the Deployment silently fights the autoscaler. |
| Ingress TLS | cert-manager annotation | Certificates issue and renew automatically — no manual kubectl create secret tls. |
Kubernetes Manifest Generator — FAQ
Are my image names or credentials uploaded anywhere?
Why maxUnavailable 0 in the rollout strategy?
With the default 25%/25% strategy, a deploy of four pods may kill one before the replacement is ready — a 25% capacity drop exactly when you are shipping a risky change. maxSurge 1 / maxUnavailable 0 costs one extra pod of resources and guarantees capacity never dips during the rollout. The dropdown offers the default if you prefer fewer temporary pods.
Requests vs limits — what is the difference?
The request is what the scheduler reserves: a pod is guaranteed this much, and it decides which node accepts the pod. The limit is the ceiling: CPU above the limit gets throttled, memory above the limit gets the pod OOMKilled. Set the request near real usage (the Optimize tab shows you how to measure it) and the limit at roughly 1.5–2x the request.
How do I size requests from real traffic?
Do not guess — measure. The Optimize tab generates kubectl top pod over your workload and the kubectl describe node output that shows what the scheduler actually reserved. A week of that data beats any rule of thumb: set requests at the 90th percentile of observed usage plus headroom, and re-check after every major release.
Do I still need the Docker Compose builder?
The two tools cover different stages. Docker Compose Stack Builder is the single-server path: one YAML, no control plane. This generator is the cluster path: replicas, rolling updates, HPA and self-healing. Moving between them is exactly what the kompose path in the Compose tool covers — convert, then replace its output with these hardened manifests.
Why does HPA ignore my replica count?
Because the HPA owns the replicas field once it targets a Deployment. If you also set replicas in the manifest, Kubernetes fights itself: the HPA scales up, your next apply scales it back. The generated HPA ships with the note to remove the fixed replicas count — the min/max in the HPA is your only replica control.
Is a Kubernetes Secret actually secret?
Only if the cluster is. base64 is an encoding, not encryption: anyone with read access to Secrets in the namespace, or root on a node, reads the values. The generator uses stringData so you type plain values (Kubernetes encodes for you — double-encoding is a classic bug), supports immutable Secrets, and the real protections are RBAC, encryption at rest on the API server, and never committing manifests with live credentials. For strong isolation use an external secrets operator or a cloud KMS-backed driver.
What does the monitoring script check?
It is a single bash file with zero dependencies beyond kubectl: pods not Ready, restart loops (a crash-looping pod is found by restart counts rising), OOMKilled events, CPU throttling near limits, nodes under memory pressure, and failed rollouts. It prints a plain report and returns non-zero when something needs attention — cron it every 5 minutes and pipe the output to your alerting channel. It complements, not replaces, Prometheus: it is the safety net that works before you have a metrics stack.