DATA

Volumes, files and SFTP

Persist data across deployments, browse container files from the dashboard, and connect over SFTP.

A container’s filesystem is thrown away on every deployment. Anything that must outlive one — an upload directory, a database’s data files, a cache you would rather not rebuild — lives in a volume. This page covers volumes, the built-in file browser, and SFTP access.

Volumes

A volume maps a path inside the container to storage that survives a redeploy. Declare it on the application, in the same place you declare ports and environment variables:

TEXT

/app/uploads      →  persisted
/app/node_modules →  do NOT persist (rebuilt by the image)
/var/lib/data     →  persisted

Never persist a path the image itself populates — node_modules, vendor, a compiled dist. A stale volume then shadows the freshly built image, and you deploy new code that runs against yesterday’s dependencies. The symptom is a build that succeeds and an application that behaves as if it never deployed.

Volumes are captured by backups under their own switch, and they survive changing the image tag — that is exactly why a marketplace service or a database keeps its data across an upgrade.

Deleting an application asks explicitly what to do with its volumes. Removing the container is reversible in a minute; removing the data is not, so it is never implied by a delete you clicked quickly.

The file manager

A browser for the data directories of your applications and databases, straight from the dashboard — no shell, no SFTP client, no server access:

Browse directories, read and edit text files in place.
Upload and download; compress a selection to .zip or .tar.gz; extract an archive in place.
Rename, move, create directories, delete.
Change permissions and ownership, or run Fix permissions on a tree — directories to 775, files to 664.

Reading needs files:view, writing files:manage. The browser is confined to the scopes you actually have access to: it lists your projects, their applications and their databases, and reaches nothing outside them.

The Fix permissions button exists because the single most common “it worked locally” failure is an upload directory the container’s user cannot write to. Try it before debugging the application.

The file manager also reports storage usage against the project quota, in bytes. That is the number quotas enforces, so it is the one to watch before a disk ceiling starts refusing deployments.

SFTP accounts

When someone needs a real SFTP client — a designer pushing theme files, a legacy deployment script, a client who will not learn a dashboard — issue an SFTP account instead of a server login:

Application-scoped: The account sees exactly one application’s data. The right default.
Project-scoped: One directory per application of the project, side by side. For someone who genuinely works across the whole project.

Each account is chrooted: it is locked into its own home, and the data it may reach is mounted inside that home explicitly, one directory per application. There is no path out of it and no way to walk sideways into another tenant’s files.

Accounts take a password, SSH public keys, a read-only or read-write permission, and an optional expiry date. Rotate issues a new password and shows it once. Disabling an account cuts access without deleting it — the right move when someone leaves and you are not yet sure what their scripts touch.

Accounts are re-applied from the database on every boot, so recreating the SFTP container — an image rebuild, a host reboot — never silently drops them. Drift is reconciled towards the database, never the other way round.

Set an expiry on any account you issue to someone outside your team. An account you have to remember to revoke is an account that stays live for years.

Managing accounts needs sftp:manage; listing them sftp:view. Neither is part of the read-only role.