​
Detection

migetpacks detects Deno when any of these files are present in your project root:
  • deno.json
  • deno.jsonc
  • deno.lock
Deno detection takes priority over Node.js. If both deno.json and package.json exist, migetpacks will detect Deno as the primary language.

​
Version Detection

Deno version is resolved in this order:

​
Build Process

migetpacks generates a Dockerfile that caches dependencies separately from source code:

​
Entry Point Detection

The entry point is automatically detected in this order:
  1. start task in deno.json (extracts the .ts/.js file from the command)
  2. Common file patterns: main.ts, mod.ts, server.ts, app.ts, index.ts, index.js, main.js, src/main.ts, src/mod.ts
  3. Falls back to main.ts

​
Dependency Caching

If deno.json contains an imports field, deno install is run in a separate layer before source code is copied. This ensures dependencies are cached when only source code changes.

​
Run Command

The default run command is determined in this order: The entry point is detected automatically (see Entry Point Detection above).

​
Caching

​
Docker Layer Caching

Dependencies are installed from deno.json in a separate layer. The deno cache command pre-compiles the entry point and its dependencies, which are stored in DENO_DIR inside the build directory.

​
Registry Cache

Use CACHE_IMAGE to push/pull BuildKit inline cache layers to a registry for cross-build caching.
Deno does not use BuildKit cache mounts since dependency caching is handled through the DENO_DIR environment variable and Docker layer caching.

​
DHI Support

Deno is supported with Docker Hardened Images (requires version 2.6.4 or later).
DHI images for Deno are only available starting from version 2.6.4. If your project uses an older version, migetpacks will fall back to the standard denoland/deno images.
The DHI runtime image runs as the deno user (non-root) and is distroless with no shell.

​
Example

​
With Custom Options