All about Passenger apps
A Passenger app is a Phusion Passenger-managed application — typically Node.js, but also Ruby or Python — that serves requests for a virtual host. This article walks through the create flow, the app-root constraint, the environment-variables warning, and the sizing fields (which mirror FPM pools).
Where to find Passenger apps
In Core, the top-level 'Passenger Apps' page lists every app. Click 'Create' to add one.
Creating a Passenger app
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 the user's cluster.
- 'Environment' — Passenger's app environment (e.g.
production,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/lifecycle fields.
App root
'App Root' must be a directory inside the UNIX user's home directory. You can't point a Passenger app at an arbitrary path on disk.
Environment variables
'Environment Variables' lets you set env vars passed to the running app. Keys must match [A-Za-z_]+.
Don't store secrets here
Environment variables in Core are stored in plain text. Don't put database passwords, API keys, or other secrets in them. Use a dedicated secrets store, or keep secrets in a .env file inside the app root with restricted permissions.
Sizing fields
These mirror the FPM-pool sizing fields conceptually — see All about FPM pools for the same trade-offs in more depth.
Max Pool Size — concurrent workers
The maximum number of concurrent worker processes. Each handles one request at a time.
If you don't know what to set: 10.
Max Requests — restart after N
Each worker restarts after this many requests, releasing any leaked memory.
If you don't know what to set: 2000.
Pool Idle Time — stop idle workers
Workers idle out after this many seconds with no traffic.
If you don't know what to set: 10.
Same trade-off as FPM pools: if all workers are stopped, the next request waits while one starts up.
CPU Limit
Optional. 'CPU Limit (cores)' caps the app's total CPU usage.
Namespacing
'Is Namespaced' applies the same security measures as on an FPM pool — dedicated /dev/, hidden home directories — to the Passenger app's processes. Recommended for shared environments.
Use cases by target group
Where Passenger apps land per group
- Tech agencies — Passenger apps are how you run a Next.js, Nuxt, Astro SSR, Rails, or Django app on a Cyberfusion cluster. The 'Node.js Version' picker plus per-UNIX-user defaults means each project can stay on the version it was built against.
- SaaS — websocket / real-time backends, small Node services in front of a separate API. Use a dedicated UNIX user per environment so a memory leak in staging can't crash the production app running on the same node. For background jobs see daemons — Passenger apps are for HTTP request handling.
- Shops — headless storefront (Next.js, Hydrogen, Vue Storefront) talking to a separate commerce backend. Same 'Max Pool Size' planning rules as FPM pools: size for peak, not average.
- Web agencies — handing off a headless build to a Cyberfusion cluster works the same as a PHP one. Pick 'NodeJS' on the virtual host instead of 'PHP' and you're done; the same isolation per UNIX user applies.