Node.js: Development vs Production
Differences between Development and Production
This page covers the key differences between development and production environments in Node.js applications and best practices for managing both effectively.
Key Differences at a Glance
The NODE_ENV Environment Variable
In Node.js, the NODE_ENV environment variable is a convention used to determine the environment in which an application is running.
It's commonly set to either 'development' or 'production', though other values like 'test' or 'staging' are also used.
Note: Many Node.js frameworks and libraries (like Express, React, Vue, etc.) use NODE_ENV to enable or disable certain features and optimizations.
Setting NODE_ENV
Command Line
# Windows Command Prompt
set NODE_ENV=production
node app.js
# Windows PowerShell
$env:NODE_ENV="production"
node app.js
# Linux/macOS
export NODE_ENV=production
node app.js
package.json Scripts
{
"scripts": {
"start": "NODE_ENV=production node app.js",
"dev": "NODE_ENV=development nodemon app.js",
"test": "NODE_ENV=test jest"
}
}
Using cross-env (cross-platform)
npm install --save-dev cross-env
{
"scripts": {
"start": "cross-env NODE_ENV=production node app.js"
}
}
Using NODE_ENV in Your Application
// Simple environment check
const isProduction = process.env.NODE_ENV === 'production';
const isDevelopment = !isProduction;
// Environment-specific configuration
const config = {
port: process.env.PORT || 3000,
db: {
host: isProduction ? 'prod-db.example.com' : 'localhost',
name: isProduction ? 'myapp_prod' : 'myapp_dev'
},
logging: {
level: isProduction ? 'warn' : 'debug',
prettyPrint: !isProduction
}
};
// Express.js example
const express = require('express');
const app = express();
Note: Setting NODE_ENV=production can improve application performance by up to 35%, as some packages apply optimizations based on this setting.
Configuration Management
Different environments typically require different configurations for databases, APIs, logging, and other services.
Environment-Specific Configuration
Configuration with dotenv
// Install dotenv: npm install dotenv
require('dotenv').config(); // Loads .env file contents into process.env
// config.js
module.exports = {
development: {
port: 8080,
database: 'mongodb://localhost:27017/myapp_dev',
logLevel: 'debug',
apiKeys: {
thirdPartyService: process.env.DEV_API_KEY
}
},
test: {
port: 3001,
database: 'mongodb://localhost:27017/myapp_test',
logLevel: 'info',
apiKeys: {
thirdPartyService: process.env.TEST_API_KEY
}
},
production: {
port: process.env.PORT || 8080,
database: process.env.DATABASE_URL,
logLevel: 'error',
apiKeys: {
thirdPartyService: process.env.PROD_API_KEY
}
}
};
const env = process.env.NODE_ENV || 'development';
module.exports.current = module.exports[env];
Configuration Files
Common approaches to configuration management include:
- Environment files: Using
.envfiles with thedotenvpackage - Configuration objects: Creating environment-specific configuration objects
- Configuration services: Using external services like AWS Parameter Store, Vault, or Consul
Security Warning: Never commit sensitive information like API keys, database credentials, or secrets to version control. Always use environment variables or secure configuration services for sensitive data.
Error Handling
Error handling strategies should differ between development and production environments:
Development Environment
- Display detailed error messages and stack traces
- Use verbose logging to aid debugging
- Crash early on errors to identify issues quickly
- Enable source maps for better debugging
- Provide interactive debugging tools
Production Environment
- Hide implementation details from error responses
- Log errors for internal use but return generic error messages
- Implement proper error recovery mechanisms
- Use structured logging for better analysis
- Implement circuit breakers for external services
Environment-Specific Error Handling
const express = require('express');
const app = express();
app.get('/api/data', (req, res) => {
try {
// Some operation that might fail
throw new Error('Something went wrong');
} catch (error) {
// Log the error internally (always do this)
console.error('Error occurred:', error);
// Provide different responses based on environment
if (process.env.NODE_ENV === 'production') {
// In production: generic error message
return res.status(500).json({
error: 'An unexpected error occurred'
});
} else {
// In development: detailed error information
return res.status(500).json({
error: error.message,
stack: error.stack,
details: 'This detailed error is only shown in development'
});
}
}
});
app.listen(8080);
Logging Strategies
Logging requirements differ significantly between development and production:
Development Logging
- Verbose logging with detailed information
- Human-readable format with colors
- Console output for immediate feedback
- Debug and trace level logging enabled
- No log rotation needed
Production Logging
- Structured logging (JSON format)
- Appropriate log levels (warn/error)
- Log rotation and retention policies
- Centralized log aggregation
- Performance monitoring integration
Environment-Specific Logging with Winston
const winston = require('winston');
// Define different logging configurations per environment
const logger = winston.createLogger({
level: process.env.NODE_ENV === 'production' ? 'info' : 'debug',
format: process.env.NODE_ENV === 'production'
? winston.format.json()
: winston.format.combine(
winston.format.colorize(),
winston.format.simple()
),
defaultMeta: { service: 'user-service' },
transports: [
// Always log errors to a file
new winston.transports.File({
filename: 'error.log',
level: 'error'
}),
// In production, save all logs to a file
...(process.env.NODE_ENV === 'production'
? [new winston.transports.File({ filename: 'combined.log' })]
: []),
// In development, log to the console
...(process.env.NODE_ENV !== 'production'
? [new winston.transports.Console()]
: [])
],
});
logger.info('Application started');
logger.debug('This debug message appears only in development');
For more details on logging, see the Node.js Logging tutorial.
Performance Optimizations
Production environments should be optimized for performance and reliability:
Development Focus
- Fast refresh and hot module replacement
- Source maps for debugging
- Detailed error overlays
- Unminified code
- Development tools integration
Production Optimizations
- Code minification and tree-shaking
- Asset optimization and compression
- Content Delivery Network (CDN) usage
- Browser caching headers
- Performance monitoring
Performance Considerations
- Optimized code bundling and minification
- Caching strategies
- Cluster mode to utilize multiple CPU cores
- Memory and CPU optimizations
- Content compression
Running in Cluster Mode in Production
const cluster = require('cluster');
const http = require('http');
const numCPUs = require('os').cpus().length;
if (process.env.NODE_ENV === 'production' && cluster.isMaster) {
console.log(`Master ${process.pid} is running`);
// Fork workers
for (let i = 0; i < numCPUs; i++) {
cluster.fork();
}
cluster.on('exit', (worker, code, signal) => {
console.log(`Worker ${worker.process.pid} died`);
// Replace the dead worker
cluster.fork();
});
} else {
// Workers can share a TCP connection
http.createServer((req, res) => {
res.writeHead(200);
res.end('Hello World\n');
}).listen(8000);
console.log(`Worker ${process.pid} started`);
}
Security Considerations
Security practices should be more stringent in production environments:
Production Security Measures
- Helmet: Set security-related HTTP headers
- Rate limiting: Protect against brute force and DoS attacks
- CSRF protection: Prevent cross-site request forgery
- Input validation: Sanitize all user inputs
- HTTPS: Encrypt all communications
- Dependency scanning: Check for vulnerabilities in dependencies
Security Middleware for Production
const express = require('express');
const helmet = require('helmet');
const rateLimit = require('express-rate-limit');
const app = express();
// Apply security middleware in production
if (process.env.NODE_ENV === 'production') {
// Set security headers
app.use(helmet());
// Enable rate limiting
const limiter = rateLimit({
windowMs: 15 * 60 * 1000, // 15 minutes
max: 100, // limit each IP to 100 requests per windowMs
message: 'Too many requests from this IP, please try again later'
});
app.use('/api/', limiter);
// Force HTTPS
app.use((req, res, next) => {
if (req.header('x-forwarded-proto') !== 'https') {
res.redirect(`https://${req.header('host')}${req.url}`);
} else {
next();
}
});
}
app.get('/', (req, res) => {
res.send('Hello World');
});
app.listen(8080);
Build Process
For applications using TypeScript, Babel, or other build tools, the build process differs between environments:
Development Build
- Source maps for debugging
- Incremental compilation
- Hot module replacement
- Less aggressive optimizations
Production Build
- Minification and tree shaking
- Bundling and code splitting
- Ahead-of-time compilation
- No source maps (or external source maps)
webpack.config.js for Different Environments
const path = require('path');
const TerserPlugin = require('terser-webpack-plugin');
module.exports = (env, argv) => {
const isProduction = argv.mode === 'production';
return {
entry: './src/index.js',
output: {
path: path.resolve(__dirname, 'dist'),
filename: isProduction
? 'bundle.[contenthash].js'
: 'bundle.js'
},
mode: isProduction ? 'production' : 'development',
// Generate source maps in development but not production
devtool: isProduction ? false : 'eval-source-map',
optimization: {
minimize: isProduction,
minimizer: isProduction ? [
new TerserPlugin({
terserOptions: {
compress: true,
mangle: true
}
})
] : [],
},
// Add development server configuration for non-production
...(isProduction ? {} : {
devServer: {
contentBase: './dist',
hot: true
}
})
};
};
Package.json Scripts
{
"scripts": {
"start": "node dist/server.js",
"dev": "nodemon src/server.ts",
"build": "tsc",
"build:prod": "tsc && webpack --mode=production",
"lint": "eslint src/**/*.ts",
"test": "jest"
}
}
Deployment Considerations
Development
- Local development server
- Docker containers for dependencies
- Integrated development environment (IDE) tools
Production
- Process managers (PM2, Forever)
- Container orchestration (Kubernetes, Docker Swarm)
- Load balancing
- Health checks and monitoring
- Automated deployment pipelines
- Rollback strategies
PM2 Ecosystem File for Production
// ecosystem.config.js
module.exports = {
apps: [{
name: "my-app",
script: "./dist/server.js",
instances: "max",
exec_mode: "cluster",
env_development: {
NODE_ENV: "development",
PORT: 8080
},
env_production: {
NODE_ENV: "production",
PORT: 8080
}
}]
};
For more details on deployment, see the Node.js Deployment tutorial.
Testing Environments
Different environments have different testing requirements:
Development Testing
- Unit tests during development
- Integration tests
- Fast feedback loops
- Mocking external dependencies
Staging/QA Environment
- End-to-end tests
- Performance testing
- Configuration similar to production
- Mock data or sanitized production data
Production Testing
- Smoke tests
- Canary deployments
- Real user monitoring
- Load testing (during off-peak hours)
Best Practices
1. Use Environment Variables
Store environment-specific configuration in environment variables, not in code.
2. Automate Environment Setup
Use tools like Docker, Vagrant, or cloud templates to create consistent environments.
3. Implement Feature Flags
Use feature flags to enable features selectively in different environments.
const featureFlags = {
development: {
newUserInterface: true,
experimentalFeature: true,
betaAnalytics: true
},
production: {
newUserInterface: false,
experimentalFeature: false,
betaAnalytics: true
}
};
const env = process.env.NODE_ENV || 'development';
const features = featureFlags[env];
if (features.newUserInterface) {
// Enable the new UI
}
4. Implement Continuous Integration/Continuous Deployment (CI/CD)
Automate testing and deployment across environments to ensure consistency.
5. Monitor and Alert
Set up comprehensive monitoring and alerting in production environments.
6. Document Environment Differences
Maintain clear documentation of environment-specific configurations and requirements.
Summary
- Use the
NODE_ENVenvironment variable to distinguish between development and production environments - Implement environment-specific configuration management
- Handle errors differently in development (verbose) and production (secure)
- Adjust logging strategies based on the environment
- Apply performance optimizations and security measures in production
- Use different build and deployment processes for each environment
- Follow best practices for environment management, including automation and documentation
