С node-direct можно заливать серверные .js файлы и обращаться к ним так же, как к .php скриптам: example.com/foo.srv.js. Установка. Конфигурация nginx. Запуск. Скрипт foo.srv.js, где req и res созданы сервером express. Когда NodeJS стал более-менее популярным, мне было нелегко осознать, что с ним всё не так просто, как с PHP. Используя последний, можно было создать .php файл, залить его на сервер, обратиться по адресу example.com/путь/имяфайла.php и радоваться. Такая простота развертывания скриптов служила одной из причин, почему "пых" стал таким популярным.  В свою очередь, NodeJS, независимо от сложности приложения, заставляет очень многие вещи делать руками.  pm2 несколько облегчает просесс обновления и запуска приложения после перезагрузки или после брошеных приложением исключений. Но с ним, во первых, нужно набить руку, во-вторых, запуск очередного приложения заставлыть повторять рутинные действия.  Всё вышесказанное является, скорее, преимуществом, чем недостатком, если вы разрабатываете крупное приложение. Но что если приложение очень простое? Что если это вовсе не приложение, а обычный сайт, с небольшой "апишкой" (например, прокси для кроссдоменных запросов)? Что если на VPS гоняется много сайтов, и для каждого настраивать NodeJS сервер — лень. node-direct — тулза, которая позволяет разворачивать серверные JavaScript скрипты так же просто, как и .php: При этом, один инстанс node-direct можно использовать на разных сайтах. За большую часть "магии" отвечает конфиг nginx. Его нужно научить обрабатывать запросы к файлам .srv.js (можно юзать любое расширение). Пример полного конфига:  Т. е. статика сервится при помощи nginx (известно, что это в несколько раз быстрее статики, которую гоняет express без кеширования), плюс, в список поддерживаемых серверных файлов можно добавить даже .php (юзабельно для легаси проектов). node-direct использует старый добрый Express. Серверные файлы должны экспортировать функцию, принимающую request и response. Hello world: JSON API: Рендеринг За подробной информацией обратитесь к документации Express. Пример гипотетического приложения: --port — порт сервера node-direct (8123 по умолчанию) В этом режиме создается HTTP сервер, раздающий статику и не ребующий nginx. Режим используется разработчиком для запуска на локальной машине. --standalone — включает режим standalone
--root — путь к статичным файлам (process.cwd() по умолчанию)
--ext — расширение серверных JS файлов (.srv.js по умолчанию) Можно добавить новое задание в crontab, вызовом crontab -e и добавлением новой задачи в файл. Пример: Как известно, NodeJS кеширует значения, которые возвращает функция require. Когда вызывается require('foo') два или более раз, функция возвращает одно и то же значение. node-direct обновляет кеш автоматически, когда файл .srv.js изменен (например, вы залили новый файл на сервер) и перезагружать node-direct нет необходимости. Проблема может возникнуть тогда, когда .srv.js запрашивает другие модули. Когда меняется foo.srv.js, кеш обновляется, как и ожидается, но когда меняется ./bar, его значение остаётся прежним. node-direct мог бы обновлять все запрашиваемые модули самостоятельно, но это бы вызвало сайд-эффекты с непредсказуемым поведением в других модулях. Эту проблему можно решить созданием вотчера, котогрый чистит кеш, когда заданный модуль обновился. В примере ниже для ./bar включена горячая замена, а для ./baz — нет. Если выглядит слишком сложно, юзайте небольшой модуль fresh-up, который делает то же самое. Как вы, возможно, заметили, nginx передаёт адрес запрашиваемого файла node-direct серверу в виде хедера X-Requested-File-Path. Используя этот хедер, злоумышленник может вызывать произвольные JavaScript файлы на вашем сервере. Для того, чтоб сделать что-то плохое, хакеру нужно знать адрес "опасного" файла, относительно рута. Для закрытия уязвимости, нужно запретить обращаться к порту  node-direct извне. Вот, как это можно сделать в Linux используя файервол ufw Веб разработчик