Draft, turning a plain app into Kubernetes manifests in one command

The first afternoon with Kubernetes, automated

Draft's stated purpose is blunt: a tool to help developers hit the ground running with Kubernetes, described as a day 0 tool for getting your app on Kubernetes fast. The project documentation puts it plainly: Draft is a tool made for users who are just getting started with Kubernetes or who want to simplify their experience with Kubernetes.

The problem it addresses is the gap between a working application and a running one in a cluster. For most developers that gap is a day of reading about images, deployments, services, ingress and Helm templates, followed by an afternoon of writing YAML. Draft compresses that into a question-and-answer session and a set of generated files.

The mechanism is a guided prompt. The documentation says that in the directory holding your application you run the `draft create` command, and that it walks you through a series of questions prompting you on your application specification. At the end of it you have a Dockerfile and Kubernetes manifests to deploy the application. The prompt shown in the documentation asks you to select a Kubernetes deployment type, with the three options helm, kustomize and manifests.

Those three deployment types are the key decision. Helm gives you a chart with templates, Kustomize gives you an overlay-based patch setup, and plain manifests give you raw YAML. The choice is yours and it is not cosmetic, because it determines what your team maintains afterwards.

The audience is a developer with an existing service and no Kubernetes experience, or a team that wants every new service to start from a known-good template rather than from a blank file.

Installing Draft, and what it needs once it is on your machine

There are two documented install paths, and one platform caveat.

Homebrew is the first.

brew install draft

The second is a shell script piped to bash.

curl -fsSL https://raw.githubusercontent.com/Azure/draft/main/scripts/install.sh | bash

And the caveat is stated right next to them: Windows is supported via WSL Ubuntu. So on Windows you are running a Linux build inside a Linux environment, not a native binary, which is a real constraint if your workflow is otherwise native Windows.

The dependency list in the module file is heavier than a typical CLI. The Azure SDK for Go is there, which is expected given the `draft setup-gh` command talks to Azure, and the Kubernetes client libraries at k8s.io/api, apimachinery, cli-runtime and client-go version 0.36.2. Helm is a dependency at helm.sh/helm/v3 v3.21.2, and Kustomize is there too through sigs.k8s.io/kustomize. That is not accidental: Draft generates Helm charts and Kustomize configuration, so it needs the libraries that render and validate them.

Two dependencies tell you what the validator really is. github.com/open-policy-agent/gatekeeper/v3 and the OPA constraint framework are direct requirements, and github.com/yannh/kubeconform is there as well. The `draft validate` command checks your manifests against policies expressed in the Gatekeeper style rather than against a hand-written list, which is a considerably more serious approach than a linter with hardcoded rules.

The command-line surface is cobra, and promptui handles the interactive questions, with a spinner and coloured output for the terminal experience.

The project ships prebuilt binaries for a spread of platforms. The Makefile's build targets cover Windows amd64, Linux amd64 and arm64, and macOS amd64 and arm64, with the version stamped in through a linker flag on the cmd package.

What create writes, and what generate-workflow adds

The output of `draft create` is described in the command list as the minimum required Dockerfile and manifest files for your deployment, added to the project directory. The about section is broader: Draft generates the Dockerfiles, Kubernetes manifests, Helm charts, Kustomize configuration and other artifacts associated with a containerized application, starting from a non-containerized application.

The dry run output shows exactly what lands on disk. The summary is JSON, with a variables block and a list of files to write.

// Example dry run output
{
  "variables": {
    "APPNAME": "testapp",
    "BUILDERVERSION": "null",
    "IMAGENAME": "testapp",
    "LANGUAGE": "gomodule",  // Note that this variable is in addition to the draft config variables
    "NAMESPACE": "default",
    "PORT": "1323",
    "SERVICEPORT": "80",
  },
  "filesToWrite": [
    "langtest/.dockerignore",
    "langtest/Dockerfile",
    "langtest/charts/.helmignore",
    "langtest/charts/Chart.yaml",
    "langtest/charts/production.yaml",
    "langtest/charts/templates/_helpers.tpl",
    "langtest/charts/templates/deployment.y

The variables are the abstraction worth understanding. Port and service port are separate, so the container listens on one port and the Kubernetes Service exposes another. Namespace defaults to default. Language is the detected application type, here gomodule, and the comment notes that this variable comes in addition to the Draft config variables.

The `filesToWrite` list shows the shape of a Helm deployment: a `.dockerignore`, a `Dockerfile`, a chart directory with `.helmignore`, `Chart.yaml`, a `production.yaml` values file, and templates including `_helpers.tpl` and a deployment template.

The second command extends that into continuous delivery. `draft generate-workflow` automatically builds out a GitHub Action, and the documentation reports it printing that Draft has successfully generated a GitHub workflow for your project. With that file committed, the documentation says you can watch your application get deployed, or apply the files directly with `kubectl apply -f` if you are not using the workflow at all.

setup-gh, and the OIDC handshake it automates

The third command is the one that ties Draft to Azure, and it exists because GitHub Actions authenticating to Azure is a genuinely fiddly manual process.

`draft setup-gh` automates the GitHub OIDC setup process for your project. The documentation explains why that process is needed: it makes sure your Azure account and your GitHub repository can talk to each other, and it is a required step if you plan to deploy through the GitHub Action.

The prompt shown in the documentation asks which account you want to log into, offering Github.com and Github Enterprise Server. That choice matters in practice, because the OIDC subject and audience strings that Keycloak, Entra ID or GitHub's own identity service expect differ between the hosted service and a self-hosted Enterprise Server instance, and a workflow that works in one will fail in the other with a confusing token error.

The command's existence also tells you something about the project's centre of gravity. Draft is a Microsoft project under the Azure organisation, and the Azure dependencies in the module file, the azidentity SDK, the resource manager clients for authorization, resources and subscription, all point at a workflow where the target is an Azure cluster, specifically AKS. The `draft update` command is described as automatically making your application internet accessible, and the repository also contains a `clean-entra-app` Makefile target that deletes an Azure Entra application by display name, so Draft does create Azure-side resources during setup.

That is the tension in the design. The generation commands are cloud-agnostic, they write standard Helm and Kustomize output, but the workflow and identity setup path is built around Azure.

validate runs AKS deployment safeguards against your manifests

The `draft validate` command is the part of the tool with the most lasting value, and it is worth understanding precisely what it checks.

The documentation says it scans your manifests and populates warning messages in your terminal if your manifests are not following best practices. The important sentence is the next one: all best practices are sourced from AKS's deployment safeguards feature, with a link to the official documentation for deployment safeguards, and a pointer to the safeguards package inside the repository so you can see the exact rules used.

That sourcing is what makes the check meaningful. AKS deployment safeguards are a defined, documented set of policy rules that a cluster can enforce, and Draft running the same rules locally means the warning you get in your terminal is the warning your cluster would have raised. The Go dependencies confirm the mechanism, with the Open Policy Agent Gatekeeper framework and the constraint package as direct requirements, so the rules are Rego-style constraints evaluated against your manifests.

The third dependency in that area, kubeconform, is a separate and complementary thing: it validates that your manifests conform to the Kubernetes schemas, so a manifest that is structurally wrong is caught as well as one that is merely against policy.

The `draft info` command completes the picture. It prints information about supported languages and deployment types in JSON format, and the example output shows the shape.

{
  "supportedLanguages": [
    {
      "name": "clojure",
      "displayName": "Clojure",
      "variableExampleValues": {
        "VERSION": [
          "8-jdk-alpine",
          "11-jdk-alpine"
        ]
      }
    }
  ],
  ...,
  "supportedDeploymentTypes": [
    "helm",
    "kustomize",
    "manifests"
  ]
}

The `variableExampleValues` block is the practical part. It tells you which version values the language's builder image supports, so you can pick a runtime version that the generated Dockerfile will actually build. The example shown is Clojure with two JDK Alpine variants.

Where the generated files stop being useful

Draft's own documentation frames the tool as a getting-started aid, and that framing sets the boundary of what it is good for.

The generated output is a starting point, not a maintained artefact. It is a Dockerfile, a chart or a manifest set derived from a question-and-answer session at one moment in time. It does not know about your ingress controller, your image registry, your resource limits, your HPA, your secrets, your network policies, or the fact that your team deploys through Argo CD rather than kubectl. A generated Helm chart that was never reviewed is a chart nobody on the team understands.

The dependency on Azure is the other boundary. `draft setup-gh` and the Entra application cleanup target make sense for an Azure workflow. The generation commands are portable, but the OIDC automation is where the Azure assumption lives, and a team on GCP or a different CI system gets the files without the automation.

There is a documentation gap as well, and it is worth knowing before you commit. The reference section of the README ends mid-sentence, and the dry run example is truncated partway through the filesToWrite list, with the deployment template name cut off. The commands are all listed and their purposes are stated, but the deep configuration reference is not in the excerpt available, so the details of what you can tune in the Draft config are something you will need to look up in the repository or the docs directory.

The practical rule that follows is simple. Use Draft to get a running deployment, then read every file it wrote before you let it near a cluster you care about. The tool is at its best in the first hour and at its worst in the first month.

Editorial conclusion

Draft suits a developer or team that has an existing application, has never had to containerise it for Kubernetes, and wants a working set of manifests in an afternoon rather than a week of learning the platform by hand. It does not suit an application that already has mature deployment tooling, and it does not suit a team that needs the generated manifests to be a long-term maintained artefact rather than a starting point. Verify first that the language and version variables your application needs appear in the output of draft info, that the deployment type you choose matches how your team actually ships, and that the generated manifests pass draft validate before you let a workflow apply them to a cluster.

Frequently asked questions

Official sources

1. Azure/draft on GitHub
2. Issues
3. License: MIT
4. README
5. Releases