Architecture Overview

Files.com is a cloud-native file orchestration and automation platform built from the ground up for modern scale, resilience, and flexibility. Rather than retrofitting legacy file transfer systems into the cloud, Files.com is architected to auto-scale, recover, and serve in a globally distributed, multi-region model.

The architecture is layered, with separation of concerns across user-facing clients, routing and proxy, core APIs, regional services, and storage and data infrastructure. Each layer is designed for high availability, security, resilience, and observability.

Files.com Owned and Developed Client Applications (Client Tier)

The client tier covers every Files.com application a customer interacts with directly:

• Files.com Web Application (browser interface)
• Files.com Desktop Application v6 for Windows and macOS
• Files.com Mobile Apps for iOS and Android
• Files.com CLI, a command-line tool for power users and automation
• Files.com SDKs in Python, Go, Ruby, Node.js, and other languages
• Files.com Boomi, MuleSoft, Zapier, and Microsoft Power Automate integrations, built by Files.com and distributed through these iPaaS vendors as plugins or components

These applications are built and maintained by Files.com for tight integration, correct execution, and fast performance.

Engineering and Development Practices

Files.com develops all applications in house and does not outsource development of any application beyond minor components. The platform takes an API-first approach: all primary client applications use the same published REST API endpoints, and every UI action is backed by an API call. A small number of undocumented internal endpoints exist (for example, billing), but they are the exception.

The core is developed in-house, with industry-standard and open-source components used where appropriate, such as HTTP libraries, cryptographic primitives, and open-source SDKs. The development pipeline follows a secure software development lifecycle: code reviews, automated testing, static analysis, dependency scanning, CI/CD, and controlled release processes such as blue/green or canary deployments. Because all clients share the same API surface, new features roll out consistently and uniformly across web, mobile, CLI, and SDKs. The applications use the Files.com SDKs internally wherever possible.

Benefits and Implications

Feature parity means no client is left behind: whatever is possible through the API is possible through the UI or CLI. Bug fixes and enhancements in backend logic benefit all clients immediately. In-house clients give Files.com control over user experience, performance tuning, and security. The unified API approach prevents shadow-copy or bespoke integrations from diverging over time.

Proxy and Routing Layer (Regional)

This layer is the front door to the platform: it handles incoming client connections, SSL termination for HTTPS, routing, and initial load balancing. Files.com does not rely on AWS ELBs in this role; instead, Files.com maintains a fleet of proxy servers under its own control.

Traffic Routing and Load Balancing

The proxies direct incoming requests to the appropriate backend microservices or API endpoints. For HTTP and HTTPS, routing happens at layer 7 (based on URL, host, and path). For SFTP, FTP, and FTPS, the same infrastructure load-balances raw TCP and SSL at layer 4. The configuration supports zero-downtime code deployments: proxies update routing rules without dropping existing connections, via techniques like socket handoff and hot reconfiguration.

SSL and TLS Termination

SSL and TLS are terminated at the proxy layer for HTTPS. Decrypted traffic is then forwarded internally as needed, with internal HTTPS traffic re-encrypted. Terminating at the edge lets Files.com manage certificates and enforce strong cipher suites and TLS settings centrally.

Customer-Dedicated IPs

For customers requiring static or dedicated IPs (for example, to allow partner firewalls to allowlist Files.com traffic), the proxies have those IP addresses mapped directly to them. When a customer has two dedicated IPs, those map to distinct proxy servers via AWS networking.

Regional Deployment and Redundancy

The proxy layer exists in all 7 regions. Within each region, the proxies run in high-availability clusters, with active-active failover powered by Round Robin DNS.

Security, Traffic Control, and Edge Filtering

The proxy layer is the natural choke point for WAF rules, rate limiting, DDoS mitigation, IP filtering, access control lists, and blocking invalid requests. Logging and metrics from this layer are central to observability: latency, traffic volumes, and error rates. Proxy access and error logs are sent to centralized log systems for auditing, alerting, and troubleshooting. Files.com preserves client IPs downstream (via the PROXY protocol or X-Forwarded-For headers) so that backend services see the true origin IPs.

Core API Layer (Central / Global)

This is the brains of the system: the set of microservices that expose business logic, metadata operations, orchestration, and the central control plane.

Stack and Technologies

The core APIs are largely implemented in Ruby, covering REST endpoints, authentication, orchestration, metadata, and control logic. Underlying data technologies include:

• MySQL and Amazon Aurora for relational metadata (users, permissions, configurations)
• Redis for caching, fast ephemeral state, and in-memory operations
• Memcached for caching
• Elasticsearch for searching metadata, full-text search, and log and audit indexing
• Amazon S3 for primary file storage (object store)
• Amazon Redshift for analytics and reporting

Autoscaling is built into the API server fleet to accommodate variable load.

Multi-Tenancy and Isolation

Files.com is a multi-tenant system: customers share the same infrastructure physically but are isolated logically through namespace separation. Security boundaries prevent one customer from seeing or impacting another customer's data or operations.

Inter-Service Communication

Microservices communicate via message queuing systems for asynchronous tasks and event-driven workflows. Synchronous RPC or HTTP calls handle immediate, API-driven operations.

Background Jobs and Worker Pools

The core layer schedules and triggers background and automation tasks such as event triggers, file syncs, and transformation jobs. Centralized workers handle central tasks, while file content processing is always regionally executed in the Regional Services Layer to respect data locality, latency, and cost.

Regional Services Layer (Edge / Protocol Services)

This layer is where protocol-specific functions live (SFTP, FTP, WebDAV, and others) and where file data flows in and out. Because file content is bulky and latency-sensitive, this layer resides near the client and data region.

Key Services

Each of the following is an independent service, with its own autoscaling pool of EC2 instances in each region:

• FTP and FTPS
• SFTP
• WebDAV
• Inbound S3 (accepts uploads via S3 protocols)
• Regional Integration Services (pushes and pulls of files to and from external endpoints)
• Regional Job Processing (file movement, transformations, and syncs within region)

These services handle data plane operations: actual file transfer, proxying, and buffering. The layer also includes region-specific Redis clusters for metadata and authentication caching.

Isolation and Security

Services are isolated at the machine level (dedicated instances per service) and at the network level (via AWS Security Groups) to restrict allowed traffic. Each region's services live within their own VPC and are interconnected via VPC peering for internal control-plane coordination.

Within each service, that service operates as a multi-tenant system: customers share the same infrastructure physically but are isolated logically by connection or RPC job. All services connect to the same region-specific Redis cluster for metadata and authentication caching. One cluster serves the entire region, and Files.com uses logical separation within the Redis cluster to separate data by customer into distinct regions of the key space.

Data Flow Dynamics

When a file operation arrives (for example, a client uploading over SFTP), it is handled by the regional service instance closest to the client, assigned via geo-DNS routing. That service interacts with the central API layer for metadata, policy checks, and orchestration, while the heavy data flow stays local to minimize cross-region data transfer.

Regional Integration Services

Regional Integration Services are the microservices that implement integrations with a given type of remote service, such as SharePoint or remote SFTP. Although they are described as one service, these are independent technical implementations: some in Ruby, some in Go.

Storage, Data, and Persistence Layer

This is the foundation that persists files, metadata, audit logs, and all underlying state.

Multi-Tier Architecture

Primary storage is an object store. Customer files (blobs and file content) are stored in AWS S3, encrypted at rest. Files.com uses one master bucket per region for customer data storage. Within that bucket, customer data is separated by key (folder). S3 signing is centralized in a way that ensures only operations related to a single customer can sign an S3 request related to that customer's data.

For metadata, indexing, and caching:

• Amazon Aurora tracks user accounts, configurations, file metadata, directory structure, permissions, and other relational data.
• Redis handles high-speed caching, ephemeral state, session data, locks, and queue coordination.
• Elasticsearch indexes metadata and supports search, audit query, and logs indexing.

For audit and logging, many user actions and system events generate logs and audit records. These are streamed or batched into Elasticsearch for query and S3 for long-term retention and archive. Each log stream has its own retention policy, chosen to optimize compliance with regulatory and customer requirements.

External and Hybrid Storage Integration

Files.com can mount external storage endpoints (Azure Blob, Google Cloud Storage, S3-compatible endpoints, on-prem file servers, SharePoint, and others) and present them in the unified namespace. Access to these external storages is mediated through an Integration Service in the Regional Services Layer. From the user's perspective, external mounts behave like native directories: operations still flow through Files.com for governance, permissions, audit, transformations, and movement.

Files.com Agent Layer

The Files.com Agent bridges the Files.com cloud platform with customer-controlled or private environments. It allows Files.com to reach securely into on-premises or private cloud storage without inbound connections or complex networking configurations. This enables hybrid file orchestration, one of the capabilities that sets Files.com apart from legacy MFT or EFSS systems.

Purpose and Overview

Many enterprise customers have data or systems that cannot leave their private environment, whether for compliance, data sovereignty, or performance reasons. The Files.com Agent allows Files.com to orchestrate files in place, performing transfers, synchronizations, automations, and audits on storage endpoints that are not directly exposed to the Internet.

The Agent Layer is a secure connector that:

• Connects private storage (internal SFTP servers, NAS, SAN, SMB shares, and private S3 endpoints) to the Files.com orchestration engine.
• Executes file operations locally under customer control.
• Maintains end-to-end encryption and centralized audit trails.
• Enables Files.com workflows (automations, triggers, syncs) to run against private data as easily as cloud data.

Architecture and Design

The Files.com Agent runs as a lightweight daemon or service within the customer's infrastructure, most commonly installed on a Linux or Windows server in a data center or private VPC, or on a VM or container inside a private cloud (AWS, Azure, GCP, or private OpenStack).

Each Agent establishes a mutually authenticated, outbound encrypted connection to the Files.com cloud at the Proxy layer. This means:

• No inbound firewall changes are required; only outbound HTTPS (port 443) traffic is needed.
• Mutual identity verification is enforced: the Agent authenticates using a certificate tied to the customer's account.
• All control-plane and data-plane communications are encrypted.

The internal components of the Agent are:

• Agent Core handles communication with the Files.com control plane, job dispatch, and health monitoring.
• RPC Job Executors perform local file operations: copy, move, upload, download, and sync.
• The Credential Vault securely stores connection credentials for local resources.
• The Updater keeps the Agent patched automatically and aligned with current Files.com versions.

Agents are stateless from the Files.com perspective. Multiple Agents can be deployed in parallel for scale or redundancy, all registered under the same Files.com environment.

Security and Compliance Characteristics

The Agent never exposes inbound ports, which minimizes attack surface. Each Agent has a unique identity and certificate; a compromised Agent can be revoked immediately without affecting others. The Agent is not a data store: for the most part it streams data directly during transfer, keeping no permanent local cache unless explicitly configured. Uploads are temporarily buffered to disk in the temporary directory of the destination disk drive, and the Agent sweeps these temporary disk buffers regularly. All communications are encrypted, and file data may also be encrypted at rest on both endpoints independently. The Agent runs in the customer's administrative domain, which lets the customer control OS patching, network configuration, and deployment topology.

Deployment and Operations

Agents are distributed via signed installers, including Linux packages and Windows service executables. Setup is simple: register the Agent via the Files.com Admin UI, download a tokenized configuration file, and launch the Agent. Once registered, the Agent maintains a persistent outbound session to the Files.com control plane, reporting health and receiving work items.

Load balancing among multiple Agents is automatic. The Files.com orchestration engine distributes jobs across available Agents based on capacity and locality. Typical enterprise deployments run two or more Agents per site for redundancy, often behind corporate firewalls or in segregated network segments.

Operational Visibility

Each Agent's status (online or offline, version, last check-in) is visible in the Files.com Admin UI. Alerts can be configured for Agent health events such as disconnection, job failures, or version drift. Agents automatically receive updates and new job definitions from the Core API.

Performance and Scalability

Agents can process multiple jobs concurrently, limited only by local system resources and configured concurrency thresholds. When multiple Agents are deployed, the Files.com orchestration engine distributes workloads to prevent overloading any single Agent. Network throughput is typically bounded by the customer's outbound Internet capacity. Files.com optimizes data streaming with compression and multipart transfer techniques.

Infrastructure and Cross-Cutting Concerns

Networking and Inter-Region Connectivity

Regions are networked together via VPC peering for control-plane communication, routing, and failover. Data locality is respected: file content is not moved across regions unless requested by a user. Proxy and edge routing via geo-DNS sends clients to the nearest region for latency and performance. Customers can require use of a single region through a sitewide setting.

Redundancy, Failover, and High Availability

Every component is deployed in a high-availability configuration, with multiple instances across multiple availability zones. Files.com always uses at least 4 availability zones in the USA region and 2 availability zones in all other regions. The system supports cross-AZ and cross-region failover: if a region fails, traffic and operations are routed to another region, unless a site's settings require otherwise. Most services deploy changes using safe patterns (blue/green, canary, and rolling updates) to avoid customer-impacting downtime.

Security, Encryption, and Key Management

In transit, all client-to-proxy communication is encrypted via TLS (modern ciphers) or SSH for SFTP, unless unencrypted FTP is manually enabled on a site. At rest, files stored in S3 and other storage layers are encrypted with AES-256.

Files.com handles keys internally, with rotation, isolation, and audit controls. Customers have options for adding additional encryption via GPG.

Files.com offers multiple types of authentication, including SSO, API keys, and MFA, along with role-based access control and per-user and per-group permissions. All systems are synchronized via NTP to maintain consistency and reliable timestamps across logs.

Observability, Monitoring, and Telemetry

Metrics exist at every layer: latency, throughput, error rates, and system health. Files.com runs centralized logging, tracing, and alerting, with detailed internal dashboards for operations and support teams. Customers have direct access to their logs both through the Files.com web app and the API. These queries are streamed directly from the master Elasticsearch clusters. Files.com runs automated alerts and remediation for degraded behavior.

Compliance and Governance

The architecture and hosting environment are reviewed in annual audits such as SOC 2 Type II and documented in compliance docs. Controls exist for data retention, deletion, export, and data residency constraints, such as retaining data only in certain jurisdictions.