Skip to main content

When to Use the On-Premise Agent

Use the Files.com Agent when Files.com needs access to files on a server or network storage that the Agent host can reach. The same connection can support employees browsing documents, Partners exchanging files, and unattended transfers. It is a connection mechanism for all of those uses.

Expose Existing File Storage

The Agent runs as a service on a host in your environment. It can access local disks and network storage mounted on that host, subject to operating-system permissions and its configured root folder. A database is not exposed as a file source merely because the Agent is nearby; export the data to accessible files or use an appropriate application integration.

Create a Remote Server Mount when users or workflows should act on those remote files through Files.com. For example, staff can browse and share documents that remain on an internal file server. Use a Sync when the job needs a separate copy in Files.com or another destination.

The Agent also supports routing connections to supported servers that Files.com cannot reach directly. Review that configuration separately from exposing a local folder.

Check Network and Host Requirements

The standard Agent connection is initiated from the host toward Files.com and does not require an inbound listener. Your network must still permit the required outbound traffic. A policy that blocks that traffic needs configuration; installing the Agent does not bypass the firewall.

Optional Direct Transfers adds an inbound listener for supported CLI and Desktop App transfers. Review its ports and access separately before enabling it.

Choose a host that will remain available during the required access and transfer windows. Confirm the service account can reach the intended disks or mounted shares after a restart. Limit the configured root and permissions to the work, and review the implications before allowing the Agent to follow filesystem links.

Account for Where Data Travels

A mount leaves the authoritative files on the remote storage, but operations can transfer their contents through Files.com. Downloads, previews, editing, buffered uploads, GPG processing, and copies have their own data handling. “Stored on premises” does not establish that content never leaves the network.

For location requirements, review the actual operations, buffered uploads, and storage, routing, and access guidance. Test the intended flow against those requirements.

Compare with Other Connections

When Files.com can connect directly to the existing cloud storage or supported file-transfer server, use that Remote Server integration unless the Agent's routing or local-storage access serves a specific need. An employee who only needs to upload files from a laptop can use a client application without operating an Agent service.

The CLI can also run unattended inside your own script. Choose it when that script should control the work; choose the Agent when Files.com should reach the host as a Remote Server. Scripts, APIs & Application Workflows explains that distinction.

After choosing the Agent, follow setup, then test the actual file operations and inspect logs before enabling recurring work. Transfer performance depends on the host, storage, network, and workload; measure representative files rather than assuming one connection method always wins.