Project Calico: the Kubernetes network policy layer that became its own data plane

One monorepo, at least four things called Calico

The repository is a Go monorepo with a module path of `github.com/projectcalico/calico` and a Go requirement of 1.27.1. The manifest is enormous, and the dependency list is itself a description of the project's scope: the CNI plugin interface, the upstream CNI plugins, the AWS SDK for cloud metadata, cfssl for certificate issuance, the Envoy Gateway and the Elastic cloud operator.

module github.com/projectcalico/calico

go 1.27.1

tool golang.org/x/tools/cmd/goimports

The directories tell the same story more clearly. `felix/` is the node agent and the actual data plane, which is the part everyone means when they say Calico. `cni-plugin/` is what the kubelet calls. `calicoctl/` is the command line client. `confd/` holds the template daemon that renders BGP configuration. `typha/` is a daemon that fans out Felix state to many watchers over a single connection, which is the trick that lets Calico run on large clusters without every node watching every resource.

Then there are the parts that are less familiar: `app-policy/` for the policy enforcement agent, `guardian/` for a policy enforcement daemon, `pod2daemon/` for communicating with pods that have no network identity, `key-cert-provisioner/` for issuing node certificates, `goldmane/` which is a high scale metrics aggregation component, and an `istio/` directory suggesting some service mesh integration.

The README acknowledges the sprawl by pointing outward. Its list of projects the team maintains includes a separate repository for the Golang API, a separate VPP dataplane repository, and a separate BIRD repository. The monorepo you are reading is the core, not the whole product.

Four data planes, and the README treats them as one bullet

The single most consequential choice in Calico is the data plane, and the README compresses it into one line under why use Calico: eBPF, standard Linux, Windows and VPP.

Those are not variations on a theme. eBPF replaces iptables and IP tables with programs compiled into the kernel at load time, which removes the rules-per-pod scaling wall but ties you to a kernel feature set and to Calico's own compilation pipeline. Standard Linux keeps the iptables and eBPF hybrid approach that has existed since the beginning. VPP is a userspace dataplane with its own performance characteristics and its own separate release cadence in a sibling repository. Windows is not a variant so much as a parallel implementation, and it ships as its own zip artifact.

The GitHub topics reinforce how broad the surface is: cni, cni-plugin, ebpf, xdp, kubernetes-windows, windows, network-policy, identity-aware-policy, host-protection, observability, and openstack.

That last one is the interesting leftover. Project Calico began life as an OpenStack networking component, and the topic tag survives from that era, while the README never mentions OpenStack and the current documentation is Kubernetes-only. Tags like cats, which also appears, are harmless. A stale platform tag on a project whose entire install path is `kubectl apply` of Kubernetes manifests is a small but real signal that repository metadata is not maintained with the same care as the code.

Release artifacts reveal what actually ships together

The newest release is v3.32.2, published 2026-08-30, and its body is a list of downloadable bundles rather than a changelog. The release notes live in a markdown file on a release branch of the same repository, which is a pattern worth knowing about if you are trying to find out what changed.

The artifacts are more informative than the notes. There is a general tarball with container images, binaries and Kubernetes manifests, a separate zip for Calico on Windows, a Helm 3 chart for the Tigera operator that is also published to an OCI registry, a CRD chart for the `crd.projectcalico.org/v1` API, a second CRD chart for `projectcalico.org/v3` that is explicitly labelled tech-preview, and an OpenShift bundle.

Two facts sit side by side there. The v1 CRDs are the stable API, and a whole new major version of the same CRDs exists in the same release marked as a preview. If you are starting fresh you have a choice the README does not discuss, and if you are upgrading you need to know which API your manifests target before you touch anything.

The release history also shows parallel maintenance branches rather than a single line. v3.32.1 shipped 2026-06-26, then v3.31.7 shipped 2026-08-21, then v3.32.2 shipped 2026-08-30. A patch on the older minor line landing after a newer minor release is exactly what a supported long-term branch looks like, and it means you should be reading release notes for your branch, not the newest tag.

The README badge that points at the wrong repository

Small details tell you how a README is maintained. The Go package badge near the top of the Calico README is a good example. The image it loads is the Kubernetes one, pointing at `k8s.io/kubernetes`, while the link it wraps goes to the Calico API package. Two different repositories in one badge, which means the badge was copied from another project's README and only half edited.

The rest of the badge row is in better shape: a Go Report Card badge for this repository, an ArtifactHub badge that resolves to the `tigera-operator` Helm repository rather than to anything in this tree, an Apache license badge pointing at the LICENSE file, and a CII Best Practices badge.

The Apache license badge is worth pausing on, because the file is named `LICENSE.md` rather than `LICENSE`. That is trivial in itself. What it illustrates is that the README is a marketing page maintained by the community team, complete with emoji-headed sections, an ambassador program called Calico Big Cats and a newsletter subscription, while the engineering facts live in a documentation site, a design document in the tree and per-component make targets.

The build system shows the same split. The root Makefile resolves a package name, includes a metadata file and a shared library Makefile, and defines a Docker-based invocation that mounts the working tree into a container running as the current user ID, with separate Go and package caches mounted so builds stay incremental. The clean target recurses into sixteen component directories individually rather than using a pattern, which is what a monorepo with heterogeneous sub-builds ends up looking like.

Claims to read as claims

The README says Calico powers more than eight million nodes daily across 166 countries, and that it has over 200 contributors from a range of global companies. Both are unverifiable from the repository, and both are the kind of number that ages badly in a README nobody regenerates.

There is a more checkable claim nearby. The README says Kubernetes network policy support is continually being defined and extended, which is vague, but the repository backs the general direction: the tree contains an `app-policy` directory and a `guardian` daemon, and the topic list includes identity-aware-policy and host-protection, both of which are extensions beyond what upstream network policy specifies.

That distinction matters for anyone writing policy. Standard Kubernetes network policy is namespace and pod selector based, enforced additively by the plugin. Identity-aware policy adds a principal dimension, which is closer to how AWS IAM or Google IAM works, but it is Calico-specific CRDs rather than something you can move between plugins. Host protection is likewise about preventing a workload from tampering with its own node's networking.

If your requirement is plain network policy, any conformant plugin will do and Calico is one option among several. If your requirement is workload identity in policy or host-level protection, you are choosing Calico specifically, and you should read the CRD documentation for the API version you intend to use rather than the README bullet list.

Reading the repository as an architecture document

The most useful thing about this repository is that you can read it to understand how a CNI plugin is put together. `DESIGN.md`, `DEVELOPER_GUIDE.md`, a `design/` directory and `AI_POLICY.md` are all in the tree, alongside `CONTRIBUTING.md` and a separate `CONTRIBUTING_DOCS.md`, which tells you documentation contributions are handled as their own workflow.

There are also directories for the things you would have to write yourself otherwise: `libcalico-go/` for the client library, `lib/` for shared internal packages, `e2e/` and `test-tools/` for the test harnesses, `manifests/` and `charts/` for the packaged install, `networking-calico/` for the daemon set manifests, and `operator/` for the operator itself. A `gomodder_config.yaml` and a Renovate configuration file handle dependency management, and `.semaphore/` and `.argoci/` indicate the older and newer CI systems coexisting.

The `hack/` directory and the copyright tooling in the Makefile are also a small lesson. The build updates copyright headers on changed files relative to a base branch, and inserts a header from `hack/copyright.template` into new Go files that lack one. That is a level of process hygiene you rarely see outside large enterprise codebases, and it is a reasonable signal about how the project is run.

If you are evaluating Calico, read those files in that order. The README tells you what to believe, and the repository tells you what is true.

Editorial conclusion

The question with Calico is not whether the components work, it is which one you are actually adopting. A `felix` binary, a CNI plugin, an operator, a set of CRDs and four possible data planes are separate decisions that the word Calico tends to collapse into one. Start by picking your data plane, because that choice constrains policy features and platform support, then read the quickstart on the documentation site rather than the README. The repository itself is a good map of the architecture: the per-component Makefile targets, the release artifacts, and the CRD charts tell you what ships together and what does not.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. projectcalico/calico on GitHub
3. Project website
4. README
5. Releases