November 2026

November 2026 introduces Connected Sites, letting two organizations with their own Files.com sites work in each other's shared folders. Automations v2 gains a visual condition builder. Malware Scanning can now alert the team whose workflow a quarantined file interrupted, and archives can be created as TAR as well as ZIP.

Two security settings deserve a decision from Site Administrators: turning off Legacy App Pairing if your organization no longer runs older app releases, and requiring TLS session reuse for FTPS once your clients are tested. We also shipped a security update to the Agent, so update any installation that doesn't update itself.

Security Update for the Agent

We shipped a security update to the Files.com Agent in November. If you run the Agent, make sure it is on the latest version.

The Agent updates itself by default, so most installations already have this update. If your team changed the Agent's update policy to manage deployment itself, install the new version now. Upgrading the Agent covers the update policies and how to upgrade remotely or locally.

Legacy App Pairing

Site Administrators can now turn off Legacy App Pairing, the older sign-in method used by earlier releases of the Desktop and Mobile Apps and by the third-party Cyberduck app. Current releases of our apps sign in with OAuth instead. The legacy method is slightly less secure, and we recommend turning it off unless your organization still needs those clients.

New sites have Legacy App Pairing off by default. Existing sites keep it on until a Site Administrator changes it.

Turning it off blocks new legacy pairings without signing anyone out. Credentials already issued stay active, and OAuth sign-in is unaffected. If an older app later needs to sign in again, update it to a current release, or have a Site Administrator turn the setting back on.

TLS Session Reuse for FTPS Data Connections

Site Administrators can now require TLS session reuse for encrypted FTP data connections. FTP uses separate command and data connections. TLS session reuse ties the encrypted connection carrying files or folder listings to the authenticated command connection.

The requirement is off by default. Test each FTPS client's uploads, downloads, and folder listings before enabling it. Enabling the site requirement signs out active login sessions across the site, including sessions using other protocols.

User overrides let individual accounts require or waive reuse while the site allows exceptions. Organizations that need a uniform rule can reset explicit user choices and then disable overrides. Both settings can be enforced across Child Sites with a Child Site Management Policy.

Connected Sites

Two organizations that each run their own Files.com site can now exchange files through a Connected Sites relationship, with no API key changing hands. The Host shares a Partner's folders. The Guest's Site Administrators work with those folders from their own site, using that site's sharing and automation features within the permissions the Host gave the Partner.

The Host starts the connection. A Partner Admin selects Link Your Files.com Account under Integrations > Files.com, or a Site Administrator or Workspace Administrator uses Request Connection on the Partner's Connected Sites tab. A Site Administrator on the Guest site then approves the request, either creating a new Guest Partner or attaching the connection to an existing Partner that already represents the organization.

Once connected, Browse opens the Host's shared folders in the File Manager, and the Copy and Move dialogs and Sync location pickers offer the connected site as a location. The Host Partner's permissions are checked on every operation, and a Site Administrator on either site can Unlink the connection. Each connection shares folders in one direction. Sharing folders in both directions requires two separately approved connections.

Quarantine Alerts for Malware Scanning

When Malware Scanning quarantines a file, the uploader sees no error and the workflow waiting on that file stops. You can now send an alert to the team responsible, so a quarantined file no longer goes unnoticed until someone asks where it went.

Choose File Quarantined under Malware Scanning in an Event Channels subscription, and route it to email, Slack, Teams, a webhook, or another system target. Each alert includes the file's original path, which identifies the interrupted workflow, and its quarantine path. Existing subscriptions that match all event types pick up quarantines automatically.

The alert belongs to the file's original Workspace. To collect alerts from every Workspace at one destination in the Default Workspace, turn on Apply to All Workspaces on both the subscription and the target, as Quarantine Alerts explains. Receiving an alert doesn't grant access to the quarantine folder, which stays with Site Administrators.

Visual Condition Builder for Automations v2

Filter, If, and Switch nodes in Automations v2 now have a visual editor for their conditions, so you no longer need to write TransformScript to route files and data. Choose a property, comparison type, operator, and value, then combine rows with All Conditions, Any Condition, or condition groups. Expression Preview shows the expression the rows produce.

The node still stores a plain TransformScript expression, so existing Automations and API definitions are unchanged. Handwritten conditions open in the visual editor whenever the controls can represent them exactly.

You can switch a single row to an expression for a comparison the controls can't express. Every expression field now has a Reference link listing what an expression can read at that node.

Two details matter when moving from handwritten expressions. Fields parsed from a CSV file are text, so compare a numeric or date column as Number or Date. Text comparisons are exact and case-sensitive. Conditions covers comparison types, missing values, and groups.

TAR, TAR.GZ, and TGZ Archives

Save as Zip, the Automations v2 Zip node, and the API can now create TAR, TAR.GZ, and TGZ archives as well as ZIP. Linux and Unix tools and many partner processes expect TAR archives, so you no longer need to build them outside Files.com.

ZIP remains the default everywhere, so existing workflows and API calls keep producing ZIP files. Choose a different Archive Format in the Save as Zip dialog or the Zip node, or pass archive_format in the API. The Zip node doesn't change its destination path when you change the format, so set a matching extension yourself.

A TAR archive needs each file's size up front. When a file on a Remote Server Mount has no reported size, or its size changes while the archive is built, choose ZIP instead, as described in TAR Creation from Remote Server Mounts. Unzip and Automatic ZIP Extraction still extract ZIP archives only.

Java and JavaScript SDK 2.0, and Adaptive Transfers in PHP

Following the Python and .NET 2.0 releases in October, the Java and JavaScript SDKs reach version 2.0, and the PHP SDK gains adaptive transfers. These updates move more of the work of fast, reliable transfers into the SDKs, so an integration needs less of its own scheduling and retry code.

Java SDK 2.0

The new client.transfers() methods in Java SDK 2.0 send upload parts and download ranges in parallel, adjusting concurrency to measured throughput. With a checkpoint directory, uploads and downloads can resume in a later run, including after a crash. Downloads replace the destination file only after every byte has arrived and been checked.

FilesClient.builder() creates a client with its own credentials, Workspace, timeouts, and retries, and the existing static methods keep working.

Version 2.0 runs on Java 8 or later, and we recommend Java 25 for new applications. It changes logging, error classes, retry timing, and some dependencies, so review Upgrading before moving an existing integration.

JavaScript SDK 2.0

JavaScript SDK 2.0 adjusts upload concurrency to measured throughput, and File.uploadDirectory() and File.downloadDirectory() move a whole folder in one call. A Files.TransferJob shares limits across many transfers, and a Files.TransferControl pauses and resumes them.

new FilesClient() creates a client with its own settings, and TypeScript declarations ship in the package.

Version 2 requires Node.js 22 or later. If your application runs on an earlier Node.js release, stay on the 1.x files.com package until you upgrade Node.js. The JavaScript SDK reference covers installation and usage.

Adaptive Transfers in the PHP SDK

The PHP SDK can now run uploads and downloads as adaptive, parallel transfers. Pass the transfer option to File::uploadFile, File::uploadData, or File::downloadToFile, or run several transfers under a TransferJob with shared limits. Without the option, transfers work exactly as before.

Adaptive transfers need 64-bit PHP 7.3 or later; review Upgrading for the error-handling and pagination changes in recent releases.

Client Logs by Workspace

Client Logs, the CLI run logs uploaded with --send-logs-to-cloud, now belong to a Workspace. Under Logs & Reports > External Logs > Client Logs, the list, details, and exports show the selected Workspace's logs. The Default Workspace shows only its own logs; to review another Workspace's logs, switch to it.

Each log keeps the Workspace assigned when it was uploaded, even if the user later moves. CLI Run Logs explains who can view them, and Sending Operation/Run Logs to the Cloud explains which Workspace receives each upload.

Dedicated IP Addresses From the Files.com Owned Range

New dedicated IP addresses now come from the Files.com owned range, 198.72.80.0/20. If a partner's firewall already allows that entire range, it also covers the dedicated addresses assigned when you set up a Custom Domain, with no new allowlist request. Address Allocation explains how addresses are assigned.