skip to content

What does the `--no-daemon` flag do, and when would you actually use it?

level: middleimportance: should knowfreq 60%

answer

  1. single-use foreground JVM
  2. exits when build ends
  3. no reuse, no spawn
  4. CI ephemeral containers
  5. org.gradle.daemon=false default
  6. does NOT stop running daemons

basics

~10 s

--no-daemon runs the build in a single-use foreground JVM that exits when the build finishes, instead of reusing or spawning a persistent daemon. It's slower but fully isolated.

solid answer

~40 s

`--no-daemon` tells Gradle to run **this** invocation in a throwaway JVM that terminates as soon as the build completes — no warm process is kept around and no existing daemon is reused. You give up the daemon's performance benefits (warm JIT, cached project model) for a clean, isolated run. Typical uses: CI agents that spin up a fresh container per job (where a persistent daemon buys nothing and may leak memory across jobs), reproducing a bug without daemon-state contamination, or constrained environments. You can make it the default per-project with `org.gradle.daemon=false` in `gradle.properties`, or per-machine via `GRADLE_USER_HOME/gradle.properties`. Note `--no-daemon` does not stop already-running daemons — for that you use `--stop`.

code

bash · 5 lines
bash
# one-off isolated run, no warm process kept
gradle build --no-daemon

# make it the default (CI) via gradle.properties:
# org.gradle.daemon=false

go deeper

for a junior

Know it runs the build without a persistent daemon and is slower.

for a middle

Explain the isolation-vs-performance trade-off and the CI use case.

for a senior

Discuss when ephemeral CI makes the daemon pointless and the org.gradle.daemon=false default, and that it doesn't stop running daemons.

for a principal

Advise org-wide on CI image strategy: ephemeral containers + no-daemon vs. warm shared agents, and the memory-leak failure mode.

## The default vs. `--no-daemon` By default Gradle uses a **daemon**: a persistent background JVM reused across builds so startup, JIT warm-up and the configured model are amortised. `--no-daemon` opts out for a single invocation: ``` gradle build --no-daemon ``` The build runs in the **client JVM itself** (a single-use process) which exits the moment the build ends. No daemon is spawned, and no existing daemon is reused. ## What you trade - **You lose:** warm JIT, in-memory caches, the pre-loaded build/project model — so the build is noticeably slower, especially short ones. - **You gain:** complete process isolation — no state from a previous build can leak in, and nothing lingers afterward consuming RAM. ## When to use it 1. **Ephemeral CI** — each job runs in a fresh container that's discarded; a persistent daemon survives nothing and a misconfigured one can accumulate heap across builds, causing flaky OOMs. Many teams set `org.gradle.daemon=false` for CI. 2. **Reproducing a heisenbug** — to rule out daemon-retained state (stale classes, leaked system properties) as the cause. 3. **Constrained/locked-down hosts** where leaving a background JVM is undesirable. ## Making it a default Rather than typing the flag every time, set it in properties: ``` # gradle.properties (project or GRADLE_USER_HOME) org.gradle.daemon=false ``` The CLI flag overrides the property for that run. ## What it does NOT do `--no-daemon` only affects the current invocation's execution mode. It does **not** stop daemons that are already running — those keep living until idle-timeout or an explicit `gradle --stop`. People often conflate the two; they're separate concerns (how *this* build runs vs. shutting down *existing* daemons).

  • Does `--no-daemon` stop daemons that are already running?
    No. It only changes how the current build executes. To shut down existing daemons you must run `gradle --stop`.
  • How do you make non-daemon execution the default without typing the flag?
    Set `org.gradle.daemon=false` in the project's `gradle.properties` or in `GRADLE_USER_HOME/gradle.properties`.

It's like taking a taxi for one trip (--no-daemon) versus keeping a car idling in the driveway for the whole day (the daemon): the taxi is slower to flag down each time but you never pay to keep an engine running.

saying these in an interview costs you the question

  • Saying `--no-daemon` kills existing daemons — it doesn't.
  • Recommending `--no-daemon` for local dev to 'speed things up' — it's slower; the daemon is the fast path.

context

resolving links…