Storing Files on Uploadcare: Why and How

In many of its features, Uploadcare provides a solid and secure solution out of the box, but not at the expense of flexibility. One such feature is the ability to easily, but finely control which user-uploaded files you really need, and which ones can be discarded.

If you are using the “autostore” feature of the Uploadcare widget, the default behavior of an Uploadcare project is to accept every file that gets thrown at it, store it in the cloud on S3, and make a public CDN link for it. This is called “autostoring”, which is part of a broader concept of “storing” files.

Of course, at scale it may not be desireable to store each and every file, because that easily wastes space. Some of the uploaded files are there by mistake, e.g. when a user changes his file selection multiple times before submitting the form, or submits only part of a file set in a multiupload dialog.

To keep only those files that your application will really serve, “autostore” can be disabled in favor of a simple mechanism of control.

Fine Control over Uploads

The “autostore” feature can be enabled or disabled on the fly on the settings page of a given project. When it's disabled, you (the application owner) have to explicitly and manually state which of the uploaded files you want to keep. Thankfully, it's easier than it may sound.

It works like this.

Without “autostore”, every file uploaded to any of your Uploadcare projects is marked as temporary upon upload. All such temporary files are automatically deleted after 24 hours from the time of their upload. They're also not available publicly, i.e. there is no CDN link for them. But, all temporary files, their attributes, and data are still available via the Uploadcare REST API.

In a way, temporary state is a file's personal limbo. The hosting application needs to make a decision to keep it in 24 hours' time, or simply ignore it, thus allowing it to be automatically discarded.

To “store” (keep) a file, you need to make an API request from your server-side code. The typicall place for such a request is the form submission handler.

PUT /files/:uuid/storage/

Of course, you need to substitute :uuid with a real UUID of whatever file you wish to keep. As soon as you do this, it's going to be stored on S3 forever or until deletion. At the same time, a public CDN link is going to be created. In the case of image files, this also allows you and your users to apply CDN operations.

This way, your application never has to deal with files uploaded by accident, as they're not even submitted with a form. In the simplest scenario you just send a store request for each submitted file (Uploadcare libraries for your language or framework of choice usually do it for you). Plus, you have optional fine control over what files to keep — you can send store requests only for a subset of submitted files, filtering them with your own personal heuristic, e.g. enforcing maximum file size or file type.

Autostore without a Server

But what if you don't have a back end, or what if there's no way to make a server-side store request? That's when “autostore” comes in handy.

In order to avoid the API request, it is paramount for automatic storing to be enabled both in project settings and in the widget. You already know how to toggle it for a project. In the widget, there is a setting that makes the widget upload files with a specially-crafted request. This request tells the Uploadcare server that incoming files should be automatically stored, but only if the project allows automatic storing.

The setting comes in two varieties. Global, for all widgets on a page:

UPLOADCARE_PUBLIC_KEY = 'your_public_key';
// ... other settings

Local, for a specific widget:

<input type="hidden" role="uploadcare-uploader" data-autostore>

To permit automatic storing on the server, the widget makes use of a common upload API request parameter UPLOADCARE_STORE. This parameter is supported by all Uploadcare methods of upload. When, in a given request, it's set to anything but 0 (“zero”) and automatic storing is enabled in project settings, the server will store every file sent with such a request.

Some Uploadcare libraries implement this functionality in their upload interface.

To Autostore or Not

Whether you can or need to use the “autostore” feature depends on your needs, of course. Here are some good examples where automatic storing is useful:

  • Private application without a server or with restricted access to server code.
  • A front-end tool plugin, like our official CKEditor plugin.
  • Environments where an additional HTTP request during form submission results in unacceptable response time.

Alternatively, if there are much more files uploaded to your account than you actually need, you are better off doing store requests yourself.

Choose whatever suits your project best and let Uploadcare handle the rest.

If you haven't found what you were looking for in these docs, try looking in our Knowledge Base.