Feature Request: Built-in file logging support (output logs to .log files + console)

[RuanMingze]

Goals

1. Add native support to write all server-side logs to configurable .log files
2. Provide zero-dependency file logging config via next.config.js
3. Capture both framework internal logs and application logs without third-party libs

Non-Goals

1. Replace or disable console logging by default
2. Support client-side file logging in browsers
3. Implement advanced centralized logging or complex filtering rules

Background

Many developers using self-hosted Next.js deployments (Docker, VPS, bare metal) need persistent log files for debugging, auditing, and monitoring. Currently, the only way to achieve this is by using external libraries like winston or pino, which cannot fully capture Next.js internal logs (e.g., middleware, startup, framework errors) and require boilerplate setup. Other frameworks like Express, Fastify, and NestJS offer built-in or first-class file logging support, making Next.js inconsistent for production backend use cases. This feature would improve the developer experience and make Next.js more production-ready for traditional server deployments.

Proposal

Extend the next.config.js logging configuration to support native file logging.
Add a new logging.file configuration:
module.exports = {
logging: {
file: {
enabled: true,
dir: './logs',
rotate: {
maxSize: '20m',
maxFiles: '14d'
}
}
}
};
The framework will automatically create logs directory, output all server logs to combined.log and error.log, support daily/size rotation, and capture all native logs including server components, API routes, middleware, and system errors.

[romkravets]

Hey, great write-up. While native next.config.js file logging isn't available yet, there's a zero-dependency approach that actually captures all Next.js internal logs — including middleware, server components, and startup errors — using instrumentation.ts:

// instrumentation.ts
export async function register() {
  if (process.env.NEXT_RUNTIME === 'nodejs') {
    const fs = await import('fs');
    const path = await import('path');

    fs.mkdirSync(path.join(process.cwd(), 'logs'), { recursive: true });

    const logStream = fs.createWriteStream(
      path.join(process.cwd(), 'logs/combined.log'),
      { flags: 'a' }
    );

    const levels = ['log', 'error', 'warn', 'info', 'debug'] as const;
    for (const level of levels) {
      const orig = console[level].bind(console);
      console[level] = (...args: any[]) => {
        orig(...args);
        logStream.write(
          `[${new Date().toISOString()}] [${level.toUpperCase()}] ${args.map(String).join(' ')}\n`
        );
      };
    }
  }
}

This runs before Next.js initialises, so it intercepts framework-level output that third-party loggers typically miss. Make sure instrumentationHook is enabled in next.config.js if you're on Next.js 14:

// next.config.js
module.exports = {
  experimental: {
    instrumentationHook: true, // not needed in Next.js 15+
  },
};

For log rotation, dropping in pino + pino-roll keeps the boilerplate minimal:

import pino from 'pino';
import { roll } from 'pino-roll';

const dest = await roll('logs/app.log', { size: '20m', limit: { count: 14 } });
export const logger = pino({}, dest);

And if you're on Docker/systemd and don't want any code at all:

node server.js 2>&1 | tee -a logs/combined.log

That said, I fully support adding native logging.file config — having to patch console manually isn't great DX, and it's the kind of thing that should just work out of the box for self-hosted deployments.

Cross-checked with AI assistance.