n8n workflow automation

n8n runs per hosting account, on one of the account's own domains. It is an ordinary application of that account rather than a shared service: a systemd unit running as the account's user inside user-<uid>.slice, so the plan's CPU, memory and process limits already apply to it, and the front-end serves it on 443 with the certificate the domain already has.

Install it from the panel (Auto Installer → n8n, or /n8n), or from the shell:

hitechcloudcli n8n install --account oneil --domain flow.example.com

--path /flows serves it under a prefix instead of taking the whole hostname. --database sqlite|postgres overrides the choice described below.

What the install does​

• Installs the n8n npm package under ~/.n8n-app, using the account's selected Node.js runtime when it has one and the host's otherwise. Node 20 is the minimum; anything older is refused rather than left to fail at the first start.
• Writes ~/.n8n-app/n8n.env (mode 0600, owned by the account) with the host, the port, the public URLs and the database settings.
• Writes /etc/systemd/system/hitechcloud-n8n@<account>.service, enables it and starts it.
• Adds a front-end entry for the domain, so the app is reached over HTTPS on the ordinary web ports. Nothing new listens publicly: n8n itself binds 127.0.0.1 on a port between 5678 and 5778.

Where things live​

The encryption key​

n8n encrypts the credentials you save in it — API keys, database passwords, OAuth tokens — with the key in encryption.key. It is generated once, at install, and never rewritten afterwards, including by upgrade.

Include ~/.n8n-app in your backups. Restoring the data directory without that key leaves every saved credential unreadable, and n8n does not report this as a failure: it starts, the workflows are there, and each one fails when it tries to authenticate. For the same reason, an install that finds an existing data directory but no key is refused rather than given a new one.

The database​

By default the install picks for the account:

• PostgreSQL when the account already has a role on this server (a database named <account>_n8n is created inside it), because that is what holds up once several workflows run at the same time.
• SQLite otherwise — one file under the data directory, nothing to set up, and enough for most accounts.

Which one it chose is printed at the end of the install and shown on the panel page.

Webhooks and the public URL​

N8N_WEBHOOK_URL and N8N_EDITOR_BASE_URL are pinned to the domain given at install. A webhook registered with an external provider carries that full URL, so moving n8n to a different domain means re-running the install with the new one and re-registering the affected webhooks — changing DNS alone leaves the provider calling the old name.

Upgrades​

hitechcloudcli n8n upgrade <account>

The service is stopped first, with a 60 second stop timeout, so an execution in flight finishes or is interrupted cleanly before npm replaces the files; it is started again afterwards. The encryption key is not touched. If npm fails, the previous version stays installed and the service is started again.

Removing it​

hitechcloudcli n8n uninstall <account>                 # stop and unregister
hitechcloudcli n8n uninstall <account> --delete-data   # and delete everything

Without --delete-data the workflows, credentials and the encryption key are left in place, so the account can be re-installed onto the same data.

Limits that apply​

The service runs in the account's slice, so TasksMax, MemoryMax and CPUQuota from the plan cover n8n together with the account's PHP workers and shell. A workflow that forks heavily is limited by the same PID ceiling as everything else the account runs — worth knowing before blaming n8n for a "cannot fork" error.