Skip to content

All about UNIX users

A UNIX user is the operating-system-level account that owns the files, processes, and configuration of a project on a Cyberfusion cluster. Virtual hosts, mail domains, FPM pools, Passenger apps, crons — they all belong to a UNIX user.

This article covers what you set when creating one, the Virtual Hosts vs Mail Domains choice, and the related toggles.

Where to find UNIX users

In Core, the top-level 'UNIX Users' page lists every UNIX user across your clusters. Click 'Create' to add one.

Creating a UNIX user

Required fields

  • 'Cluster' — which cluster the user lives on. Clusters that don't support UNIX users are disabled in the dropdown.
  • 'Username' — used for SSH/SFTP login. Lowercase, digits, dash, underscore. Max 32 characters.
  • 'Description' — free-form label.

Password and SSH access

  • 'Password' — optional. Minimum 24 characters when set. Leave empty for key-only access — the user can only log in via an SSH key.
  • The 'Generate' button produces a secure password for you.

Add SSH keys to the user after creation.

Default PHP and Node.js versions

  • 'Default PHP Version' — only shown when the cluster supports PHP. Sets the user's default PHP version.
  • 'Default Node.js Version' — only shown when the cluster supports Node.js. Sets the default Node.js version.

For how these defaults are enforced (and why they only work with namespacing), see UNIX user namespacing. For the steps to change them later, see Install Puppeteer — the navigation applies to any UNIX user's default.

Usage: Virtual Hosts or Mail Domains

A UNIX user is dedicated to one purpose — picked at create time as a 'Usage' tile:

  • 'Virtual Hosts' — the user is for hosting websites. Virtual hosts are created under this user.
  • 'Mail Domains' — the user is for hosting mail. Mail domains are created under this user.

A single UNIX user can't host both. To run both kinds of workload on the same cluster, create one UNIX user per purpose.

If a tile is greyed out, the cluster doesn't support that usage — the tooltip says so.

Advanced: Shell

Under 'Show advanced options':

  • 'Shell' — on by default. When off, the user can't log in via SSH at all. Useful for users that only need to own files and run processes — no interactive sessions.

Usage tracking

A UNIX user reports periodic usage stats (disk space mainly). Optionally, you can have those reports include a list of the user's largest files — useful for tracking down what's eating space.

The toggle is 'Record Usage Files', set on the UNIX user after creation. When on, each usage report carries a files list showing the top 10 largest files in the user's home directory.

Daemons

A daemon is a long-running process the cluster supervises — Laravel queue workers, Horizon, Craft queue listeners, or any custom command. Daemons belong to a UNIX user and appear under the 'Daemons' section on the UNIX user page (and on the project page, when the user belongs to a project).

Each daemon runs on one or more nodes you select. The cluster keeps the daemon running and restarts it if it dies or hits its 'Memory Limit (MiB)'. 'CPU Limit (cores)' caps the CPU it may use.

Restarting from inside the UNIX user

You can trigger a daemon restart from any process running as the UNIX user (typically a deploy script) by creating an empty file at:

{home directory}/tmp/.daemon-restart.{daemon name}.txt

A cluster watcher service picks the file up, restarts the daemon via the API, and removes the file. This avoids having to ship API credentials with the user's deploy scripts.

Trigger file must be owned by the daemon's UNIX user

The watcher checks the trigger file's owner against the daemon's UNIX user. If they don't match, the file is ignored — useful guarantee, but easy to trip over if the file is created by a different user (e.g. root).

Malware scanning

The cluster runs a daily malware scan (maldet) across UNIX user home directories. Scans cover files modified in the last day, so detection happens close to upload time.

Hits are recorded against the owning UNIX user — matched by which user's home directory the file path falls under — and appear on the UNIX user page (and on the project page) under 'Malware', with the file path and a 'Last Seen' timestamp.

A record disappears automatically once the file is no longer on disk.

  • UNIX user namespacing — what namespacing gives you (per-user PHP/Node versions, LPE protection) and the one reason to opt out.
  • Change PHP settings — PHP runtime settings, with FPM-pool and .user.ini scopes overriding the cluster default.
  • All about FPM pools — the PHP-FPM process pool that runs PHP requests for the user's virtual hosts.
  • All about Passenger apps — the Passenger-managed app that runs Node.js (or Ruby / Python) for the user's virtual hosts.
  • All about crons — crons live on UNIX users.