VMware Tanzu Licensing Guide

VMware Tanzu is the name attached to VMware's Kubernetes-related product family, and the licensing model around it has been one of the more confusing aspects of the post-acquisition catalogue. Broadcom reorganised the Tanzu product family into a separately-managed business unit, kept some Tanzu functionality bundled inside VCF, and discontinued or repositioned several mid-tier Tanzu SKUs that customers previously held. The net result is a commercial map that is materially different from the pre-acquisition Tanzu catalogue.

This guide explains where Tanzu sits today, what is included in which bundle, what is sold separately, and how to avoid the two costly mistakes we routinely see: buying Tanzu Platform for runtime needs already covered by VCF, and assuming VCF covers application-platform features that are in fact sold separately.

How Broadcom structured Tanzu post-acquisition

The Tanzu product family at acquisition contained more than a dozen SKUs spanning runtime, application platform, observability, build services, and data services. Broadcom collapsed this catalogue into two principal commercial vehicles: a runtime entitlement bundled inside VCF, and a standalone Tanzu Platform commercial structure managed by the Tanzu business unit.

The bundled runtime — commonly referenced as Tanzu Standard inside VCF — provides the Kubernetes execution layer on the licensed cores. The standalone Tanzu Platform is the developer-experience and platform-engineering offering, sold per-developer or per-application with its own commercial structure independent of VCF. Several pre-acquisition Tanzu SKUs were retired or rolled into one of these two structures.

For customers, the practical consequence is that the question "do we have Tanzu" no longer has a single answer. A VCF customer has Kubernetes runtime by virtue of the VCF entitlement; whether they have the Tanzu Platform application-platform layer is a separate question with a separate commercial.

What is included in VCF as Tanzu Standard

VCF Advanced and VCF Enterprise both include a Tanzu Standard entitlement. The scope of what this covers is meaningful but bounded.

Kubernetes runtime on licensed cores

The principal value is the Kubernetes runtime — Tanzu Kubernetes Grid (TKG) clusters — deployed on the cores already licensed under VCF. This means customers running mixed VM and container workloads on the same VCF estate do not pay separately for Kubernetes runtime. The runtime supports the standard Kubernetes API surface, control-plane lifecycle, and worker-node provisioning.

Tanzu Mission Control entitlement (partial)

VCF Advanced and Enterprise include a Tanzu Mission Control entitlement for management of clusters provisioned through TKG. The scope of this entitlement has been adjusted across catalogue revisions; the current scope as of mid-2026 covers cluster lifecycle, policy distribution, and basic observability for TKG-provisioned clusters. The full Tanzu Mission Control offering — including third-party Kubernetes management and broader policy and inventory features — is positioned within the standalone Tanzu Platform commercial.

Tanzu Data Services (limited)

VCF customers receive entitlement to specific Tanzu Data Services components — principally those required for stateful workloads running on TKG. The scope is narrower than the pre-acquisition Tanzu Data Services catalogue; customers requiring the full breadth of managed data services should not assume VCF coverage and should validate against the current catalogue.

What is not included — the Tanzu Platform line

The Tanzu Platform is the standalone offering covering application-platform functionality. This is the area that pre-acquisition customers most often confuse with the bundled VCF Tanzu entitlement.

Tanzu Platform includes the developer-experience layer (templates, application accelerators, developer portals), the platform-engineering features (golden paths, supply-chain choreography, deployment governance), and the higher-tier observability and application-performance management. It is sold by the Tanzu business unit on a per-developer or per-application commercial structure that is independent of VCF.

The Tanzu Platform commercial is not a small expansion of the VCF deal — it is a separate procurement, separate contracting motion, and separate budget line. Customers building a full internal developer platform around Tanzu Platform should budget for this independently of their VCF subscription.

How the Tanzu Platform commercial works

The Tanzu Platform commercial is structured around developer or application metrics, not cores. The principal pricing axes are number of developers, number of applications managed, and feature tier.

Tier selection follows the application-platform feature stack: a base tier covering supply-chain choreography and basic developer portals, a mid tier adding templating and golden-path features, and an enterprise tier with the full platform-engineering and observability stack. Pricing escalates substantially across tiers; customers typically negotiate tier selection at the same level of intensity as VCF edition selection.

Term length follows the standard Broadcom three-year default, with multi-year commitments available for additional discount. The minimum-commitment provisions are looser than VCF — there is no per-core floor — but minimum developer counts and minimum-application thresholds apply at certain tiers.

Tanzu SKU changes customers should know about

Several pre-acquisition Tanzu SKUs have been retired, repositioned, or repackaged. Customers holding any of these in active inventory need to plan for the change at renewal.

Tanzu Application Service (formerly Pivotal Cloud Foundry)

The Application Service line is positioned as a separate runtime offering within Tanzu Platform. Customers running TAS in production should expect a contract restructure at renewal, with revised pricing and a likely migration path encouraged toward the broader Tanzu Platform stack.

Tanzu Build Service

The standalone Build Service SKU has been folded into the Tanzu Platform supply-chain capability. Customers with a Build Service contract should treat the next renewal as a Platform migration discussion.

Tanzu Observability (Wavefront)

The observability product has been repositioned within the Tanzu Platform observability tier. Pricing has changed, and customers with substantial Wavefront deployment should validate the new commercial against their actual data-ingestion volume.

Tanzu Service Mesh

Service Mesh has been repositioned within Tanzu Platform with a revised commercial. Customers running Service Mesh as a standalone capability should evaluate whether the Platform commercial reflects their actual deployment scope.

How to size Tanzu commitments correctly

The right Tanzu commitment depends on how the customer is actually using Kubernetes. We categorise this into three patterns.

Runtime-only customers

Customers using Kubernetes as a workload runtime — running containers in TKG clusters with the standard Kubernetes API, deploying via their own CI/CD, observing via their own observability stack — need only the Tanzu Standard entitlement bundled in VCF. No additional Tanzu spend is required.

This is the most common pattern in our client base. Customers in this category should resist Tanzu Platform sales motion that suggests they "need" the Platform to "complete" their Kubernetes deployment. The runtime works without the Platform; the Platform addresses a different problem.

Platform-engineering customers

Customers building an internal developer platform — with golden paths, application templates, self-service portals, and centralised supply-chain governance — have a credible case for Tanzu Platform. Sizing should be based on the actual developer population that will use the platform and the number of applications under management.

Tier selection matters. The enterprise tier is meaningfully more expensive than the mid tier and is justified only by specific platform-engineering or observability features that the mid tier does not provide. Most platform-engineering customers can deliver value at the mid tier.

Modernisation-programme customers

Customers running a defined application modernisation programme — with a specified set of legacy applications being refactored onto containers — sit between the two. The TKG runtime in VCF covers the execution layer, and the modernisation tooling needs are typically covered by selective Tanzu Platform features rather than the full platform.

The mistake we most often see in this group is committing to an enterprise-tier Tanzu Platform deal sized for a much larger application population than the modernisation programme will actually move. Right-sizing — with explicit scope tied to the programme's application list — produces materially better commercials.

Audit considerations for Tanzu deployments

Tanzu deployments produce their own audit-risk profile, separate from the underlying VCF estate. Three patterns dominate audit findings.

First, customers running TKG clusters on cores outside the VCF entitlement — on dedicated hypervisor hosts not included in the VCF licence count — create exposure. The TKG runtime is bundled with VCF specifically; running it elsewhere without separate licensing produces an audit finding.

Second, customers using Tanzu Mission Control to manage non-TKG Kubernetes clusters — clusters running on EKS, GKE, AKS, or self-managed Kubernetes — may exceed the bundled Mission Control entitlement scope. The full multi-cluster management capability sits in Tanzu Platform; customers extending Mission Control beyond TKG should validate their entitlement scope.

Third, customers using Tanzu Platform application-platform features under the assumption that VCF coverage extends to them produce findings when the audit team reconciles deployment to entitlement. This is the single most common Tanzu audit finding in our experience.

Negotiating Tanzu at renewal

Tanzu commercials at renewal require the same negotiating discipline as the broader VCF commercial. Three points matter most.

First, tier selection should follow actual deployed feature usage, not aspirational future state. The Tanzu sales motion will press toward higher tiers based on roadmap discussions; the commercial discipline is to commit at the tier matching demonstrated usage and to defer tier upgrades until the usage materialises.

Second, developer counts should reflect the platform-using developer population, not the total developer headcount. Many platform-engineering deployments serve only a subset of developers; sizing to total headcount produces meaningful over-buy.

Third, price protection on renewals matters. Tanzu Platform pricing has moved materially across the last several catalogue revisions; explicit price-protection language for renewal cycles is worth negotiating into the initial commercial.

How VCF customers should think about Tanzu in 2026

The current state of the catalogue produces a clear decision framework for VCF customers thinking about Tanzu.

If the customer's Kubernetes use is runtime-only, the bundled Tanzu Standard in VCF is sufficient. No additional Tanzu spend is required. The sales motion may push toward Platform, but the runtime-only customer should resist this and validate that the bundled entitlement meets their actual deployment.

If the customer is building an internal developer platform, Tanzu Platform is a credible component — but it is one of several options in a competitive landscape that includes Backstage-based platforms, GitLab's platform offering, and several other commercial platform-engineering tools. The Tanzu Platform commercial should be evaluated against this alternative landscape rather than treated as the default extension of VCF.

If the customer is running a modernisation programme, the Tanzu Platform engagement should be scoped to the programme and not committed at a larger scale than the programme will consume. Programme-end exit options should be negotiated explicitly.

How the Tanzu commercial decision should be sequenced

The Tanzu commercial decision is sequencing-sensitive in ways that the standard procurement motion does not surface. The right sequence runs as follows.

First, validate what is in the bundled VCF entitlement at the current edition. Tanzu Standard inside VCF Advanced covers the Kubernetes runtime; Mission Control coverage is bounded; Data Services coverage is bounded. Document the bundled coverage explicitly before any conversation about Tanzu Platform.

Second, map the actual Tanzu use against the bundled coverage. Identify which Tanzu features the deployment uses, which it might use within the contract term, and which sit clearly outside the contract-term scope. The mapping exposes whether the bundled entitlement is sufficient or whether Tanzu Platform is genuinely required.

Third, if Tanzu Platform is genuinely required, build the platform commercial as a separately-sized analysis. The developer-population sizing, the application-population sizing, and the tier selection are the principal inputs; the per-tier pricing escalation makes tier discipline particularly important.

Fourth, negotiate the Tanzu Platform commercial separately from the VCF renewal where possible. The two commercials operate on different cadences and different commercial structures; bundling them into one negotiation can obscure the per-component economics. Where the deal economics favour combined negotiation, ensure each component's pricing is visible within the combined deal.

Tanzu and the Kubernetes-platform competitive landscape

The Tanzu Platform sits in a competitive landscape of Kubernetes platform-engineering offerings that has matured substantially since 2023. The principal alternatives include the Backstage-based open-source platforms (often delivered through Spotify Portal or commercial Backstage distributions), GitLab's developer-experience platform, Humanitec, Cortex, and several others.

The Tanzu Platform's strengths sit in its integration with the broader VMware estate, its enterprise-support model, and its supply-chain choreography capabilities. The competitive alternatives' strengths typically sit in developer-experience modernity, in open-source ecosystem integration, and in pricing structures that may be more accommodating at certain scales.

Customers evaluating Tanzu Platform should evaluate it within this competitive landscape rather than treating it as the default Kubernetes platform-engineering option for VCF customers. The right answer for the deployment may not be the default vendor extension; the alternatives should be evaluated on the same terms.

Practical implementation checklist

For customers building or right-sizing their Tanzu position, the implementation checklist runs as follows. Validate VCF edition coverage of Tanzu Standard and Mission Control entitlement. Document the deployed Kubernetes scope including TKG clusters, non-TKG Kubernetes, and Mission Control management scope. Identify the Tanzu Platform feature requirements (if any) and map to the appropriate tier. Build the platform sizing on developer and application counts. Negotiate Tanzu Platform on the standard Broadcom commercial cadence with attention to tier selection and term length. Build runtime-only deployment patterns to maximise the bundled VCF entitlement before considering Platform commercial. Maintain ongoing reconciliation of deployed scope against entitled scope to support audit defence.

Related reading

For deeper context on adjacent topics, see the VCF licensing explainer, the VMware licensing complete guide, and our VMware audit defence guide. For broader context on the post-acquisition catalogue, see the licensing complete guide.