deno ci

deno ci performs a reproducible install for CI environments, mirroring npm ci. Use it in CI scripts and Dockerfiles when you want a single, greppable command that's guaranteed to install exactly what the lockfile records — no drift, no leftover state, no surprises.

deno ci

What it does

deno ci is roughly equivalent to:

rm -rf node_modules
deno install --frozen

but with stricter error handling and clearer failure modes:

1. Requires a lockfile. If deno.lock is missing or unreadable, deno ci errors out instead of generating one. This guarantees that two runs of the same commit install the same versions.
2. Wipes node_modules first. Any stale state from a previous CI step (or a leaked development install) is removed before installing, so the final tree reflects only what the lockfile resolved to.
3. Locks resolution with --frozen. If deno.json or package.json has been edited without re-running deno install to refresh the lockfile, the command fails. This catches "I bumped a version but forgot to commit the lockfile" mistakes before they reach production.

If any of those checks fail, the install does not proceed.

When to use it

The rule of thumb: pick deno ci whenever the install must be reproducible and there is no expectation that the lockfile should change. Pick deno install whenever you're iterating on dependencies.

Examples

GitHub Actions

name: Test

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: denoland/setup-deno@v2
        with:
          deno-version: v2.x
      - run: deno ci
      - run: deno test
      - run: deno lint
      - run: deno fmt --check

Production Dockerfile

FROM denoland/deno:2.8.0
WORKDIR /app

# Copy the manifest files first so install caches well
COPY deno.json deno.lock package.json* ./
RUN deno ci --prod

# Then copy the rest of the source
COPY . .
CMD ["deno", "run", "-A", "main.ts"]

Splitting the COPY into "manifests first, source after" lets Docker reuse the deno ci layer whenever your dependencies are unchanged.

Production install on the host

deno ci --prod --skip-types

--prod skips devDependencies from package.json. --skip-types drops @types/* packages from both deno.json imports and package.json dependencies — useful in deployment artifacts where types add weight and aren't needed at runtime.

Common failure modes

See also

• deno install — everyday install, with full flag reference
• Continuous integration — guide to running Deno in GitHub Actions and other CI providers
• deno audit — scan dependencies for known vulnerabilities, complements deno ci in CI
• deno approve-scripts — manage which npm lifecycle scripts are allowed to run

deno ci [OPTIONS]

deno ci

deno ci --prod