Transfer Usage by Route

A partner uploading over SFTP, a staff member downloading from an Amazon S3 mount, and an Automation delivering to another server can all use the same file while adding different amounts of Transfer Usage. The storage behind the folder matters, but so does the action that moves the contents.

An estimate starts with the source, destination, and transfer method. A client download followed by an upload is two separate transfers. A Files.com copy, a Sync, or an Automation can perform different work, including a copy completed within the storage provider.

File Size and Transfer Usage

The comparisons below use 0×, 1×, and 2× to mean zero, one, or two times the file's size counted as Transfer Usage. For a 100 MB file, those amounts are 0 MB, 100 MB, and 200 MB. They describe usage, not a price multiplier or the total charge for the workflow.

Initial uploads into Files.com Native Storage count toward Storage Usage rather than Transfer Usage. An ordinary download from Native Storage counts once. For remote storage, a complete upload or download relayed through Files.com's network counts once; eligible Direct Routing bypasses that relay and contributes no Transfer Usage for the contents.

Storage, API calls, connection counts, and the remote provider's charges are separate. A transfer showing 0× can still contribute to those other measures.

Each example assumes one successful transfer of the complete file, with unchanged contents. Processing, repeated downloads, and retries can add work, as described under Additional Transfer Steps.

Client Uploads and Downloads

A client is the application sending or receiving the file, such as an SFTP client, the Desktop App, the Files.com CLI App, or the Web App. A Remote Server Mount presents external storage as a Files.com folder; transferring to that folder uses the mounted storage's route.

The tables group clients and storage connections that have the same transfer-usage result. A 0× cloud entry assumes an eligible direct transfer, including a supported client version and endpoint, with no buffering or required processing. Direct Routing lists the detailed client requirements. Downloads using dedicated outbound addresses instead use the relayed route described under Additional Transfer Steps.

The CLI column means the Files.com CLI App. Running an FTP, SFTP, or WebDAV program from a command line still uses that protocol's column. AS2 and the Files.com S3-Compatible Endpoint also follow the protocol column.

The Same S3 File Through Different Clients

Suppose a partner uploads a 100 MB file to a Files.com folder backed by your Amazon S3 bucket. The partner must use SFTP, so the contents pass through Files.com and the upload contributes 100 MB of Transfer Usage, or 1×.

A staff member then downloads that file through the Desktop App using eligible Direct Routing. The contents travel from S3 to the staff member's computer, adding 0 MB. Together, the partner upload and staff download contribute 100 MB.

If the staff member instead downloads through SFTP, that download adds another 100 MB. The same upload-and-download workflow then contributes 200 MB, or 2× the original file size. Keeping the file in S3 does not by itself make access free of Transfer Usage.

Uploads From a Client

An upload starts on the client's computer and ends in the folder's storage. Uploading to Native Storage contributes 0× Transfer Usage regardless of the client. Uploading to a remote mount contributes 1× when Files.com relays the contents, or 0× when they travel directly to the remote storage.

For the generic S3 Compatible connection, an endpoint containing a path prefix uses a relayed upload, including with the Desktop App or CLI App.

Downloads to a Client

A download starts in the folder's storage and ends on the client's computer. Native Storage downloads count once. Several cloud connections support direct downloads even though their uploads use Files.com's network.

The Web App column describes an ordinary single-file download. Previews and generated ZIP downloads perform different work.

Using the Agent's Direct Transfers requires its own configuration and a reachable direct connection. A CLI App or Desktop App transfer that falls back to the ordinary Files.com route counts as 1×.

Different Upload and Download Routes

Suppose a staff member uploads a 100 MB file to an Azure Blob Storage mount through the Desktop App, then downloads it once. The upload is relayed and contributes 100 MB. An eligible direct download contributes 0 MB, giving a combined 100 MB of Transfer Usage.

The same directional difference applies to Google Cloud Storage connections using HMAC or service account JSON credentials. With an OAuth connection, both directions are relayed, so uploading and downloading the 100 MB file contributes 200 MB.

A different distinction applies to Backblaze B2. A 100 MB Web App upload contributes 100 MB, while an eligible direct upload through a supported CLI App contributes 0 MB. Eligible single-file downloads from that mount contribute 0 MB in either client. Upload support must be considered separately from download support.

Separate Downloads and Uploads Through a Computer

When you download a file to a computer and then upload it to another Files.com folder, add the source download usage to the destination upload usage. The two steps can use different clients; each step follows its own column in the tables above.

For example, the following combinations use the Files.com CLI App to download one file to local storage and then upload it. Eligible S3 transfers are direct, and the SFTP mount is relayed.

For a 100 MB file downloaded from Native Storage and uploaded to an SFTP mount, the download contributes 100 MB and the upload contributes another 100 MB. The total is 200 MB. In the reverse direction, downloading from the SFTP mount contributes 100 MB and uploading into Native Storage contributes 0 MB, for a total of 100 MB.

An eligible direct download from an S3 mount followed by an upload into Native Storage contributes 0 MB of Transfer Usage: the download bypasses Files.com's network, and the native upload counts toward Storage Usage. The new native copy then has its own storage usage and subsequent download behavior.

These results apply to separate client downloads and uploads. A Copy or Move action in Files.com follows the server-side behavior below, including when that action is requested from an app or script.

Files.com Copies, Syncs, and Automations

A Files.com Copy or Move action, a scheduled Sync, and an Automation perform work between their configured locations. The interface or trigger that starts the work does not make it a direct client transfer. For example, selecting Copy in the Web App does not mean the browser downloads the file and uploads it again.

The amount counted depends on the storage and operation. A move can rename a remote file in place, copy it within the provider and delete the source, or transfer its contents to another storage location. Remote Mount File Operations explains these differences.

Client Direct Routing support does not establish the route of a Sync or Automation. In particular, the client upload and download tables are not a source-to-destination billing table for server-side work. A Sync also does not automatically use a connector's same-mount provider-copy operation.

Native Copies Within and Between Regions

Suppose an administrator copies a 100 MB file from one Native Storage folder to another in the same region using Files.com's Copy action. That copy contributes 0 MB of Transfer Usage. A copy to a native folder in a different region contributes 100 MB in the sending region. The destination copy also contributes to Storage Usage; a cross-region transfer resets its upload date for storage calculation.

Downloading that file to a computer and then uploading it into another native folder instead contributes 100 MB for the download, even when both folders are in the same region. The client workflow and the Files.com Copy action reach the same kind of destination through different work.

Scheduled Collection and Onward Delivery

Suppose a vendor leaves a 100 MB file on an SFTP server, and a Sync collects it into Native Storage. The external read contributes 100 MB of Transfer Usage. Writing the retained native copy contributes Storage Usage rather than a second 100 MB of Transfer Usage.

If an Automation then delivers that native file to another SFTP server, the outbound delivery adds 100 MB. The complete collection-and-delivery workflow contributes 200 MB. A transfer between two SFTP mounts that relays the complete read and write likewise counts both directions.

The schedule itself adds no file-content bytes. A later Sync run that skips an already-matching file does not repeat that file's transfer. Files selected and transferred again contribute usage again.

Reorganization Within a Remote Mount

Suppose an Automation copies a 100 MB object between two folders within one Amazon S3 mount. S3 performs the object copy, so the contents do not pass through Files.com and contribute 0 MB of Files.com Transfer Usage. S3's own request, storage, and other charges still apply.

FTP and SFTP distinguish a rename from a copy. A rename can be completed by the remote server without transferring the contents; a copy reads the file and uploads its contents to the new path. Azure Blob Storage can also fall back from a provider-side copy to a streamed copy. The 0× provider-copy row applies only when the contents stay within the remote service.

Two mounts backed by the same provider do not automatically share the within-mount copy behavior. Source and destination mounts, required processing, and the operation determine the work performed.

Transfers Between Files.com Sites

A transfer between Files.com sites using a Files.com to Files.com Remote Server or Connected Sites is exempt from billable inter-site Transfer Usage for both customers.

For example, transferring a 100 MB file from Native Storage in one site into Native Storage in a connected site contributes 0 MB of inter-site Transfer Usage. The retained destination copy contributes to that site's Storage Usage. A subsequent client download is a separate operation; the inter-site exemption does not make every later use of the file exempt.

Additional Transfer Steps

Routing and processing settings can change an otherwise direct transfer. An estimate must include those stages, as well as subsequent downloads or deliveries.

Dedicated Outbound Addresses

Suppose a 100 MB S3 download is configured to use Files.com's dedicated outbound addresses. Files.com relays the download so the provider sees those source addresses. It contributes 100 MB rather than the 0 MB of an eligible direct download.

Selecting dedicated addresses for that Remote Server does not make an eligible direct client upload originate from Files.com's addresses. That upload can still go directly from the client to S3 and contribute 0 MB.

Buffered Uploads and Processing

With Buffered Uploads, Files.com first receives the file into temporary Native Storage and then sends it to the remote destination. For an unchanged 100 MB file delivered once, the onward transfer contributes 100 MB of Transfer Usage, and temporary Storage Usage also applies. A 0× direct-upload entry therefore does not apply to that buffered upload.

GPG processing, Auto Unzip, and upload Malware Scanning can require staging even when optional buffering is disabled. Processing can change the size or number of delivered files, and further workflow actions can add deliveries. Count those contents and stages rather than applying 1× or 2× to the original file regardless of its outputs.

Repeated Reads and Deliveries

The multipliers describe the specified transfers, not a lifetime maximum for a file. Three complete relayed downloads of a 100 MB file contribute 300 MB, even though only one 100 MB file is stored. A workflow delivering a copy to several destinations similarly has more than one delivery to account for.

Interrupted transfers, retries, and application read patterns can make actual usage differ from a one-pass estimate. Understanding Usage with SFTP and Desktop App explains how read-ahead can fetch contents that an application does not finish consuming.