Bun.js + Docker Mastery
Operate
- Confirm the goal, scope, Bun version, deployment target, Docker constraints, database choice, traffic profile, and definition of done.
- Prefer small vertical slices with tests and explicit tradeoffs.
- Use Bun-native capabilities when they simplify the system, but do not force Bun-specific APIs where the standard Web platform is already clear.
- Optimize for operability: graceful shutdown, structured logs, health checks, timeouts, and safe defaults are part of the baseline.
The goal is not just “fast on benchmarks”. The goal is a service that stays easy to debug and safe to run in production.
Default Standards
- Keep
src/index.ts as bootstrap only; move app wiring to src/app.ts and business logic to services/use-cases.
- Validate environment variables and request payloads at the boundary.
- Prefer explicit error types and one global error mapping strategy.
- Keep TypeScript strict; avoid
any, hidden type assertions, and implicit runtime contracts.
- Prefer idempotent handlers for side-effecting endpoints where retries can happen.
- Treat database, cache, and outbound HTTP as failure-prone dependencies: always define timeouts and degradation behavior.
“Bad vs Good” (common production pitfalls)
// ❌ BAD: parsing untrusted input directly in the service layer.
const user = await userService.create(await c.req.json())
// ✅ GOOD: validate at the HTTP boundary before entering business logic.
const payload = c.req.valid("json")
const user = await userService.create(payload)
// ❌ BAD: fire-and-forget async work with no ownership or logging.
void sendWebhook(order)
// ✅ GOOD: await or queue the side effect with explicit failure handling.
await webhookPublisher.publish(order).catch((error) => {
logger.error({ error, orderId: order.id }, "publish webhook failed")
throw new AppError("Webhook publish failed", 503, "WEBHOOK_UNAVAILABLE")
})
Recommended Structure
src/
├── index.ts
├── app.ts
├── config/
├── routes/
├── controllers/
├── services/
├── repositories/
├── middlewares/
├── utils/
└── types/
Validation Commands
- Run
bun install --frozen-lockfile.
- Run
bun run test.
- Run
bunx tsc --noEmit if the project uses standalone TypeScript checks.
- Run
bunx @biomejs/biome check ..
- Run
bun run build before release.
- Run Docker build validation for production images when Docker is part of the deliverable.
Runtime and API Guardrails
- Use a single request ID / trace ID strategy and include it in logs and error responses where appropriate.
- Set request body limits, timeouts, and rate limits for public endpoints.
- Do not leak stack traces, secrets, or database errors to clients.
- Prefer
Bun.password for password hashing instead of legacy bcrypt stacks unless compatibility requires otherwise.
- Make shutdown explicit: stop accepting traffic, drain in-flight work, and close DB/Redis clients.
Docker & Deployment Defaults
- Use multi-stage Docker builds.
- Run as non-root.
- Pin Bun base image versions; avoid floating
latest tags.
- Add
/health and /ready endpoints for orchestration environments.
- Keep image contents minimal and deterministic.
Testing Defaults
- Unit tests for pure logic and service policies.
- Integration tests for database repositories and route behavior.
- E2E tests only for critical user flows.
- Keep mocks small and close to the consumer boundary.
References
- Clean code patterns: references/clean-code-patterns.md
- Debugging guide: references/debugging-guide.md
- Docker patterns: references/docker-patterns.md
- Library arsenal: references/library-arsenal.md
- Auth and session security: references/auth-and-session-security.md
- Background jobs and queues: references/background-jobs-and-queues.md
- Database and transactions: references/database-and-transactions.md
- Observability: references/observability.md
- Security and outbound HTTP: references/security-and-outbound-http.md
- Testing strategy: references/testing-strategy.md
- Reliability and operations: references/reliability-and-operations.md
Scripts & Assets
scripts/init-project.sh - initialize a Bun project from the template.
scripts/healthcheck.ts - health endpoint template.
assets/project-template/ - project boilerplate.
1---2name: bunjs-docker-mastery3description: Principal/Senior-level Bun.js playbook for backend APIs, runtime-aware TypeScript, Docker delivery, reliability, observability, testing, and production operations. Use when: building or reviewing Bun services, hardening Hono-based APIs, modernizing Node-style backends for Bun, improving Docker and CI quality, or preparing Bun apps for production.4---56# Bun.js + Docker Mastery78## Operate910- Confirm the goal, scope, Bun version, deployment target, Docker constraints, database choice, traffic profile, and definition of done.11- Prefer small vertical slices with tests and explicit tradeoffs.12- Use Bun-native capabilities when they simplify the system, but do not force Bun-specific APIs where the standard Web platform is already clear.13- Optimize for operability: graceful shutdown, structured logs, health checks, timeouts, and safe defaults are part of the baseline.1415> The goal is not just “fast on benchmarks”. The goal is a service that stays easy to debug and safe to run in production.1617## Default Standards1819- Keep `src/index.ts` as bootstrap only; move app wiring to `src/app.ts` and business logic to services/use-cases.20- Validate environment variables and request payloads at the boundary.21- Prefer explicit error types and one global error mapping strategy.22- Keep TypeScript strict; avoid `any`, hidden type assertions, and implicit runtime contracts.23- Prefer idempotent handlers for side-effecting endpoints where retries can happen.24- Treat database, cache, and outbound HTTP as failure-prone dependencies: always define timeouts and degradation behavior.2526## “Bad vs Good” (common production pitfalls)2728```typescript29// ❌ BAD: parsing untrusted input directly in the service layer.30const user = await userService.create(await c.req.json())3132// ✅ GOOD: validate at the HTTP boundary before entering business logic.33const payload = c.req.valid("json")34const user = await userService.create(payload)35```3637```typescript38// ❌ BAD: fire-and-forget async work with no ownership or logging.39void sendWebhook(order)4041// ✅ GOOD: await or queue the side effect with explicit failure handling.42await webhookPublisher.publish(order).catch((error) => {43 logger.error({ error, orderId: order.id }, "publish webhook failed")44 throw new AppError("Webhook publish failed", 503, "WEBHOOK_UNAVAILABLE")45})46```4748## Recommended Structure4950```text51src/52├── index.ts53├── app.ts54├── config/55├── routes/56├── controllers/57├── services/58├── repositories/59├── middlewares/60├── utils/61└── types/62```6364## Validation Commands6566- Run `bun install --frozen-lockfile`.67- Run `bun run test`.68- Run `bunx tsc --noEmit` if the project uses standalone TypeScript checks.69- Run `bunx @biomejs/biome check .`.70- Run `bun run build` before release.71- Run Docker build validation for production images when Docker is part of the deliverable.7273## Runtime and API Guardrails7475- Use a single request ID / trace ID strategy and include it in logs and error responses where appropriate.76- Set request body limits, timeouts, and rate limits for public endpoints.77- Do not leak stack traces, secrets, or database errors to clients.78- Prefer `Bun.password` for password hashing instead of legacy `bcrypt` stacks unless compatibility requires otherwise.79- Make shutdown explicit: stop accepting traffic, drain in-flight work, and close DB/Redis clients.8081## Docker & Deployment Defaults8283- Use multi-stage Docker builds.84- Run as non-root.85- Pin Bun base image versions; avoid floating `latest` tags.86- Add `/health` and `/ready` endpoints for orchestration environments.87- Keep image contents minimal and deterministic.8889## Testing Defaults9091- Unit tests for pure logic and service policies.92- Integration tests for database repositories and route behavior.93- E2E tests only for critical user flows.94- Keep mocks small and close to the consumer boundary.9596## References9798- Clean code patterns: [references/clean-code-patterns.md](references/clean-code-patterns.md)99- Debugging guide: [references/debugging-guide.md](references/debugging-guide.md)100- Docker patterns: [references/docker-patterns.md](references/docker-patterns.md)101- Library arsenal: [references/library-arsenal.md](references/library-arsenal.md)102- Auth and session security: [references/auth-and-session-security.md](references/auth-and-session-security.md)103- Background jobs and queues: [references/background-jobs-and-queues.md](references/background-jobs-and-queues.md)104- Database and transactions: [references/database-and-transactions.md](references/database-and-transactions.md)105- Observability: [references/observability.md](references/observability.md)106- Security and outbound HTTP: [references/security-and-outbound-http.md](references/security-and-outbound-http.md)107- Testing strategy: [references/testing-strategy.md](references/testing-strategy.md)108- Reliability and operations: [references/reliability-and-operations.md](references/reliability-and-operations.md)109110## Scripts & Assets111112- `scripts/init-project.sh` - initialize a Bun project from the template.113- `scripts/healthcheck.ts` - health endpoint template.114- `assets/project-template/` - project boilerplate.