`java8` image cannot install CurseForge modpacks: pinned `mc-image-helper` predates the baked-in CF_API_KEY

[Wroud]

Summary

AUTO_CURSEFORGE fails on the java8 image with API key is not set, while the same setup
succeeds on java17/java21 without any CF_API_KEY set. This makes CurseForge modpacks
uninstallable for Minecraft versions that require Java 8 (1.12.2 and older), which is where a lot
of the classic modpacks live (RLCraft, older FTB/ATLauncher-era packs).

I believe this is a side effect of the Java 8 helper pin rather than an intentional restriction,
so I wanted to raise it with the analysis rather than just the symptom.

Environment

• Image: itzg/minecraft-server:java8, freshly pulled
• [init] Image info: buildtime=2026-08-08T21:55:34.592Z,version=java8,revision=9b12eb6a6c02a40b0c5acc643659323f2286cfbb
• Platform: linux/arm64
• Minecraft 1.12.2, Forge
• MODPACK_PLATFORM=AUTO_CURSEFORGE, CF_SLUG=rlcraft
• No CF_API_KEY set (relying on the baked-in key)

Steps to reproduce

1. Run itzg/minecraft-server:java8 with MODPACK_PLATFORM=AUTO_CURSEFORGE and a CF_SLUG for a
   1.12.2 pack, with no CF_API_KEY.
2. Observe the install fail and the container enter a restart loop.

Actual

[mc-image-helper] ERROR : Invalid parameter provided for 'install-curseforge' command:
API key is not set. Obtain an API key from https://console.curseforge.com/ and set the
environment variable CF_API_KEY
[ERROR] Failed to auto-install CurseForge modpack

Expected

Same behaviour as java17/java21, where the identical configuration installs the pack with no
CF_API_KEY supplied.

Analysis

The java8 line pins the helper:

# .github/workflows/build.yml
# JAVA 8: NOTE: Unable to go past 8u312 because of Forge dependencies
  - variant: java8
    baseImage: eclipse-temurin:8u312-b07-jre-focal
    mcVersion: 1.12.2
    # Pin version for Java 8, also be sure to set in verify-pr.yml
    mcHelperVersion: 1.51.4-java8

while Dockerfile defaults to ARG MC_HELPER_VERSION=1.66.0.

The baked-in key landed after that pin, per mc-image-helper releases:

Version	Date	Change
1.51.3-java8, 1.51.4-java8	~Dec 2025	the only Java-8-compatible builds published
1.61.3	2026-07-15	"Bake in obfuscated CF_API_KEY" (#811)
1.61.4	2026-07-16	"Also use baked in API key for install-curseforge" (#815)

So the pinned 1.51.4-java8 predates the bake-in by ten minor versions, and since no newer
Java-8-targeted helper builds exist, the java8 image has no path to the key.

Notes

• Only the install is affected. Once a pack is on disk, java8 runs it fine — installing on
  java17 and then switching back to java8 is a working workaround, which is what we currently
  do.
• 1.51.4-java8 does still accept a plain CF_API_KEY env var, so supplying one works. That is
  not viable for us: our env is visible to the end user, so we can't ship an org key that way.
• CF_API_KEY_FILE (1.65.0) is likewise unavailable on the pinned helper.

Possible directions

Listing these for discussion, not as a request for any specific one:

1. Publish a Java-8-targeted mc-image-helper build that includes the baked key, and bump the pin.
2. Have the java8 image perform the CurseForge install with a newer helper under a Java 17
   runtime present only at build/install time, then run the server on Java 8.
3. Document the limitation in the CurseForge modpack docs so it is discoverable before someone
   hits the restart loop.

Happy to test any of these against the affected setup.

[AadityaAnand]

Hi, I would like to contribute. Could you assign this task to me?

[itzg]

Thanks @Wroud for reporting this and yes that is an unfortunate and somewhat intentional side effect and maintenance burden of the java8 split. I waited many years to make that switch. I switched to Java 17 so I could take advantage of modern language/JDK features and libraries -- porting those back defeats the purpose.

@AadityaAnand that would be great for you to help. I'd like to go with the documentation change, option 3, for now.

Separately I'll ponder merging that feature over but really wanted to park java8 in maintenance mode.

Regardless, I realize now I should capture the stance on java8 in the documentation to help avoid surprises and extra investigation.