SecureFX is a file-transfer client for moving and synchronizing data between a computer and remote servers. A saved session records the server, protocol, authentication, and starting folders, while the file panes show local and remote directories. SecureFX handles SFTP, SCP, FTPS, WebDAV, S3-compatible storage, and older FTP connections. It protects data in transit only when the selected protocol supplies encryption; choosing legacy FTP does not turn that protocol into a secure connection.
Sessions define trust
A session combines the hostname with a protocol and login method. SFTP and SCP use SSH host keys to identify the server. The first connection therefore needs a deliberate host-key check, because accepting an unexpected key stores trust in that identity for later sessions.
SecureFX can share sessions and a host-key database with SecureCRT when both products use the bundle configuration. That removes duplicate setup, but it also means a changed shared session affects both workflows. A copied session name does not create a separate security boundary.
Queues control transfers
Dragging files adds work to the transfer queue. SecureFX can pause and resume queued transfers, and its relentless-transfer behavior can reconnect after a broken connection. Resume avoids restarting a large transfer, but the remote server and protocol must support a compatible continuation.
Parallel transfers can improve throughput, while a serial queue avoids problems on servers that limit simultaneous connections. Increasing concurrency beyond the server’s limit produces retries rather than useful speed. Bandwidth throttling can preserve capacity for calls or other network work during a long upload.
Overwrite rules matter
When a destination already has the same name, SecureFX can confirm each case, always overwrite, never overwrite, or overwrite only when the source is older or newer under the selected rule. These choices apply mechanically to the compared files.
Timestamp comparisons depend on correct clocks and time-zone settings at both ends. A wrong remote time zone can make an older file appear newer. Use confirmation until the session reports consistent times, especially before replacing a production configuration.
Mirrors can delete
Synchronization can upload, download, mirror the local side, mirror the remote side, or work between remote servers. A mirror treats one side as the model. Files that exist only on the other side may be removed or replaced so the destination matches that model.
Wildcard filters can include or exclude folders and file types. An exclusion can protect a cache or private folder, but a reversed filter can omit the files the job was meant to copy. Preview the direction, paths, and filter results before saving a recurring synchronization task.
Automation needs silence
SecureFX on Windows can schedule transfers through its command-line utility and the Windows task scheduler. The saved session must connect without asking for a password, host-key decision, or another interactive answer. The Windows user must also be logged in when the scheduled task runs.
A configuration passphrase conflicts with unattended scheduling because the task cannot open the protected configuration by itself. Removing that passphrase changes how stored settings are protected. Use restricted account permissions and an authentication method designed for automation rather than embedding a broadly privileged password.
Remote edits upload
SecureFX can open a remote file in a local editor and upload the changed file after a save. The editor works on a transferred local copy; it does not edit server storage byte by byte. Closing the transfer client or losing the connection can interrupt the upload after the local editor reports a successful save.
Server permissions still control the final write. A user may be able to download a file but not replace it. Keep a local copy until the remote timestamp and content confirm the upload, and avoid two people editing the same remote file through separate sessions.
