Oracle Java in Docker Containers:
the licensing rules.

Containers changed how Java is deployed, but they did not change how Oracle licenses it. There is no "it's in a container" exemption. The licensing question is exactly the same one as everywhere else — which JDK is this, and which agreement governs it — except containers make that question harder to answer and easier to get wrong at scale.

This guide explains how Oracle Java licensing applies to Docker containers: where the obligation comes from, how the current employee metric and the legacy processor metric each treat containerised Java, and the practices that keep a container platform compliant.

Why containers matter for Java licensing

A container image is built in layers, and a JDK is almost always one of those layers. The risk is propagation: a single base image is reused to build dozens or hundreds of application images, which in turn run as thousands of container instances. If that base image contains Oracle JDK, every image and instance derived from it inherits an Oracle licensing obligation.

This is what makes containers different in practice, even though the rules are the same. A licensing mistake on one server affects one server. A licensing mistake in one base image affects an entire platform — and because container images are built automatically in CI/CD pipelines, the mistake spreads silently, without anyone making a deliberate decision to deploy Oracle Java.

There is a second amplifying factor: containers separate the person who chooses the JDK from the person who deploys it. A developer selects a base image once, often early in a project, often by copying a Dockerfile from another team or an internet example. That single choice is then executed thousands of times by an orchestrator that has no concept of licensing. By the time the workload is in production at scale, the original decision is buried several layers deep and nobody remembers making it. Compliance in a container estate is therefore less about policing running workloads and more about governing the small number of base-image decisions that everything else inherits. Get those right and the platform is compliant by construction; get them wrong and no amount of runtime monitoring will save you.

Base images: Oracle JDK vs OpenJDK

The whole compliance question reduces to the JDK inside your base image. There are two categories.

Oracle JDK base images

Oracle publishes official container images containing Oracle JDK. These carry Oracle's licensing terms. Under the OTN agreement, using an Oracle JDK image for anything beyond development and testing requires a paid subscription. Under the NFTC, an Oracle JDK image of an in-window version may be used in production for free — until that version's free window closes.

OpenJDK base images

Images built on free OpenJDK distributions — Eclipse Temurin, Amazon Corretto, Azul Zulu, Microsoft Build of OpenJDK, the Red Hat build — carry no Oracle licensing obligation. Eclipse Temurin in particular is widely used as a clean, free, production-grade base image. For most enterprises, standardising container builds on one of these distributions removes Oracle Java exposure from the container platform entirely.

How the employee metric treats containers

Under the current Java SE Universal Subscription, licensing is priced per Employee — your whole workforce — not per container, per host, or per CPU. This has a specific and important consequence for containerised Java.

If your organisation runs any Oracle JDK that requires a subscription, you license your entire employee count regardless of how many containers are involved. Whether Oracle JDK runs in 5 containers or 50,000, the employee-metric bill is the same. Containers neither inflate nor reduce an employee-metric subscription.

The practical takeaway is counter-intuitive but powerful: partial migration of a container platform saves nothing under the employee metric. Removing Oracle JDK from 90% of your images while leaving it in 10% still leaves you owing the full employee-metric subscription. Only complete elimination of Oracle JDK — across containers and everywhere else — removes the obligation. That makes "all or nothing" the right strategy for container migration. See development vs production licensing for how this interacts with non-production images.

The legacy processor metric and containers

Enterprises still on a legacy Java SE Subscription — priced by Processor and Named User Plus — face a different and more intricate situation. Under the processor metric, licensing follows the compute the JDK runs on, and Oracle's rules on virtualisation and partitioning become directly relevant.

The central issue is whether a container is treated as bounded to specific cores or as having potential access to all cores on its host — and, in an orchestrated cluster, potentially across multiple hosts. Oracle has historically taken expansive positions on "soft partitioning," arguing that licensing must cover all processors a workload could run on, not just those it currently uses. In a container cluster that can be a very large number.

If you hold a legacy processor-based agreement and run Oracle JDK in containers, the processor count is a genuine area of dispute and one where expert review is well worth the cost. Note that this complexity is itself one reason many enterprises with legacy agreements still find them cheaper than converting to the employee metric — protecting that position is a real renewal consideration.

Kubernetes and orchestration

Kubernetes does not introduce new Oracle Java licensing rules, but it amplifies the existing ones in two ways.

First, scale and dynamism. Pods are created and destroyed continuously, scheduled across nodes by the orchestrator. A point-in-time snapshot of "how much Oracle JDK is running" is almost meaningless; you need to know what is in the images, because that is the durable fact. Compliance in Kubernetes is an image-registry question, not a running-pod question.

Second, inventory difficulty. Traditional discovery tools that scan hosts may miss or misattribute Java inside short-lived pods. Effective container Java discovery works from the image registry and the deployment manifests — cataloguing every image, its JDK vendor and version, and where it is deployed. See Java containerization compliance for a deeper treatment.

Containers in the cloud

Most containerised Java now runs on cloud platforms — AWS, Azure, and GCP — across managed Kubernetes services and serverless container runtimes. The cloud does not change Oracle's licensing of Java itself: the JDK inside the image is still what matters, and the employee metric still applies to your workforce.

What the cloud changes is the surrounding context. Cloud providers offer their own free OpenJDK builds — Amazon Corretto on AWS, Microsoft Build of OpenJDK on Azure — which integrate cleanly as container base images and carry no Oracle obligation. Choosing the provider's own OpenJDK distribution for cloud container builds is both convenient and a clean compliance position. For platform-specific detail see Oracle Java in Docker on AWS and hybrid cloud licensing.

Discovering Java in container images

You cannot license, remove, or defend Java you cannot see — and containers are unusually good at hiding it. Traditional discovery tools scan running hosts; in a container platform the durable truth lives in the image registry, not on any host. Effective container Java discovery therefore works from the registry outward.

A complete container discovery answers, for every image in your registries:

• Which JDK does the image contain? Inspect the image layers and confirm the vendor — Oracle JDK, or a free OpenJDK build. Do not rely on the repository name or tag; inspect what is actually installed.
• Which version and update level? Capture the exact version, because for any Oracle JDK that determines whether BCL, OTN, or NFTC applies.
• Where did the JDK come from? Trace the base image. A Java layer almost always arrives from a parent image, and the parent is where the licensing decision was really made.
• Where is the image deployed? Cross-reference deployment manifests so you know which images are actually in production versus dormant in the registry.

Two failure modes are common. The first is scanning only running pods: pods are ephemeral, so a point-in-time scan misses images that are between deployments and over-weights whatever happens to be running. The second is trusting tags — an image tagged openjdk is not guaranteed to contain a free OpenJDK build, and an image tagged for an application may silently carry an Oracle JDK base. Inspect layers, not labels. The output of discovery should be a single catalogue: every image, its JDK vendor and version, its base image lineage, and its deployment footprint. That catalogue is the foundation for everything that follows.

Migrating container images

When discovery finds Oracle JDK in container images, the remediation is usually straightforward — and, because of the employee metric, it should be thorough rather than partial.

The mechanics are simple. Migrating a container image off Oracle JDK normally means changing one line: the FROM statement that selects the base image. Swap an Oracle JDK base image for a free OpenJDK equivalent — Eclipse Temurin, Amazon Corretto, Azul Zulu, or your cloud provider's build — rebuild, and the new image carries no Oracle obligation. Because all of these are compiled from the same OpenJDK source, the application inside the container behaves identically. There is rarely any code change involved.

The discipline is where the work lies. A sound container migration proceeds in stages: standardise on a single approved OpenJDK base image; update every Dockerfile or build definition to use it; rebuild and test each application image through your normal pipeline; and roll out the rebuilt images on your usual deployment cadence. Because the registry catalogue from discovery lists every image, the migration becomes a finite, trackable checklist rather than an open-ended hunt.

The one strategic point to hold onto: under the employee metric, migrating most of your images achieves nothing financially. If a single Oracle JDK image remains in production use, the full employee-metric subscription is still owed. Container migration must therefore be planned as complete elimination of Oracle JDK — every image, including the forgotten and rarely rebuilt ones — or it does not move the bill at all. Treat the registry catalogue as a list to drive to zero. For the wider migration picture beyond containers, see the Oracle-to-OpenJDK migration guide.

Best practice for compliant containers

Keeping a container platform compliant comes down to a small set of disciplines:

• Standardise on a free OpenJDK base image. Pick one distribution — Temurin, Corretto, Zulu, or your cloud provider's build — and make it the only approved Java base image.
• Verify the vendor, not the tag. Never assume an image tagged "openjdk" or "jdk" is free. Confirm what is actually inside it.
• Add a pipeline gate. Configure CI/CD to block any build using an Oracle JDK base image unless it is explicitly approved and licensed.
• Catalogue the registry. Maintain an inventory of every image, its JDK vendor and version, and its deployment footprint.
• Re-scan on rebuild. Images change. Treat each rebuild as a moment to re-verify the JDK layer.
• Go all-in on migration. Because the employee metric is binary, plan container migration as complete elimination of Oracle JDK, not a partial reduction.

Conclusion

Docker containers do not get a Java licensing discount and they do not carry a penalty — they simply make the standard question, "which JDK is this and which agreement governs it," operate at platform scale. One Oracle JDK base image can quietly create an enterprise-wide obligation; one disciplined switch to a free OpenJDK base image can remove it just as broadly.

For enterprises auditing a container estate, the work is to catalogue every image, verify every JDK layer, and decide — cleanly and completely — whether Oracle JDK belongs anywhere in the platform. We run that assessment as a fixed-scope engagement, and where an independent specialist opinion is wanted, Redress Compliance is the Oracle Java licensing advisory firm we recommend most. Get the base images right and container Java compliance largely takes care of itself.