Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/khushboodaryani/Chat-App/llms.txt

Use this file to discover all available pages before exploring further.

Chat App reads its runtime configuration exclusively from environment variables, which are loaded by dotenv when backend/server.js starts. All variables should be defined in a .env file placed at the repository root — the directory that contains both /backend and /frontend. None of the variables are baked into the frontend build; they are consumed only by the Node.js process at runtime.

Variables

MONGO_URI
string
required
The MongoDB connection string used by Mongoose to connect to your database.
  • Local development: mongodb://localhost:27017/chat-app
  • MongoDB Atlas: mongodb+srv://<username>:<password>@<cluster>.mongodb.net/chat-app
The database name at the end of the URI (chat-app) will be created automatically by MongoDB if it does not already exist. This variable is required — the server will fail to connect to the database without it.
JWT_SECRET
string
required
The secret key passed to jwt.sign() when generating authentication tokens. Must be a long, random, and unpredictable string — a minimum of 32 characters is recommended.Tokens are signed with this secret and expire after 15 days. All active sessions are invalidated if this value changes, because previously issued tokens can no longer be verified.Generate a strong secret with:
openssl rand -hex 32
PORT
number
default:"4000"
The TCP port that the Express/Socket.io server listens on. Defaults to 4000 when not set (process.env.PORT || 4000).Cloud platforms such as Railway, Render, and Heroku inject their own PORT value automatically — you do not need to set this manually on those platforms.
NODE_ENV
string
default:"development"
Controls environment-specific behaviour in the application. The most important effect is on JWT cookie security: the secure flag on the jwt cookie is set to true whenever this value is not "development".Accepted values:
  • development — disables the Secure cookie flag, allowing cookies to be sent over plain HTTP on localhost.
  • production — enables the Secure cookie flag; browsers will only transmit the cookie over HTTPS connections.
Always set NODE_ENV=production when running behind a TLS-terminating reverse proxy or on any internet-facing server.

Example .env File

Place this file at the repository root before starting the server. Fill in the values for your own MongoDB cluster and generate a unique JWT_SECRET:
# MongoDB connection string (required)
MONGO_URI=mongodb+srv://user:password@cluster.mongodb.net/chat-app

# Secret key for signing JWT tokens (required)
JWT_SECRET=your-very-long-random-secret-here

# Port the Express server listens on (optional, default: 4000)
PORT=4000

# Node environment — set to production for HTTPS deployments (optional, default: development)
NODE_ENV=production
Never commit your .env file to version control. Add the following line to your .gitignore if it is not already present:
.env
Exposing MONGO_URI or JWT_SECRET in a public repository compromises your database and all user sessions.
The .env file must live at the repository root — the same directory that contains /backend and /frontend — not inside /backend/. The call to dotenv.config() in backend/server.js resolves the .env path relative to the working directory from which you launch the process (the repo root), so placing the file anywhere else will result in the variables not being loaded.
The JWT authentication cookie is configured in backend/utils/generateToken.js. The secure attribute is derived directly from NODE_ENV:
secure: process.env.NODE_ENV !== "development"
NODE_ENVsecure cookieUse case
developmentfalseLocal HTTP development on localhost
productiontrueHTTPS in production behind a reverse proxy
When secure: true, browsers enforce that the cookie is only sent over encrypted HTTPS connections. If your server is accessible over HTTP only (for example, during initial testing on a plain IP address), set NODE_ENV=development temporarily — but always switch back to production before going live.

Build docs developers (and LLMs) love