Deploying Elpod Applications on Bun

Prepare an Elpod application for Bun deployment with health checks, graceful shutdown, configuration validation, and architecture audits.

Deploying an Elpod service means operating a Bun process that serves native Elysia routes. Use this guide to connect Elpod startup and shutdown hooks to readiness, configuration, resource cleanup, and your platform controls.

The idea

Local development asks, “does it run?” Production asks, “can it restart, drain, scale, observe, and keep secrets safe?” Deployment is the set of decisions that turns one healthy process into a responsible fleet member.

How Elpod provides it

Elpod targets Bun ESM applications. A minimal production shape is:

FROM oven/bun:1.4.0
WORKDIR /app
ENV NODE_ENV=production
COPY package.json bun.lock tsconfig.json ./
RUN bun install --frozen-lockfile --production
COPY src ./src
USER bun
CMD ["bun", "run", "start"]

Use bun run start or bun src/main.ts, not watch mode. Keep bun.lock in the release context, run as a non-root user, and do not copy .env files or development dependencies into the image.

Expose health routes and configure the orchestrator to use /health/live for liveness and /health/ready for readiness. Give the process a termination grace period long enough for native Elysia, request scopes, queues, and providers to drain.

Production boundary

Elpod provides explicit composition, DI/lifecycle ownership, native HTTP hooks, request identity, structured errors, health routes, diagnostics, and adapters. Your application/deployment still owns:

database driver, schema, migrations policy, backups, and credentials;
durable queues, event brokers, outbox storage, and distributed idempotency;
distributed cache, locks, rate limiting, and brute-force state;
identity provider, key rotation, MFA, authorization, and tenant isolation;
OpenTelemetry SDK/exporters, log retention, alerting, and dashboards;
TLS termination, network egress, secrets injection, image scanning, and rollout policy.

Checklist

Pin Bun, Elpod, Elysia, and lockfile dependencies.
Run elpod audit --production --strict and elpod doctor --production --strict.
Run elpod seal, typecheck, tests, and migration checks in CI.
Validate required environment with defineConfig().
Configure request limits, security headers, authentication, authorization, CORS/CSRF, and rate limits.
Use shared stores for every cross-replica guarantee.
Configure structured logs, metrics, traces, alerts, and sensitive-data redaction.
Test readiness during drain and provider disposal.

Common mistakes

Scaling replicas while leaving caches, locks, rate limits, or queues in memory.
Running migrations independently on every startup without a shared lock.
Assuming container non-root settings replace application authorization.
Deploying an unpinned alpha dependency.

Health and shutdown · Configuration · Observability · CLI audits.