Loading

Local, S3 or Azure Storage

The storage backend decides where the bytes of every uploaded file live: on the web server's own disk, in an Amazon S3 bucket or in an Azure Blob Storage container. There is one backend for the whole installation, chosen by your hosting administrator. This article explains what each one means for you as an administrator, and how to check which one you have.

Where to find it

Architect Panel → Integration & Connections:

  • Deployments — the File Storage card: Storage Mode, plus the S3 bucket or the Azure storage account and container

Architect Panel → Security:

  • Security Check-up — File storage and Stored file links, in the Data protection section

Architect Panel → Activity:

  • Error Log — storage errors, such as a refused upload or a missing credential

The three backends

  • Local Web Server: simplest, with nothing outside the server to configure. Files live and die with that server, so it suits a single long-lived server with its own backups, and does not suit containers that are replaced on each deployment.
  • Amazon S3: one bucket for the installation, with each tenant's files under its own prefix. Supports direct uploads from the browser for large files and the Web Video field type. Credentials are set by your hosting administrator; S3-compatible services from other providers are not supported, because there is no setting for a different endpoint.
  • Azure Blob Storage: one container in one storage account, signed with the storage account key. Suits organisations whose infrastructure is already in Azure. See Azure Blob Storage for what it does and does not support.

None of these is set on a screen, and File Stores and upload fields cannot use different backends. Switching backend means moving every existing file; the platform has no built-in migration, so plan it with your hosting administrator.

How download links work

With S3 or Azure, your hosting administrator also chooses a link mode, and it is the setting that decides whether a stranger holding a URL could read a file:

  • Signed links (the default on both): each download gets a short-lived signed URL, so the bucket or container can stay private. The Security Check-up shows this as OK.
  • Direct links: files are served by a plain URL straight from storage. Pages load faster and the server does less work, but the bucket or container must be publicly readable. The Security Check-up marks this as Review, with the note "files are served straight from storage, so the bucket/container must be public".

Private files are always checked against the person's permissions before any link is issued; the link mode only affects what happens after that check.

Thumbnails and content types

Image thumbnails are made for JPG, JPEG, PNG, GIF and BMP files when a File Upload field has thumbnail sizes set, and they are stored on the same backend. Thumbnails now carry the correct image type when they are written to S3 or Azure. Older thumbnails written to S3 before that fix may be stored with a generic type, which some browsers download instead of displaying; your hosting administrator has a repair script that corrects them, with a dry run first.

Checking your backend

  1. Open Deployments and read Storage Mode on the File Storage card: Local Web Server, Amazon S3 or Azure Blob Storage.
  2. Open Security Check-up and confirm the Stored file links row says every download is a short-lived signed URL, unless you have deliberately chosen direct links.
  3. Upload a file to a private File Upload field, download it while signed in, and confirm it opens.
  4. Open Error Log and check nothing was logged for the upload.

What goes wrong

  • Storage Mode shows Unknown. The configured backend name is not written exactly as expected. If it is not a recognised backend at all, the platform falls back to storing files on the local server, which is probably not what was intended. Ask your hosting administrator to check it.
  • Every upload fails with "Server error when trying to upload file". The Error Log entry says why: usually missing or wrong credentials, or a bucket or container that does not exist.
  • Images download instead of displaying. Likely an old S3 thumbnail with the wrong type; ask for the repair script to be run.
  • Files are readable by anybody with the link. Direct links are in use. Decide whether that is acceptable for the data you hold.

Worked example

A council moves its installation from a single server to containers. On Local Web Server, files would vanish with each replaced container, so the hosting administrator switches to Azure Blob Storage, where the council's other systems already live, and copies the existing files across first. Afterwards the administrator confirms Storage Mode reads Azure Blob Storage, the Security Check-up shows signed links, and a test upload and download leave nothing in the Error Log.

Recommendations

  • Use an object store (S3 or Azure) for anything running in containers.
  • Keep signed links unless every file you hold is meant to be public.
  • Read the Deployments card rather than assuming which backend you are on.
  • Plan any backend change as a migration, with a copy of every file and a test afterwards.