Published files

Documents your application hands to its users — a price list, a brochure, a form — with a stable address and no build to change them.

The Files tab. These belong to the business rather than to the code.

What they are for#

A price list, a brochure, a form to download, a terms document. Things that:

  • change on the business's schedule, not the software's;
  • must keep the same address when they are replaced, because a link is already sitting in somebody's inbox;
  • should not require a deployment to update.

The address#

Each file gets a stable address on your application's own domain:

https://crm.acme.com/_files/price-list.pdf

Three useful properties follow from that address being served by the platform rather than by the application:

  • It is the same in test and live. One link works in both.
  • It works while a deployment is building, and while a build is broken.
  • It works before anything has been deployed at all. Publishing a price list should not require a deployment.

How much#

Up to 100 MB per file, and up to 200 files per application. You are told plainly if you reach either.

Replacing one#

Keeps the address. That is the entire point — a link already in a customer's inbox goes on working, and it now points at this quarter's prices.

Handing one to the builder#

Use it on a file writes a sentence into the conversation with the name, the exact address and what it is, switches you back to the conversation, and leaves the cursor after it — because what is still missing is where it belongs, and only you know that.

The current price list is published at https://crm.acme.com/_files/price-list.pdf (PDF, 340 KB). …

Then say where you want it linked from.

The builder links to files; it never copies the bytes into the application.

Not to be confused with#

Attachments in the conversation — see Showing it a file. Those explain what to build. They are not served to anybody.

Files your application's users upload — those go to the application's own storage, through its own code, and are part of what the application does. They are not managed here.

Safety#

Anything a browser could execute — an HTML or SVG file — is handed over as a download rather than rendered, because this is your application's own address and a file rendered there would run with its privileges.

Published files sit behind the access setting. On an application with a shared password, a file is not a way around it.