Going Live: Staging vs Production Environments

Welcome to Day 3! 🌍

“It works on my machine” is not a deployment strategy. You need identical environments to ensure stability.

1. The 3 Environments

1. Development (Localhost):
   • Single Node (Standalone).
   • No Auth (or weak auth).
   • Data: Mock/Dummy data.
2. Staging (The Rehearsal):
   • Replica Set (3 Nodes) - matches prod.
   • Strong Auth.
   • Data: Anonymized copy of production data.
3. Production (The Stage):
   • Replica Set (3+ Nodes across zones).
   • Strict Firewall.
   • Data: Real Customer Data.

2. Managing Configuration

Do NOT hardcode connection strings. Use Environment Variables.

# .env.development
DB_URI=mongodb://localhost:27017/myapp

# .env.production
DB_URI=mongodb+srv://user:pass@cluster0.mongodb.net/myapp

In Node.js:

const mongoose = require('mongoose');
mongoose.connect(process.env.DB_URI);

3. MongoDB Atlas vs Self-Hosted

MongoDB Atlas (Managed)

• Pros: Auto-backups, Auto-scaling, One-click upgrades.
• Cons: Can get expensive at scale.

Self-Hosted (EC2 / DigitalOcean)

• Pros: Cheaper raw compute. Full control.
• Cons: You have to update the OS, manage backups, and handle failover yourself.

Recommendation: Start with Atlas. Move to self-hosted only if you have a DevOps team.

4. Connection Pooling

In Production, opening/closing connections is slow. Mongoose manages a Connection Pool for you.

• checkServerIdentity: Verifies SSL certs (Crucial for Prod).
• readPreference: Can be set to secondaryPreferred to offload read traffic.

🧠 Daily Challenge

1. Create a .env file in your project.
2. Move your URI there.
3. Install dotenv and refactor your connection code.
4. Make sure you don’t commit .env to Git! (Add it to .gitignore).

See you on Day 4 for Backups & Disaster Recovery! 🚑

Next Step

Next: Backups Replica Sets →