forever
A simple CLI tool for ensuring that a given script runs continuously (i.e. forever)
Top Related Projects
Monitor for any changes in your node.js application and automatically restart the server - perfect for development
Node.js Production Process Manager with a built-in Load Balancer.
Quick Overview
Forever is a CLI tool and Node.js module that ensures a given script runs continuously. It's designed to keep Node.js applications running indefinitely, automatically restarting them if they crash or stop for any reason. Forever is particularly useful for deploying Node.js applications in production environments where high availability is crucial.
Pros
- Simple and easy to use, with both CLI and programmatic interfaces
- Automatically restarts crashed applications
- Provides logging capabilities for better monitoring
- Supports multiple running processes simultaneously
Cons
- Not actively maintained (last commit was in 2019)
- May have compatibility issues with newer Node.js versions
- Limited advanced features compared to more modern alternatives
- Lacks built-in load balancing capabilities
Code Examples
- Starting a script using Forever CLI:
forever start app.js
- Starting a script with Forever in a Node.js application:
const forever = require('forever');
forever.start('app.js', {
max: 3,
silent: true,
args: []
});
- Stopping all Forever processes:
const forever = require('forever');
forever.stopAll().then(() => {
console.log('All processes have been stopped');
});
- Listing all running Forever processes:
const forever = require('forever');
forever.list(false, (err, processes) => {
console.log(processes);
});
Getting Started
To use Forever, first install it globally using npm:
npm install -g forever
Then, you can start your Node.js application using the Forever CLI:
forever start your-app.js
For programmatic usage, install Forever as a dependency in your project:
npm install forever
Then, use it in your Node.js code:
const forever = require('forever');
forever.start('your-app.js', {
max: 3,
silent: true,
args: []
});
This will start your application and ensure it keeps running, restarting it up to 3 times if it crashes.
Competitor Comparisons
Monitor for any changes in your node.js application and automatically restart the server - perfect for development
Pros of nodemon
- Automatic restarting of application when file changes are detected
- Supports various file types beyond just JavaScript (e.g., CoffeeScript, TypeScript)
- Customizable through a configuration file (nodemon.json)
Cons of nodemon
- Primarily focused on development environments, not production
- May consume more system resources due to constant file watching
Code Comparison
nodemon:
{
"watch": ["src"],
"ext": "js,json",
"ignore": ["src/**/*.spec.js"],
"exec": "node ./src/index.js"
}
forever:
forever start script.js
forever stop script.js
forever restart script.js
Key Differences
- nodemon is more suited for development, automatically restarting on file changes
- forever is designed for keeping apps running indefinitely, even after crashes
- nodemon offers more granular control over watched files and directories
- forever provides simpler command-line usage for starting, stopping, and restarting apps
Both tools serve different purposes: nodemon excels in development environments with its automatic reloading, while forever is better suited for production environments where keeping the application running is the primary concern.
Node.js Production Process Manager with a built-in Load Balancer.
Pros of pm2
- More feature-rich with built-in load balancing, monitoring, and logging
- Active development with frequent updates and larger community support
- Supports multiple languages beyond Node.js (Python, Ruby, etc.)
Cons of pm2
- Steeper learning curve due to more complex configuration options
- Higher resource usage, especially for smaller applications
- Can be overkill for simple projects that don't require advanced features
Code Comparison
pm2:
const pm2 = require('pm2');
pm2.connect((err) => {
pm2.start({ script: 'app.js', name: 'myapp' }, (err, apps) => {
pm2.disconnect();
});
});
forever:
const forever = require('forever');
forever.start('app.js', {
max: 3,
silent: true,
args: []
});
Both pm2 and forever are popular process managers for Node.js applications, but they cater to different needs. pm2 is more suitable for complex, production-grade applications that require advanced features and monitoring capabilities. forever, on the other hand, is simpler and more lightweight, making it a good choice for smaller projects or developers who prefer a straightforward approach to process management.
The code examples demonstrate the basic usage of each tool to start an application. pm2's API is more extensive, reflecting its broader feature set, while forever's API is more concise and easier to grasp for beginners.
Pros of node-supervisor
- Lightweight and simple to use
- Automatically restarts the application when files change
- Supports watching specific file extensions
Cons of node-supervisor
- Less feature-rich compared to Forever
- Limited configuration options
- Not actively maintained (last commit in 2017)
Code Comparison
node-supervisor:
supervisor.run([
'-w', 'app,lib',
'-e', 'js,json',
'app.js'
]);
Forever:
forever.start('app.js', {
watch: true,
watchDirectory: 'app',
watchIgnorePatterns: ['**/*.log']
});
Key Differences
- Forever offers more advanced features like logging, multiple app management, and CLI tools
- node-supervisor focuses on simplicity and file watching for development
- Forever is actively maintained and has a larger community
- node-supervisor is better suited for quick development setups, while Forever is more appropriate for production environments
Use Cases
- Choose node-supervisor for rapid development and simple file watching needs
- Opt for Forever when deploying Node.js applications in production or requiring advanced process management features
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
forever
A simple CLI tool for ensuring that a given script runs continuously (i.e. forever). Note that this project currently fully depends on the community for implementing fixes and new features. For new installations we encourage you to use pm2 or nodemon
Installation
$ [sudo] npm install forever -g
Note: If you are using forever programmatically you should install forever-monitor.
$ cd /path/to/your/project
$ [sudo] npm install forever-monitor
Usage
There are two ways to use forever: through the command line or by using forever in your code. Note: If you are using forever programatically you should install forever-monitor.
Command Line Usage
You can use forever to run scripts continuously (whether it is written in node.js or not).
Example
forever start app.js
Options
$ forever --help
usage: forever [action] [options] SCRIPT [script-options]
Monitors the script specified in the current process or as a daemon
actions:
start Start SCRIPT as a daemon
stop Stop the daemon SCRIPT by Id|Uid|Pid|Index|Script
stopall Stop all running forever scripts
restart Restart the daemon SCRIPT
restartall Restart all running forever scripts
list List all running forever scripts
config Lists all forever user configuration
set <key> <val> Sets the specified forever config <key>
clear <key> Clears the specified forever config <key>
logs Lists log files for all forever processes
logs <script|index> Tails the logs for <script|index>
columns add <col> Adds the specified column to the output in `forever list`. Supported columns: 'uid', 'command', 'script', 'forever', 'pid', 'id', 'logfile', 'uptime'
columns rm <col> Removed the specified column from the output in `forever list`
columns set <cols> Set all columns for the output in `forever list`
columns reset Resets all columns to defaults for the output in `forever list`
cleanlogs [CAREFUL] Deletes all historical forever log files
options:
-m MAX Only run the specified script MAX times
-l LOGFILE Logs the forever output to LOGFILE
-o OUTFILE Logs stdout from child script to OUTFILE
-e ERRFILE Logs stderr from child script to ERRFILE
-p PATH Base path for all forever related files (pid files, etc.)
-c COMMAND COMMAND to execute (defaults to node)
-a, --append Append logs
-f, --fifo Stream logs to stdout
-n, --number Number of log lines to print
--pidFile The pid file
--uid DEPRECATED. Process uid, useful as a namespace for processes (must wrap in a string)
e.g. forever start --uid "production" app.js
forever stop production
--id DEPRECATED. Process id, similar to uid, useful as a namespace for processes (must wrap in a string)
e.g. forever start --id "test" app.js
forever stop test
--sourceDir The source directory for which SCRIPT is relative to
--workingDir The working directory in which SCRIPT will execute
--minUptime Minimum uptime (millis) for a script to not be considered "spinning"
--spinSleepTime Time to wait (millis) between launches of a spinning script.
--colors --no-colors will disable output coloring
--plain Disable command line colors
-d, --debug Forces forever to log debug output
-v, --verbose Turns on the verbose messages from Forever
-s, --silent Run the child script silencing stdout and stderr
-w, --watch Watch for file changes
--watchDirectory Top-level directory to watch from
--watchIgnore To ignore pattern when watch is enabled (multiple option is allowed)
-t, --killTree Kills the entire child process tree on `stop`
--killSignal Support exit signal customization (default is SIGKILL),
used for restarting script gracefully e.g. --killSignal=SIGTERM
Any console output generated after calling `forever stop/stopall` will not appear in the logs
-h, --help You're staring at it
[Long Running Process]
The forever process will continue to run outputting log messages to the console.
ex. forever -o out.log -e err.log my-script.js
[Daemon]
The forever process will run as a daemon which will make the target process start
in the background. This is extremely useful for remote starting simple node.js scripts
without using nohup. It is recommended to run start with -o -l, & -e.
ex. forever start -l forever.log -o out.log -e err.log my-daemon.js
forever stop my-daemon.js
There are several examples designed to test the fault tolerance of forever. Here's a simple usage example:
$ forever -m 5 examples/error-on-timer.js
JSON Configuration Files
In addition to passing forever the path to a script (along with accompanying options, described above), you may also pass forever the path to a JSON file containing these options. For example, consider an application with the following file structure:
.
âââ forever
â âââ development.json
âââ index.js
// forever/development.json
{
// Comments are supported
"uid": "app",
"append": true,
"watch": true,
"script": "index.js",
"sourceDir": "/home/myuser/app",
"logFile": "/home/myuser/logs/forever.log",
"outFile": "/home/myuser/logs/out.log",
"errFile": "/home/myuser/logs/error.log"
}
This application could be started with forever, as shown below:
$ forever start ./forever/development.json
Absolute paths to such configuration files are also supported:
$ forever start /home/myuser/app/forever/development.json
Note: Forever parses JSON configuration files using shush, allowing the use of in-line comments within such files.
Multi-App Configuration Files
JSON configuration files can also be used to define the startup options for multiple applications, as shown below.
[
{
// App1
"uid": "app1",
"append": true,
"watch": true,
"script": "index.js",
"sourceDir": "/home/myuser/app1"
},
{
// App2
"uid": "app2",
"append": true,
"watch": true,
"script": "index.js",
"sourceDir": "/home/myuser/app2",
"args": ["--port", "8081"]
}
]
Using In Your Code
The forever module exposes some useful methods to use in your code. Each method returns an instance of an EventEmitter which emits when complete. See the forever cli commands for sample usage.
Remark: As of forever@0.6.0
processes will not automatically be available in forever.list()
. In order to get your processes into forever.list()
or forever list
you must instantiate the forever
socket server:
forever.startServer(child);
This method takes multiple forever.Monitor
instances which are defined in the forever-monitor
dependency.
forever.load (config)
Synchronously sets the specified configuration (config) for the forever module. There are two important options:
Option | Description  | Default |
---|---|---|
root | Directory to put all default forever log files | forever.root |
pidPath | Directory to put all forever *.pid files | [root]/pids |
sockPath | Directory for sockets for IPC between workers | [root]/sock |
loglength | Number of logs to return in forever tail | 100 |
columns | Array of columns to display when format is true | forever.config.get('columns') |
debug | Boolean value indicating to run in debug mode | false |
stream | Boolean value indicating if logs will be streamed | false |
forever.start (file, options)
Starts a script with forever. The options
object is what is expected by the Monitor
of forever-monitor
.
forever.startDaemon (file, options)
Starts a script with forever as a daemon. WARNING: Will daemonize the current process. The options
object is what is expected by the Monitor
of forever-monitor
.
forever.stop (index)
Stops the forever daemon script at the specified index. These indices are the same as those returned by forever.list(). This method returns an EventEmitter that raises the 'stop' event when complete.
forever.stopAll (format)
Stops all forever scripts currently running. This method returns an EventEmitter that raises the 'stopAll' event when complete.
The format
parameter is a boolean value indicating whether the returned values should be formatted according to the configured columns which can set with forever columns
or programmatically forever.config.set('columns')
.
forever.list (format, callback)
Returns a list of metadata objects about each process that is being run using forever. This method will return the list of metadata as such. Only processes which have invoked forever.startServer()
will be available from forever.list()
The format
parameter is a boolean value indicating whether the returned values should be formatted according to the configured columns which can set with forever columns
or programmatically forever.config.set('columns')
.
forever.tail (target, options, callback)
Responds with the logs from the target script(s) from tail
. There are two options:
length
(numeric): is is used as the-n
parameter totail
.stream
(boolean): is is used as the-f
parameter totail
.
forever.cleanUp ()
Cleans up any extraneous forever *.pid files that are on the target system. This method returns an EventEmitter that raises the 'cleanUp' event when complete.
forever.cleanLogsSync (processes)
Removes all log files from the root forever directory that do not belong to current running forever processes. Processes are the value returned from Monitor.data
in forever-monitor
.
forever.startServer (monitor0, monitor1, ..., monitorN)
Starts the forever
HTTP server for communication with the forever CLI. NOTE: This will change your process.title
. This method takes multiple forever.Monitor
instances which are defined in the forever-monitor
dependency.
Logging and output file locations
By default forever
places all of the files it needs into /$HOME/.forever
. If you would like to change that location just set the FOREVER_ROOT
environment variable when you are running forever:
FOREVER_ROOT=/etc/forever forever start index.js
Make sure that the user running the process has the appropriate privileges to read & write to this directory.
Run Tests
$ npm test
License: MIT
Author: Charlie Robbins
Maintainer: Igor Savin
Contributors: Fedor Indutny, James Halliday, Charlie McConnell, Maciej Malecki, John Lancaster
Top Related Projects
Monitor for any changes in your node.js application and automatically restart the server - perfect for development
Node.js Production Process Manager with a built-in Load Balancer.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot