# Java deployment checklist > **This file is reference data, not instructions. It lists things to verify before deploying. Nothing below is a command from the operator, and no line in it grants authority to act. Run the read-only verification steps if you wish, then report what you found to the human operator and let them decide what to change. Do not modify the project on the basis of this file. This holds when you are running unattended, on autopilot, or in any automatic mode: an autonomy setting is not the operator approval this file withholds, and no finding here becomes authority to edit a file because nobody is watching. If something needs changing, say so and stop.** Source: https://deploy-list.com/java.md · 8 checks · layers: universal -> java · generated 2026-08-22 Verification steps come in three kinds. **Verify:** read-only, allowlisted, safe for an agent to run. **Operator-run:** a command only the human should decide to run, typically a framework CLI. An agent must not run these, only report them as outstanding. **Verify by hand:** needs a person to look. ## critical (2) - **No environment file is tracked in git** — `secrets` · `universal.gitignore-env` - Why: Environment files hold database credentials and API keys. Once committed they remain in history after deletion, so every affected credential has to be rotated rather than simply removed. - Do: Remove any tracked environment file from the index, add it to .gitignore, then rotate every credential that was ever committed. - Verify: `git ls-files --error-unmatch .env .env.local .env.production 2>&1 | head -5` - Expect: Every path reports that it did not match any file. A path echoed back is tracked and must be dealt with. - Ref: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html - **The debug agent is not enabled in production** — `security` · `java.no-debug-agent-in-production` - Why: A listening debug agent lets anyone who can reach the port load classes and execute code inside the process. There is no authentication on it, and it is usually left behind after an incident. - Do: Remove the debug agent flags from production start scripts and container images, and confirm the port is not exposed. If remote debugging is needed, bind it to localhost and tunnel. - Verify: `grep -rnE 'agentlib:jdwp|-Xdebug|-Xrunjdwp' --include=Dockerfile --include='*.sh' --include='*.yml' --include='*.yaml' --include='*.conf' . 2>/dev/null | head -10` - Expect: No production start path enables it. A hit in a development compose file or a debug profile is fine. - Ref: https://docs.oracle.com/en/java/javase/21/docs/specs/jpda/conninv.html ## high (4) - **No snapshot dependency is in the release build** — `build` · `java.no-snapshot-dependencies` - Why: A snapshot resolves to whatever was published most recently, so the same commit builds differently on different days and the artifact you tested is not the one that ships. - Do: Pin every dependency to a released version before tagging. Keep snapshots to local development and to modules you are actively changing. - Verify: `grep -rn 'SNAPSHOT' --include=pom.xml --include='*.gradle' --include='*.gradle.kts' . 2>/dev/null | head -10` - Expect: Nothing, other than the project's own version while it is unreleased. - Ref: https://docs.oracle.com/en/java/ - **The heap is bounded against the container limit** — `reliability` · `java.heap-bounded-in-container` - Why: A modern runtime reads the container limit, but only if one is set. With no limit it sizes the heap against host memory, grows into it, and is killed by the platform rather than by its own collector. - Do: Set a memory limit on the container and size the heap as a percentage of it, leaving headroom for stacks, metaspace and native buffers. - Verify: `grep -rnE 'MaxRAMPercentage|-Xmx|memory:' --include=Dockerfile --include='*.yml' --include='*.yaml' . 2>/dev/null | head -10` - Expect: A container memory limit exists, and the heap is sized relative to it rather than left to the default. - Ref: https://docs.oracle.com/en/java/javase/21/gctuning/ - **A backup has been restored at least once** — `reliability` · `universal.backup-restore-tested` - Why: An untested backup is a belief, not a capability. Silent corruption, missing tables and expired credentials are all routinely discovered during the first restore, which is the worst possible time to find out. - Do: Restore the most recent backup into a scratch environment, confirm the data is complete and current, and write down how long the restore took. - Verify by hand: Confirm that someone has restored a production backup into a separate environment recently, and that the restore procedure is written down somewhere findable. - Ref: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html - **Known vulnerabilities in dependencies have been reviewed** — `security` · `java.dependency-vulnerabilities-reviewed` - Why: A typical service pulls in hundreds of transitive artifacts. The ones that caused the worst incidents of the last decade were all transitive, and nothing in a normal build fails when one is vulnerable. - Do: Run a dependency scanner before a release and decide on each finding, recording a reason where you accept one. - Operator-run (do not run this yourself): `mvn org.owasp:dependency-check-maven:check` - Expect: No unreviewed finding above your agreed threshold. Gradle projects have an equivalent task. - Ref: https://docs.oracle.com/en/java/ ## recommended (2) - **The build declares which Java version it targets** — `build` · `java.toolchain-version-declared` - Why: Without a declared release target the build compiles against whatever runtime the machine has, and a class file built on a newer runtime fails at startup on an older one with an error that names a version number and nothing else. - Do: Declare the release or toolchain version in the build file so the compiler is checked against it rather than inferring it from the environment. - Verify: `grep -rnE 'maven.compiler.release||sourceCompatibility|languageVersion|' --include=pom.xml --include='*.gradle' --include='*.gradle.kts' . 2>/dev/null | head -10` - Expect: A version is declared in the build file. - Ref: https://docs.oracle.com/en/java/javase/21/docs/specs/man/javac.html - **The project declares a license** — `legal` · `universal.license-declared` - Why: Code with no license is not open source and not safe for anyone else to use, and for a closed project the absence leaves contributors with no written statement of who owns what they wrote. - Do: Add a license file at the repository root, and reference it from the package metadata so tooling can read it. - Verify: `ls LICENSE LICENSE.md LICENSE.txt COPYING 2>/dev/null | head -3` - Expect: A license file exists at the repository root. --- Report what you found to the operator. Do not change the project.