Production-settings Today

Your application server (like Gunicorn or uWSGI) should handle logic, not static file serving.

This reduces the load on your application server and speeds up delivery for users globally.

In production, logs should be structured (usually JSON) rather than plain text. This allows tools like Datadog, Splunk, or ELK Stack to parse and search them efficiently.

What to log:

What NOT to log:

# .env.production
NODE_ENV=production
PORT=8080
API_URL=https://api.example.com
DATABASE_URL=postgresql://user:pass@prod-db:5432/app
SESSION_SECRET=<long-random-string>
REDIS_URL=redis://prod-cache:6379

Every developer knows the sinking feeling: you’ve built a fantastic feature, the tests are passing, and it runs flawlessly on your machine. You deploy it to production, and suddenly—chaos. Debug errors are spilling secrets, static files are missing, and the server is crawling.

The culprit is almost always improper production settings. production-settings

Transitioning from a development environment to a production environment isn't just about changing a URL; it’s a fundamental shift in philosophy. Development prioritizes convenience and debugging; production prioritizes security, performance, and stability.

In this post, we will walk through the essential checklist for configuring your application for a live environment. While many examples here lean heavily into Python/Django (the framework famous for its explicit settings file), these principles apply universally to Node.js, Go, Rails, and beyond.

Hardcoding a database password or API key inside config/prod.js or appsettings.json is the most common fatal error. Once code is compiled and deployed, that secret is frozen—unless you rebuild and redeploy the entire artifact to change a password. Your application server (like Gunicorn or uWSGI) should

The Fix: Externalize all variable production-settings. Use environment variables (e.g., DATABASE_URL, REDIS_HOST) or secret management tools (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault). The codebase should read from the environment at runtime.

# Bad
DB_PASSWORD = "SuperSecret123"
# Dockerfile production stage
FROM node:18-alpine AS production
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production && npm cache clean --force
COPY . .
USER node
EXPOSE 8080
CMD ["node", "server.js"]

# docker-compose.prod.yml
version: '3.8'
services:
  app:
    build:
      context: .
      target: production
    restart: always
    environment:
      - NODE_ENV=production
    networks:
      - webnet
    deploy:
      replicas: 3
      resources:
        limits:
          memory: 512M
    logging:
      driver: "json-file"
      options:
        max-size: "10m"

Epic: Environment Configuration Management

Feature ID: ENV-09

Priority: P0 (Critical)
Description:

Enable operators to define, validate, and enforce a distinct set of configuration parameters specifically for the production environment. Unlike development or staging settings, "Production-Settings" must be immutable, audited, and require elevated permissions to modify. This reduces the load on your application server
This paper defines "production settings," surveys their dimensions across industries, examines how they shape outcomes (quality, safety, cost, sustainability, and employee well‑being), and outlines methods for designing, documenting, and continuously improving production environments. It synthesizes academic and practitioner perspectives into a practical framework and provides actionable recommendations for managers, engineers, and operations teams.