Fix Kubernetes Pod Crash in Deno

Kubernetes CrashLoopBackOff with Deno

Deno's security model adds an extra layer of complexity when deploying to Kubernetes. Your pod might crash because Deno denies permissions that work fine on your local machine.

Permission Errors

Deno requires explicit permission flags. A missing --allow-net means your HTTP server can't bind:

# Dockerfile
FROM denoland/deno:1.40.0
WORKDIR /app
COPY . .
RUN deno cache main.ts

# Must include all required permissions
CMD ["deno", "run", "--allow-net", "--allow-env", "--allow-read", "main.ts"]

Module Resolution Failures

If your app imports from URLs and the container has no internet access (common in air-gapped clusters), cache dependencies at build time:

# Cache all deps during build
RUN deno cache --lock=deno.lock main.ts

Port Binding

Deno apps must listen on 0.0.0.0, not localhost, inside containers:

// Wrong — only accessible inside the container
Deno.serve({ port: 8000, hostname: "localhost" }, handler);

// Right
Deno.serve({ port: 8000, hostname: "0.0.0.0" }, handler);

Debugging the Crash

kubectl logs <pod-name> --previous
kubectl describe pod <pod-name>  # check for OOMKilled

Set reasonable resource limits — Deno's V8 isolate can be memory-hungry under load:

resources:
  limits:
    memory: "256Mi"
  requests:
    memory: "128Mi"

Integrate Bugsly to capture Deno errors in production. It reports permission denials and uncaught exceptions with full context before the process terminates.