process is a global object — no require() needed — that represents the currently running Node.js program itself. Where os describes the machine, process describes this specific running instance of your application.
Basic information about the running process
console.log('Process ID:', process.pid);
console.log('Node.js version:', process.version);
console.log('Platform:', process.platform);
console.log('Current working directory:', process.cwd());
console.log('Uptime (seconds):', process.uptime());
Environment variables — the most commonly used feature
console.log(process.env.NODE_ENV); // 'development', 'production', etc.
console.log(process.env.PORT); // whatever value was set externally
Environment variables are how configuration (database URLs, API keys, port numbers) gets into an application without hardcoding it into source code — different values for local development, staging, and production, all read through the exact same process.env.SOMETHING line.
const PORT = process.env.PORT || 3000; // fall back to 3000 if not set externally
The dotenv package is commonly used to load a local .env file into process.env during development, so you don't need to manually export variables in your terminal every session.
Reading command-line arguments
// script.js
console.log(process.argv);
node script.js --env=production --verbose
process.argv is an array where index 0 is the path to the node executable, index 1 is the path to the running script, and everything after that is whatever was typed on the command line — useful for building small CLI tools that behave differently based on flags.
Exiting a process deliberately
if (!process.env.DATABASE_URL) {
console.error('Missing DATABASE_URL — cannot start');
process.exit(1); // non-zero code signals failure to whatever launched this process
}
An exit code of 0 conventionally means success; anything else signals an error. This matters in automated environments (deployment scripts, process managers, CI pipelines) that check the exit code to decide whether to retry, alert, or continue.
Catching problems before the process dies
process.on('uncaughtException', (error) => {
console.error('Unexpected error:', error);
process.exit(1); // log it, then exit — don't try to keep running in a possibly broken state
});
process.on('unhandledRejection', (reason) => {
console.error('Unhandled Promise rejection:', reason);
});
These are safety nets, not a substitute for proper try/catch and .catch() handling throughout your actual code — but they're valuable for logging an otherwise-silent crash before the process disappears, which is exactly the kind of failure that's hardest to diagnose after the fact.