Dummy Kubernetes Manifest Generator

About this generator

Every microservice needs a Deployment, a Service, and a ConfigMap — three YAML files with label selectors, resource limits, and environment blocks that must be internally consistent. Writing them from scratch means hunting for the correct apiVersion and getting indentation right. A Kubernetes manifest generator handles that boilerplate. Three inputs control output. App name sets metadata.name, label values, and container name throughout — sanitized to a valid lowercase DNS label. Resource kind generates a Deployment, Service, ConfigMap, or all three with --- dividers. Replicas sets spec.replicas. The Deployment includes requests (128Mi, 100m) and limits (256Mi, 500m), an env block, and a randomized port. The Service uses NodePort. The ConfigMap includes APP_NAME, LOG_LEVEL, MAX_POOL_SIZE, and FEATURE_FLAG_X. Run kubectl apply --dry-run=client to validate before adding to a CI pipeline.

How to use

1. Type your application name in the App Name field to set the metadata and label values throughout the manifest.
2. Select the Resource Kind you need — Deployment, Service, ConfigMap, or all three combined in one file.
3. Set the Replicas count to control how many pod instances the Deployment controller will maintain.
4. Click Generate to produce the complete YAML manifest with selectors, resource limits, and env var stubs filled in.
5. Copy the output and paste it into a .yaml file, then update the container image field before applying to a cluster.

Use Cases

• •Generating YAML fixtures to test Kubernetes admission webhook logic in CI without touching a live cluster
• •Scaffolding a Deployment, Service, and ConfigMap together when bootstrapping a new microservice repo
• •Teaching label selector relationships between Deployments and Services in a Kubernetes workshop
• •Dry-running kubectl apply --dry-run=client commands against realistic manifests to validate pipeline logic
• •Creating placeholder ConfigMap manifests to prototype environment variable injection patterns in staging

Tips

• →Generate the 'all' kind first to understand how Deployment labels, Service selectors, and ConfigMap references connect in one file.
• →Use a real app name matching your Docker image repository path — it makes the manifest easier to adapt without hunting through the YAML.
• →Set replicas to 1 when generating fixtures for unit tests; use 2+ when testing pod disruption or rolling update scenarios.
• →Paste the output into https://kubeval.instrumenta.dev/ or run kubectl apply --dry-run=client to validate structure before adding it to a pipeline.
• →For multi-service architectures, generate each service separately with distinct app names, then combine them in one file with --- separators between documents.
• →The generated ConfigMap is a good template for externalizing environment-specific config — add your real keys there instead of hardcoding them in the Deployment env block.

FAQ