SentinelX

Documentation · Managing your service

File manager and SFTP

Moving files in through the browser or SFTP, the two settings that catch people out, and keeping the working directory right.

Updated 2026-09-25 · 5 min read

There are two ways to get files onto a container, and using both together is common once a project grows.

The built-in file manager

The Files tab lets you browse, create, rename, edit and upload without leaving the browser. It is the fastest option for a single config file, a quick edit, or checking what is actually on disk.

Two things are worth knowing:

  • The browser editor is convenient and fragile. It does not warn you about unsaved changes, and it will happily save a file you did not mean to touch.
  • There is no undo. Before editing something load-bearing — .env, a systemd unit, the startup script — take a backup first.

The file manager also has a built-in editor for the same reason the panel exists: most fixes do not require a terminal.

SFTP for anything real

For syncing a project, use SFTP. The panel shows your SFTP host, port, username and password for the service — they are in your service settings, and the port differs from your application port. Connecting with a standard client:

sftp -P <sftp-port> <sftp-user>@sentinelx.me
put -r ./dist/* .
ls -la

Or mount it and copy normally:

rsync -avz --progress -e "ssh -p <sftp-port>" ./dist/ user@host:/home/container/

rsync is usually the better choice for repeat deploys: it sends only what changed, which turns a multi-minute upload into a few seconds.

Use the password from the panel, not the account password, and connect with SFTP rather than a full shell. This is worth internalising for two reasons: it keeps you out of trouble if you have shell access, and it keeps the container's process table free of interactive sessions that would otherwise count against your memory limit.

Where files go

The SFTP root is the container's home directory, and it is the working directory your startup command runs in. Upload your project so that its entry point sits directly in that root:

/home/container/index.js     <- entry point, runs from here
/home/container/package.json
/home/container/node_modules/

If you upload an extra directory level by accident, the app is one level deeper than your command expects and you get “module not found” for a file you can plainly see in the file manager. Check the path depth first when that happens — it is almost always the cause.

Do not upload node_modules

Dependencies compiled for a different platform will fail, and uploading them wastes a large share of a small storage limit. Exclude them:

rsync -avz --exclude node_modules --exclude .git ./dist/ user@host:/home/container/

Install on the container instead, so native modules match its platform. See Deploying a Node.js application.

A simple deploy loop

Once this is set up, a deploy is: upload changed files over SFTP, install if dependencies changed, restart. The last two steps are a good candidate for a scheduled task, or a single script if you automate deploys regularly.

These guides describe behaviour that is common across container platforms. Where a setting is specific to your service — your assigned port, your SFTP credentials, your startup command — it is shown in the panel rather than here, so check the Startup and Files tabs for your own values.

Found an error or something unclear? Let us know so we can correct it.