All about Passenger apps

A Passenger app is how Cyberfusion runs a Node.js application — and also Ruby or Python — so that visitors to your domain reach it. Cyberfusion starts it, keeps it running, and restarts a worker that leaks memory.

This article walks through creating one, where the application's files have to live, the warning about environment variables, and how to size it.

Where to find Passenger apps

The top-level 'Passenger Apps' page lists every app. Click 'Create' to add one.

Creating one

The create form asks for:

• 'Name' — lowercase, digits, dash, underscore.
• 'UNIX User' — the UNIX user the app runs as.
• 'Node.js Version' — picked from the versions installed on that user's cluster.
• 'Environment' — Passenger's app environment, for example production or development.
• 'Startup file' — the entry point relative to the app root. Defaults to app.js.

After creation you can edit the app root, environment variables, and the sizing and lifecycle fields.

App root

'App Root' must be a directory inside the UNIX user's home directory. You cannot point a Passenger app at an arbitrary path on disk.

Environment variables

'Environment Variables' are passed to the running app. Keys must match [A-Za-z_]+.

Sizing fields

Same concepts as FPM pools. Deeper discussion of the trade-offs: All about FPM pools.

• 'Max Pool Size' — the maximum number of concurrent worker processes. Each handles one request at a time. Default to 10.
• 'Max Requests' — each worker restarts after this many requests, releasing any leaked memory. Default to 2000.
• 'Pool Idle Time' — workers stop after this many seconds without traffic. Default to 10. Trade-off: when all workers are stopped, the next request waits while one starts up.
• 'CPU Limit (cores)' — optional cap on the app's total CPU usage.

Namespacing

'Is Namespaced' applies the same protections as on an FPM pool — a dedicated /dev/ and hidden home directories — to the Passenger app's processes.

Recommended for shared environments.

Common setups

• SSR frameworks — Next.js, Nuxt, Astro SSR, Rails, Django. The 'Node.js Version' picker plus per-UNIX-user defaults lets each project stay on the version it was built against.
• Websocket and real-time backends, or small Node services in front of a separate API. Give each environment its own account, so a memory leak in staging cannot crash the production app on the same server.
• Headless storefronts — Next.js, Hydrogen or Vue Storefront talking to a separate commerce backend. Size 'Max Pool Size' for peak traffic, not average.
• Handing off a headless build works the same as a PHP one: pick 'NodeJS' on the virtual host instead of 'PHP', and the same isolation per UNIX user applies.

For background jobs, use daemons instead — Passenger apps handle HTTP requests.