Deploy Bun Apps to Production - Without Everything Catching Fire

Docker is your best bet for Bun in production. Serverless works too, but Docker gives you control and Bun's startup speed means containers boot fast anyway.

Multi-Stage Build That Actually Works

Here's a Dockerfile that I've used in production without major disasters. The key is Bun's compile feature that creates a single binary with everything bundled in:

## Build stage - this gets thrown away
FROM oven/bun:1.2.21-alpine AS builder
WORKDIR /app

## Copy lockfiles first for better Docker layer caching
COPY bun.lockb package.json ./
RUN bun install --frozen-lockfile

## Copy source and build standalone binary
COPY . .
RUN bun build --compile --minify ./src/index.ts --outfile server

## Production stage - tiny final image
FROM gcr.io/distroless/cc-debian12:nonroot
WORKDIR /app
COPY --from=builder /app/server ./
EXPOSE 3000
ENTRYPOINT ["./server"]

This gives you a ~50MB final image vs ~200MB+ if you just throw the full Bun runtime in there. Distroless images are nice because there's no shell or package manager for attackers to abuse.

Real-world gotcha: If you're using native modules (like database drivers), the compile step might fail. In that case, skip the compilation and use a normal runtime image:

FROM oven/bun:1.2.21-alpine
WORKDIR /app
COPY . .
RUN bun install --production
CMD ["bun", "run", "src/index.ts"]

Performance Reality Check

Containers start noticeably faster - usually 2-3x quicker than Node.js in my testing, sometimes way better if you're lucky. This actually matters for auto-scaling where containers spin up and down frequently.

Memory usage is generally better but YMMV. My API server uses somewhere around 30-50MB with Bun vs 50-80MB with Node.js for the same workload - depends on what your app is doing. JavaScriptCore's garbage collector seems less aggressive but I've still seen memory creep in long-running containers.

But: Don't expect miracles. If your app is I/O bound (database calls, external APIs), the runtime won't matter much. The speed benefits show up in CPU-intensive work and startup time.

Security Hardening (Don't Skip This)

Production containers need basic security:

• Run as non-root: The distroless image does this automatically
• No shell access: Can't docker exec into a distroless container (feature, not bug)
• Resource limits: Always set memory/CPU limits in your orchestrator
• Secrets via environment variables: Never embed API keys in the image

## Kubernetes example with resource limits
resources:
  requests:
    memory: "64Mi"
    cpu: "50m"
  limits:
    memory: "128Mi"
    cpu: "200m"

The compiled binary approach is nice because you don't have node_modules with 500 packages that might have vulnerabilities. Everything's baked into one executable.

Things That Actually Break

After running Bun in Docker for 8+ months:

• File watching doesn't work in containers - don't use --hot in production (duh)
• Alpine vs Debian base images - Alpine is smaller but some native modules break
• Platform architecture issues - Building on M1 Mac for x86 servers needs --platform linux/amd64
• **Memory leaks in long-running containers** - I've had to restart containers periodically, though recent versions seem more stable

Pro tip: Always test your exact Docker build on the target platform. I've been burned by builds that work locally but fail in production because of architecture differences.

More shit that will break in production:

• Environment variables get loaded differently than in Node.js - caused a 30-minute outage when our config wasn't read properly
• Some process monitoring tools don't recognize Bun processes correctly
• Log aggregation can get confused by Bun's different process title
• Auto-restart scripts written for Node.js might not handle Bun's exit codes the same way

Serverless is where Bun's fast startup time becomes a huge advantage. While everyone else waits 500ms for their Node.js function to boot, your Bun function is already serving requests.

AWS Lambda (Pain But Worth It)

Lambda doesn't support Bun natively, so you need a custom runtime. It's a pain to set up but the performance gains are real.

The easiest route is using bun-lambda which handles the Lambda runtime layer:

// handler.js - Simple Lambda wrapper
import app from \"./src/app.js\";

export const handler = async (event, context) => {
  // Convert Lambda event to standard Request
  const request = new Request(`https://example.com${event.path}`, {
    method: event.httpMethod,
    headers: event.headers || {},
    body: event.body
  });
  
  const response = await app.fetch(request);
  
  return {
    statusCode: response.status,
    body: await response.text(),
    headers: Object.fromEntries(response.headers)
  };
};

Real talk: Setting up the custom runtime layer is tedious. You need to:

1. Build Bun for Lambda's Linux environment
2. Create a runtime layer zip file
3. Configure your function to use it

But the cold start difference is dramatic - I've seen 80ms cold starts vs 300ms+ for equivalent Node.js functions.

Cloud Run: The Easy Button

Google Cloud Run is probably the best serverless option for Bun. Just push your Docker image and it handles the rest:

FROM oven/bun:1.2.21-alpine
WORKDIR /app
COPY . .
RUN bun install --production
EXPOSE 8080
CMD [\"bun\", \"run\", \"server.js\"]

Cloud Run scales to zero when not in use and spins up fast thanks to Bun's startup speed. Plus you get full container control without Lambda's weird runtime limitations.

Platform Gotchas (Learn From My Pain)

Vercel: Bun templates available but has quirks. Some Node.js APIs aren't available in their edge runtime. Test thoroughly.

Railway: Native Bun support works great but their free tier sleeps after inactivity. Good for side projects, not production.

Fly.io: Excellent global distribution with their edge network. I use this for APIs that need low latency worldwide. Their pricing is transparent unlike AWS.

Netlify: Supports Bun via container deployment but their function limitations are annoying. 10-second timeout kills long-running tasks.

What Actually Breaks in Serverless

After running Bun serverless functions for a year:

• File system access - Most serverless platforms have read-only file systems
• Global state - Functions are stateless, don't rely on global variables persisting
• Long-running connections - WebSocket connections get killed when functions scale to zero
• Large dependencies - Some platforms have size limits that Bun's bundling can help with

Pro tip: Use environment variables for configuration, not config files. Serverless functions often can't write to disk.

Monitoring That Matters

Don't just monitor response times - track cold start metrics:

const start = performance.now();

export const handler = async (event, context) => {
  const coldStartTime = performance.now() - start;
  
  // Log this to your monitoring system
  console.log(JSON.stringify({
    coldStart: coldStartTime,
    memoryUsed: process.memoryUsage().heapUsed / 1024 / 1024,
    requestId: context.awsRequestId
  }));
  
  // Your actual handler code
};

I track cold start times, memory usage, and error rates. Bun functions consistently start faster but still worth monitoring for regressions.

Cost Reality Check

Serverless pricing gets complicated fast. Bun's faster cold starts mean shorter execution times, which can reduce costs. But the custom runtime overhead on Lambda can eat into those savings.

For high-traffic APIs, a small container on Cloud Run or Fly.io often costs less than Lambda with better performance. For sporadic traffic, Lambda's pay-per-request model wins despite the setup complexity.

Look, Bun isn't magic - you still need to monitor your shit in production. But the good news is JavaScriptCore's garbage collector is less stupid than V8's, so you might actually sleep at night.

Memory Monitoring (Because Memory Leaks Still Exist)

First thing: monitor your memory usage or you'll get paged at 3am. Here's what I've been using:

// Memory monitoring for production
setInterval(() => {
  const usage = process.memoryUsage();
  const metrics = {
    heap_used_mb: Math.round(usage.heapUsed / 1024 / 1024),
    heap_total_mb: Math.round(usage.heapTotal / 1024 / 1024),
    external_mb: Math.round(usage.external / 1024 / 1024),
    rss_mb: Math.round(usage.rss / 1024 / 1024)
  };
  
  // Log or send to monitoring service
  console.log(JSON.stringify({ type: 'memory_metrics', ...metrics }));
  
  // Alert on high memory usage
  if (metrics.heap_used_mb > 500) {
    console.warn('High memory usage detected', metrics);
  }
}, 30000);

Bundle Analysis (Find What's Bloating Your App)

Bun's bundler actually tells you where your bundle size went to hell. Use bun build --analyze before you ship a 50MB bundle to production:

## Analyze bundle composition
bun build --analyze --minify ./src/index.ts --outdir ./dist

## Generate source maps for production debugging
bun build --sourcemap --minify ./src/index.ts --outdir ./dist

Tree-shaking actually works in Bun, unlike webpack where you install lodash and somehow get the entire library anyway.

Performance Profiling (Before Your Users Start Complaining)

Track your slow endpoints before they turn into customer support tickets:

import { performance, PerformanceObserver } from 'perf_hooks';

// Track request performance
function trackRequest(handler) {
  return async (req, res) => {
    const start = performance.now();
    const requestId = crypto.randomUUID();
    
    performance.mark(`request-start-${requestId}`);
    
    try {
      const result = await handler(req, res);
      performance.mark(`request-end-${requestId}`);
      performance.measure(
        `request-duration-${requestId}`, 
        `request-start-${requestId}`, 
        `request-end-${requestId}`
      );
      
      return result;
    } catch (error) {
      performance.mark(`request-error-${requestId}`);
      throw error;
    }
  };
}

Error Handling (So Your App Doesn't Die Silently)

Catch your errors before they crash production at the worst possible moment:

// Global error handler with structured logging
process.on('uncaughtException', (error) => {
  console.error(JSON.stringify({
    type: 'uncaught_exception',
    timestamp: new Date().toISOString(),
    error: {
      message: error.message,
      stack: error.stack,
      name: error.name
    },
    process: {
      pid: process.pid,
      memory: process.memoryUsage(),
      uptime: process.uptime()
    }
  }));
  
  // Graceful shutdown
  process.exit(1);
});

process.on('unhandledRejection', (reason, promise) => {
  console.error(JSON.stringify({
    type: 'unhandled_rejection',
    timestamp: new Date().toISOString(),
    reason: reason?.toString(),
    stack: reason?.stack
  }));
});

Load Testing (Find Your Breaking Point Before Users Do)

Bun handles more concurrent connections than Node.js, but you still need to know when it'll fall over. Use Artillery or k6 to find your limits:

## artillery-config.yml for Bun load testing
config:
  target: 'http://localhost:3000'
  phases:
    - duration: 60
      arrivalRate: 10
    - duration: 120
      arrivalRate: 50
    - duration: 60
      arrivalRate: 100
  ensure:
    p95: 100  # 95th percentile under 100ms
    p99: 200  # 99th percentile under 200ms
    
scenarios:
  - name: "API endpoint test"
    requests:
      - get:
          url: "/api/health"
      - post:
          url: "/api/data"
          json:
            test: "data"

Watch requests per second, memory usage, and error rates during testing. In my experience, Bun usually handles 20-50% more concurrent connections than Node.js on the same hardware - your mileage may vary depending on what your app actually does.