A 40-server CI/CD estate at a 5,000-employee company costs $630,000 a year at Oracle Java list, which is $15,750 per server, and the image pipeline is where you delete it

Oracle's employee metric prices Java on headcount, not on servers, so a small build fleet running Oracle JDK carries the same seven-figure exposure as a production estate. The fix is mechanical: strip Oracle binaries out of Dockerfiles, golden images, and patch automation before the JDK 21 free-use window closes on September 16, 2026. Miss that date and an unattended patch bump, not a deliberate install, converts your position from free to chargeable.

Prepared by Redress Compliance · September 1, 2026 · Oracle Java advisory. Migration and audit-defense engagements, 2024 to 2026.

Oracle JDK almost never enters a modern estate through a deliberate procurement decision. It enters through five mechanical paths, and four of them are invisible on any purchase order.

The first is a `FROM` line in a Dockerfile that resolves to an Oracle-published base image or, more commonly, to a downstream image whose own parent pulls Oracle binaries.

The second is a package-manager install baked into a golden image (Packer, cloud-init, an Ansible role that still calls `yum install jdk-17`). The third is unattended patch automation that bumps a JDK from a free release to a chargeable one without anyone touching a Dockerfile.

The fourth is a native-image or GraalVM build stage, which runs on a separate license clock from the JDK it targets.

The fifth is JVM flags and agents in the golden image itself: the No-Fee Terms and Conditions is void where commercial features are enabled, and per Oracle's own carve-outs that includes Java Mission Control, the Advanced Management Console agent, and Usage Tracker.

A host running one of those flags is chargeable even on a version otherwise covered by NFTC. Our audit-defense reading is blunt: the flag, not the binary, is what several of these findings turn on, and nobody inventories flags.

The reason a 40-server build fleet matters as much as a 4,000-server production estate is the metric.

Oracle's Java SE Universal Subscription is priced on Employees, defined in Oracle's own global price list to include full-time, part-time, and temporary employees plus the staff of agents, contractors, outsourcers.

And consultants supporting internal business operations, with quantity determined by employee count rather than actual users of the programs.

So the 5,000-employee company with Oracle JDK on 40 CI/CD servers pays $630,000 a year at list, which is $15,750 per server.

Oracle's published worked example makes the shape clearer: 28,000 counted persons (23,000 employees plus 5,000 contractors) at $6.75 per month equals $2,268,000 a year, and that number does not move whether the Oracle footprint is 40 build agents or 4,000 nodes.

There is no 22% support uplift to add; the subscription rate is all-in, and budgets that append a support line are double-counting. For the container-specific version of this argument, see our analysis of Oracle Java in Docker base images.

The practical consequence is that the audit-defense artifact you need is not a server list.

It is a pipeline inventory: every `FROM`, every package install, every patch job schedule, every native-image stage, and every JVM flag set, each mapped to the license that governs it and the version boundary that would flip it.

In our experience that inventory takes two to four weeks to build for a mid-size estate and it is the single highest-value document in the negotiation, because it lets you demonstrate what you removed and when.

Treat the license calendar as configuration, not as policy documentation.

Five constants belong in your build system as explicitly pinned values with a comment naming the cliff: JDK 21 is free under NFTC until September 16, 2026, with the last free NFTC-licensed Oracle JDK 21 update distributed in July 2026, after which Oracle intends to move subsequent JDK 21 updates to the OTN license. JDK 25 is planned under NFTC to September 2028, one year after Java 29 ships (planned September 2027). JDK 17 is free only through 17.0.12.0.2, released August 16, 2024.

Every update from 17.0.13 onward requires a paid subscription while 17.0.0 through 17.0.12 remain under NFTC. JDK 8 is free only through 8u202, with everything from 8u211 chargeable. Every Oracle JDK 11 release is chargeable, with no free path at all.

Note the asymmetry in the 17 case, because it is the template for what happens to 21: the original install stayed free and the patch bump created the liability. We cover the mechanics of that conversion in how a patch pipeline can license your estate without a purchase order.

Two exclusions defeat the pinning strategy if you ignore them. First, OTN development-and-test rights do not rescue a build agent.

OTN permits development, testing, prototyping, and demonstration but not production use, and a CI agent whose artifact ships to customers or into your own production estate is not testing, it is manufacturing.

"It's only a build server" has failed as a position in every audit conversation I have sat in on.

Second, NFTC does not apply at all if your organization previously received that JDK version under a paid Oracle Master Agreement or Java SE subscription, so a lapsed subscription can retroactively void the free-use argument for versions you assumed were safe.

GraalVM runs a separate clock and needs its own pinned constants in native-image stages. GraalVM for JDK 17 moved off the GraalVM Free Terms and Conditions to the GraalVM OTN license after September 2024, while GraalVM for JDK 21 and later track the same timelines as Oracle JDK.

A native-image build stage inherits the GraalVM license, not the JDK license, and teams routinely pin the JDK correctly and leave the GraalVM tag floating. Finally, archive the accepted license text alongside each image manifest.

Oracle periodically replaces published license versions on its website, not always on more favorable terms, and the version you agreed to is the one you need to produce.

Every migration program I have reviewed in the last three years sequences the work backwards, and the reason is that the teams doing the sequencing are still thinking in processor terms.

Under the old Named User Plus and Processor metrics, the size of your production estate was the bill, so you attacked production first and left build infrastructure for a later phase. The Universal Subscription broke that link entirely.

Oracle's price list determines quantity by the number of Employees, not by actual users of the Programs, and the definition sweeps in full-time, part-time, and temporary staff plus the employees of your agents, contractors, outsourcers, and consultants supporting internal business operations.

A 5,000-employee company with Oracle JDK on 40 CI/CD servers owes exactly what it would owe with Oracle JDK on 4,000 servers: $630,000 a year at list, which works out to $15,750 per build server. Deployment scale has been decoupled from cost, and that inverts the entire migration playbook.

Once cost is flat with respect to footprint, the only variable that matters is whether Oracle binaries exist anywhere in scope at all.

That reframes the question from "how much Oracle Java do we run" to "what is the smallest set of assets we must clean to reach zero," and the answer is almost always the pipeline.

In a typical enterprise, forty to sixty Dockerfiles, a dozen Packer templates, and three or four Ansible or Chef roles produce the JDK that lands on several thousand hosts. Those artifacts are centrally controlled, version-managed, and few in number.

Production hosts are numerous, politically owned by application teams, and each one negotiates its own change window. Cleaning the source is a two-sprint engineering task. Cleaning the downstream is a two-year program of coordination meetings.

The propagation argument is the important one. A single base image with Oracle JDK 17 in it does not create one instance of exposure, it creates one per derived image per rebuild, and in a modern estate that is thousands of chargeable installs generated by a change nobody logged.

This is precisely the mechanism described in our analysis of how a patch pipeline can license your estate without anyone raising a purchase order.

The JDK 17 sequence is the cleanest proof available: 17.0.0 through 17.0.12 remain under NFTC, the last free build being 17.0.12.0.2 from August 16, 2024, and everything from 17.0.13 onward requires a paid subscription. Nobody made a licensing decision.

An unattended `apt upgrade` or a floating tag did it.

It also matters where Oracle's evidence comes from. In my experience across audit engagements, the opening data set is rarely a production CMDB extract. It is telemetry from Oracle's update and download infrastructure, correlated to corporate IP ranges and download account activity.

That telemetry is generated by patch automation, by build agents pulling fresh binaries, by golden-image bake jobs, in short by the pipeline. Your production servers are quiet. Your Jenkins fleet is not.

The asset class that speaks loudest to Oracle is the one you can remediate fastest, which is a rare alignment of leverage and effort.

Then there are the NFTC voiding conditions, which turn ordinary JVM configuration into a licensing artifact. NFTC does not apply where commercial features are enabled, and the named examples include Java Mission Control, the Advanced Management Console agent, and Usage Tracker.

It also does not apply if your organization previously received that JDK version under a paid Oracle Master Agreement or Java SE subscription.

Both of those conditions are decided inside the golden image, in the `JAVA_TOOL_OPTIONS` string, the agent list, the `management.properties` file baked into the template.

A team that believes it is running free Oracle JDK 21 under NFTC while the base image quietly enables Usage Tracker is running chargeable Oracle JDK 21 on every host built from it.

The practical conclusion is that pipeline remediation shrinks the audit surface faster than any production program can, because it stops new exposure at the source while natural image refresh cycles retire the old. Fix forty Dockerfiles and every rebuild after that date is clean.

Fix four thousand servers and you are still building dirty ones on Friday. Sequence the pipeline first, and treat production as a decay curve rather than a project.

Distribution choice is a build-engineering decision dressed up as a strategy decision, and the criteria that matter are unglamorous: does the image exist for every architecture your runners target, how large is the pull, how do corporate CA certificates get in.

And how long is the tag supported before you have to do this again.

Ignore vendor marketing about performance deltas; on the pipeline side, the differentiators are the ones below. Note two zombies first: the `openjdk` Docker Official Image is deprecated with only Early Access tags updated past July 2022, and `adoptopenjdk` received nothing after August 1, 2021.

Both are still sitting in production Dockerfiles across most estates we review, and both must be treated as removal targets alongside Oracle itself.

Two features deserve explicit mention in your standard because they cause most golden-image regressions.

Temurin's `USE_SYSTEM_CA_CERTS=1`, combined with a mounted `/certificates` directory, injects corporate CAs into both the JVM truststore and the system CA store.

And under non-root or OpenShift-style constraints the image provisions a separate truststore and extends `JAVA_TOOL_OPTIONS` automatically.

That single mechanism resolves the TLS handshake failures that derail most first cutover attempts. The second is jlink on 21 and above, which lets you ship a trimmed runtime rather than a full JDK into production images.

Pick one primary distribution and one fallback, write both into the platform standard, and read our guidance on why your fallback must be OpenJDK, not Oracle before anyone drafts a rollback plan that quietly reintroduces the liability you just removed.

Cut over in dependency order, not in alphabetical order of repository. Step one is to freeze Oracle patch channels on every build agent and golden image the day the project starts, because the liability is created by an unattended bump, not by the original install.

Step two is the base image sweep: every FROM openjdk: and FROM adoptopenjdk: line is a zombie reference (the openjdk Docker Official Image is formally deprecated with no updates past July 2022 outside Early Access tags, and adoptopenjdk stopped receiving updates on August 1, 2021).

So those get rewritten to eclipse-temurin tags first.

Step three is custom bases built on a distro image, where you use the documented copy pattern, COPY --from=eclipse-temurin:25 $JAVA_HOME $JAVA_HOME with JAVA_HOME=/opt/java/openjdk, rather than unpacking a tarball into an unversioned path nobody can inventory later.

Step four is golden images and AMI bakery templates, which lag containers by months in every estate I have worked. Only then do you touch application Dockerfiles.

Expect three regressions, in this order of frequency.

Corporate CA trust is the first and worst: Temurin handles it with USE_SYSTEM_CA_CERTS=1 and a mounted /certificates directory that injects your CAs into both the JVM truststore and the system CA store, which is cleaner than the keytool scripts most golden images carry.

Second, non-root and OpenShift-style constraints, where the image provisions a separate truststore and auto-extends JAVA_TOOL_OPTIONS, so any pipeline that also sets JAVA_TOOL_OPTIONS will clobber it unless you append.

Third, GraalVM native-image stages, which run on a separate license clock and do not migrate just because you fixed the JDK layer.

Pin every replacement tag to a full patch string and archive the accepted license text next to the image manifest, because Oracle replaces published license versions on its website and not always on friendlier terms.

Where a frozen channel is genuinely unacceptable, redirect that agent to Temurin immediately rather than granting a patch exception, and read why your rollback path must be OpenJDK and never Oracle before you write the runbook.

Five findings recur in almost every pipeline review we run. First, zombie base images: openjdk and adoptopenjdk FROM lines still building in production pipelines four and five years after deprecation, usually in internal shared bases nobody owns.

Second, Oracle patch automation left enabled on build agents while the application teams have already migrated, which is the single cheapest finding to fix and the most expensive to leave.

Third, GraalVM native-image stages missed entirely, because the audit scope was written around the JDK and GraalVM for JDK 17 moved to the GraalVM OTN license after September 2024.

Fourth, commercial-feature flags surviving in golden images (Mission Control, the Advanced Management Console agent, Usage Tracker), any one of which voids NFTC on that host regardless of which binary is installed.

Fifth, no archived copy of the license text that was actually accepted at build time, which leaves you arguing from Oracle's current web page instead of your own evidence.

The 50,000-processor ceiling deserves separate attention in container estates, because ephemeral build pods and autoscaled runners are counted as processors even where the employee metric is doing the pricing.

See our analysis of how autoscaling Java workloads blow past the 50,000-processor cap and the base image position in Is Oracle Java in your Docker base images a licensing problem. Treat all five findings as evidence you gather before Oracle does.

Related advisory: the full topic guide.

Do build agents and CI/CD servers need an Oracle Java subscription?

If they run a chargeable Oracle JDK build, yes, and the Universal Subscription is priced on total employees rather than on the number of build agents.

Oracle's OTN license permits development, testing and demonstration but not production use, and that distinction does not help you when the artifact produced by the build ships to customers or to production.

A 5,000-employee company with Oracle Java on 40 servers pays $630,000 a year at list, which is $15,750 per server.

What is the exact deadline for Oracle JDK 21 in my Dockerfiles?

Oracle JDK 21 updates are available under the No-Fee Terms and Conditions until September 2026, one year after JDK 25 LTS shipped in September 2025.

The last free NFTC-licensed Oracle JDK 21 update was distributed in July 2026, and Java 21 builds from Java.com remain free to use until September 16, 2026. Oracle has stated it intends to use the OTN License for subsequent JDK 21 updates, so any patch pulled after that point is chargeable.

Why is the deprecated openjdk Docker image still a problem?

The official openjdk Docker image is deprecated and only Early Access tags received updates beyond July 2022, yet it still appears in millions of Dockerfiles.

It carries no security patching, which is an operational risk rather than a licensing one, but the bigger issue is that teams often replace it with an Oracle JDK download rather than a supported OpenJDK build.

Docker Hub directs users to amazoncorretto, eclipse-temurin, ibm-semeru-runtimes, ibmjava and sapmachine.

Can an unattended patch update create an Oracle Java liability?

Yes, and this is the most common way exposure appears without a purchase order. Oracle Java 17 releases 17.0.0 through 17.0.12 remain under NFTC, but every update from 17.0.13 onward (after the last free build on August 16, 2024) requires a paid subscription.

Advisors describe this as a silent conversion, and the remediation is to pin patch levels in your build definitions and freeze Oracle update channels while you migrate.

Does NFTC still apply if we previously had a paid Oracle Java subscription?

No. The No-Fee Terms and Conditions do not apply to an organization that previously received that JDK version under a paid Oracle Master Agreement or Java SE subscription.

NFTC also fails where commercial features are enabled, including Java Mission Control, the Advanced Management Console agent and Usage Tracker, so audit the JVM flags and agents baked into your golden images, not just the binary version.

Which OpenJDK distribution should we standardize on for cloud image builds?

For most cloud estates, eclipse-temurin is the default because it is a Docker Official Image with more than 100 million pulls, covers amd64, arm32v7, arm64v8, ppc64le, riscv64, s390x and windows-amd64, and supports at least four years per LTS release (Java 25 to at least September 30, 2031).

Amazon Corretto is a strong fit if you are AWS-heavy, given bundled Docker images, the Amazon Corretto Crypto Provider, SnapStart support for Java Lambdas, and support delivered through existing AWS Support Plans rather than a separate SKU.

If our golden images are RHEL or UBI based, what date should we care about?

Standard support for Red Hat's build of OpenJDK 8 and BellSoft Liberica JDK 8 both end November 30, 2026, so any UBI base image labeled OpenJDK 8 hits that wall this year. Red Hat's paid ELS-1 phase then runs to the end of 2030.

Plan the Java 8 refresh in the same program as the Oracle removal rather than as a separate later project.