# knative/func: a CLI and Go client for building and deploying Knative functions > Func is the Knative Functions client, a Go library plus a func command that scaffolds, builds and deploys functions onto a Knative cluster. It is aimed at developers who want serverless ergonomics without writing Kubernetes manifests by hand. **knative/func** — Knative Functions client API and CLI - Repository: https://github.com/knative/func - Stars: 365 · Forks: 223 - Language: Go - License: Apache-2.0 - Published: 2026-08-21 · Updated: 2026-08-21 · Language: en - Canonical page: https://hysenlabs.com/projects/knative-func ## The gap func fills between writing a handler and running it on Knative Knative gives you request-driven scaling and scale-to-zero on top of Kubernetes, but the developer-facing loop is still Kubernetes-shaped: you need a container image, a registry it can be pulled from, and a service definition that matches the runtime you wrote. Func exists to collapse that loop. The README describes it as a client library and CLI enabling the development and deployment of Functions, and the repository ships both halves: main.go plus cmd/ for the binary, and pkg/ for the library other Go programs can import as knative.dev/func. The intended user is a developer who already has a Knative installation and wants to spend their time in a handler file rather than in YAML. If you have never run Knative and have no cluster, the tool has nothing to deploy to, and the scaffolding half alone is a thin reason to install it. One thing worth noticing in the repository layout: schema/ and templates/ sit at the top level next to cmd/ and pkg/. That placement is a hint about the design. Function shapes are data, not code paths baked into the binary, and the CLI reads them from those directories. ## How func scaffolds, builds and deploys: the mechanism in the repository Func is a single Go module, knative.dev/func, and the dependency list in go.mod tells you what the pipeline actually does. The build step is not hand-rolled: github.com/buildpacks/pack is a direct dependency, so image construction goes through Cloud Native Buildpacks rather than a generated Dockerfile. Image transport and registry work sit on github.com/google/go-containerregistry and the Docker client libraries, which is why the CLI can push to a registry and inspect what it produced. On the deployment side, github.com/manifestival/manifestival and its client-go adapter appear in go.mod. That library applies a set of manifests to a cluster and tracks them, which matches the shape of a deploy: the CLI renders the Knative Service (and whatever else the function needs) and applies it. The presence of github.com/functions-dev/func-operator suggests the operator path is also represented in the dependency graph, though the README does not describe when the CLI uses it. Runtime support is expressed through templates rather than through separate plugins per language. The templates/ directory is where the scaffolded project content comes from, and plugin/ holds the extension surface. The practical consequence is that adding a runtime is closer to adding template content than to writing new Go code, and that what you can scaffold is bounded by what that directory contains in your checkout. ## Installing the func CLI and getting to a first deploy The README points to the Knative documentation for the QuickStart and for the full documentation set, and it points to docs/reference/ for the command reference. Those are the authoritative places for install instructions; the repository itself carries no Homepage field, so the docs site is the entry point. Once the binary is on your PATH, the workflow is short. Create a project. The CLI scaffolds from the templates directory, so the runtime you name has to exist there. The README's own QuickStart link, rather than the README body, is where the concrete invocation is given; the command reference in docs/reference/ covers creating and deploying functions plus managing configurations and repositories. Read that page for your installed version before you script anything, because flags for registry, namespace and builder settings live there rather than in the README. What the repository does tell you is what a project contains. A scaffolded function carries a func.yaml describing it, and the schema/ directory at the repository root is where the shape of that file is defined. That file is what makes a deploy reproducible across machines, which is the part worth understanding before you write your own pipeline around the CLI. ## Where func stops being the right tool The deploy path assumes a reachable Knative cluster and a registry the cluster can pull from. If your environment is plain Kubernetes without Knative Serving, func has no target that matches its output, and you are better served by a plain container build plus your own manifests. The dependency on Buildpacks also means the build step is opinionated: if your project needs a custom multi-stage Dockerfile with hand-tuned layers, you are fighting the tool rather than using it. A second boundary is the template set. Because scaffolding is driven by templates/ rather than by a plugin per language, a runtime that is not represented there is not a supported starting point, regardless of whether it would run fine on Knative. The README does not document a fallback for that case. The release history is another thing to weigh. The most recent push to the repository was on 2026-08-26, and the releases listed are knative-v1.22.3 on 2026-08-26, knative-v1.23.1 on 2026-08-04 and knative-v1.23.0 on 2026-07-30. Note the ordering: the 1.22 patch line was still receiving releases after 1.23.0 shipped, which is consistent with parallel maintenance branches rather than a single linear track. If you pin a version, pin it deliberately and check which line it belongs to. ## Func against a plain Dockerfile plus kubectl workflow The honest alternative is not another function framework; it is doing the steps yourself. You write a Dockerfile, build and push with your existing tooling, and apply a Knative Service manifest with kubectl or your GitOps controller. That approach has no runtime template constraint, no Buildpacks dependency and no extra CLI to keep current. It also has no scaffolding, no func.yaml to describe the function, and no single command that goes from source to a running revision. The difference in approach is where the abstraction sits. Func abstracts the artifact and the deploy target together, which is why it can offer one command. The manual route abstracts nothing: you own the image, the manifest and the registry credentials, and in exchange every part of the pipeline is inspectable and replaceable. For a team already fluent in Kubernetes manifests, the manual route is often less work than learning a second set of conventions. For a team that wants a handler file and nothing else, func is the shorter path. There is a middle position worth naming: use the scaffolding command for the project layout and then stop, taking the generated project and deploying it with your own pipeline. Nothing in the repository prevents that, and it sidesteps the cluster assumptions in the deploy step entirely. ## Maintenance cost, versioning and the Apache-2.0 licence Func is licensed under Apache-2.0, and the LICENSE file is at the repository root. That is a permissive licence with an explicit patent grant, which matters if you vendor the client library into a Go program: you can import knative.dev/func and ship it without a copyleft obligation on your own code. This is a description of the licence text, not legal advice; if you are redistributing a modified binary, read the attribution requirements with your own counsel. Upgrade cost is driven by the dual version scheme. The Makefile builds version information into the binary from two sources: VERS comes from git tags matching v*, and KVER comes from tags matching knative-*. Both are injected as ldflags into knative.dev/func/pkg/version. In practice that means the binary reports a semver from one tag namespace and a Knative release from another, and the two do not move together. When you upgrade, check both, because a change in the knative-* tag reflects a different compatibility target than a change in the v* tag. The go.mod file pins go 1.26 and carries a replace directive for github.com/imdario/mergo pointing at dario.cat/mergo v1.0.1, with a comment attributing it to a dependency of github.com/openshift-pipelines/pipelines-as-code. If you import the library rather than using the binary, that replace is part of the module's build graph and you should expect to carry it or resolve it on your side. ## Conclusion Adopt func if you already run Knative and want a repeatable local workflow for scaffolding and deploying functions in the runtimes the templates directory covers. Do not adopt it if you have no Knative cluster and no intention of running one, because the deploy path assumes that target. Before committing, check which runtimes the templates directory in your checkout actually ships, and read docs/reference/ for the exact behaviour of the commands in the release you install. ## FAQ ### What is Knative Functions and what does the func CLI do? Func is the Knative Functions client, described in the README as a client library and CLI enabling the development and deployment of Functions. The CLI scaffolds a project from templates, builds it, and deploys it to a Knative cluster. ### Who owns or maintains the knative/func project? The repository lives under the knative organization on GitHub, and the README points to a Knative working group that meets weekly. The last push to the repository was on 2026-08-26, with knative-v1.22.3 released the same day. ### How does knative/func relate to Kubernetes? Func deploys onto a Knative installation running on Kubernetes; it is not a replacement for Kubernetes itself. The CLI renders and applies manifests through the manifestival libraries listed in go.mod, so the cluster remains the execution substrate. ### What are serverless functions in Kubernetes and how does knative/func fit that model? The README frames func as a client library and CLI for developing and deploying Functions, with the deploy step targeting a Knative installation on Kubernetes. Runtime support comes from the templates directory, so the languages you can scaffold are those present there. ## Sources - [Official README](https://github.com/knative/func#readme) - [Project repository](https://github.com/knative/func) - [Release notes](https://github.com/knative/func/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/knative-func