Files.com integrates with Google Cloud Storage (GCS) buckets in several ways.

The Remote Server Mount feature connects a specific folder on Files.com to the remote server in real time. That folder becomes a client, or window, accessing the files stored in your remote server or cloud. Any operation you perform on or inside the folder acts directly on the remote in real time. Dropping a file into the folder, deleting a file, creating a subfolder, or any other file or folder operation your Files.com user has permission to perform passes through to the remote in real time.

This enables use cases such as accessing files on a counterparty's cloud without provisioning individual access for individual users, reducing storage costs by using on-premise or bulk storage, and enabling applications to access third-party clouds via Files.com API, FTP, SFTP, or Files.com Apps.

The Sync feature pushes or pulls files to or from remote servers. The files exist in both places at the end of the sync process. A sync can be a push, where files from your Files.com site transfer to the remote server, or a pull, where files transfer from the remote server to your Files.com site.

Add Google Cloud Storage as a Remote Server

Add a new Remote Server to your site and select Google Cloud Storage as the server type.

Provide an Internal name for this connection. If you manage multiple remote servers, make the name clear enough to easily identify this connection.

Provide the Google Cloud Storage Bucket name that Files.com will connect to.

The Authentication Information is required because it contains the credentials Files.com uses to connect to the remote system.

Once your Remote Server is added, you can integrate it with Files.com as either a Remote Server Mount or a Sync.

Authentication Information

Files.com supports two authentication types for connecting to Google Cloud Storage. JSON is selected by default.

You can store JSON credentials or HMAC keys in the remote-server-credential-manager and select that credential when configuring the Remote Server.

With the JSON method, you enter your Google Cloud project ID and provide the JSON credentials from your service account. The Credentials (JSON) field must contain a JSON object that includes the access key and other required authentication details. Open the downloaded JSON key file in a text editor and copy its entire contents into this field. This JSON object is generated when you create a service account key in the Google Cloud Console. For more information, see Google's documentation.

The second authentication type is HMAC (XML / S3-compatible API). Use it when you're connecting through an S3-compatible API or when JSON credentials are not preferred or feasible. This method requires an access key and a secret key. These keys are part of the HMAC authentication mechanism supported by Google Cloud. Generate them in the Google Cloud Console by following Google's HMAC setup guide.

Permissions for Files.com Access

When you connect a Google Cloud Storage (GCS) bucket to Files.com, Files.com authenticates using a Service Account that you create in your Google Cloud project. The permissions granted to that Service Account determine what Files.com can do inside your bucket, such as reading, writing, or deleting files.

Assign only the permissions your workflow requires. Files.com does not need to manage bucket-level settings or IAM policies.

Full Access

Full access lets Files.com perform create, read, update, and delete (CRUD) operations on all objects within your GCS bucket. Use this configuration when Files.com needs to both upload and download files, synchronize folders, or manage data through Automations and Syncs.

The recommended approach is to grant the predefined Google Cloud IAM role Storage Object Admin (roles/storage.objectAdmin), which provides all necessary object-level permissions.

If you prefer a custom IAM role instead, it must include the following permissions:

storage.buckets.get
storage.objects.create
storage.objects.delete
storage.objects.get
storage.objects.list

These permissions let Files.com add, modify, and remove files as required.

Full access is typically used when Files.com must synchronize content bi-directionally with your GCS bucket, move or delete files automatically through Automations, or manage an ongoing file exchange or archival workflow.

Read-Only Access

Read-only access lets Files.com view and download files from your GCS bucket without changing the data. Use this configuration when Files.com needs to import data or read existing files but must not upload, overwrite, or delete anything in the bucket.

To enable this mode, assign the predefined IAM role Storage Object Viewer (roles/storage.objectViewer), which grants permission to view object metadata and read file contents.

If you prefer a custom IAM role instead, it must include the following permissions:

storage.buckets.get
storage.objects.get
storage.objects.list

These permissions let Files.com retrieve objects and list directory contents while preventing modifications.

Read-only access fits workflows where Files.com imports files for downstream processing, synchronizes data in a one-way direction, or provides visibility into files for partners, auditors, or compliance use cases without altering the source data.

Write-Only Access

Write-only access in Google Cloud Storage functions as an archive-only mode. Files.com uploads new files into your GCS bucket without viewing, modifying, or deleting any existing data. In this configuration, Files.com can deliver files to the bucket but cannot retrieve or replace objects that are already stored there. Because GCS enforces strong object immutability rules at the permission level, overwriting or deleting files is not permitted when access is limited in this way.

To configure this level of access, create a custom IAM role that includes the following permissions:

storage.buckets.get
storage.objects.create
storage.objects.list

The create permission lets Files.com add new objects to the bucket. The list permission is required for upload operations to complete successfully. Without list access, GCS cannot validate the target location and rejects write requests, even when the file name is new.

This configuration fits workflows where Files.com acts as a secure drop-off point for incoming data. Typical use cases include archival or compliance environments that prohibit modification of existing records, and one-way delivery pipelines that continuously write new files to GCS for downstream consumption or long-term retention.

Under write-only access, Files.com has no visibility into the contents of the bucket beyond confirming successful uploads. Existing objects remain fully protected and immutable from the Files.com connection.

Dedicated IPs

If your site has dedicated IP addresses, you can choose whether Files.com uses those dedicated IP addresses to interact with the remote server. Enable this to simplify networking rules in the remote system. If you do not have dedicated IP addresses, or you disable this option, connections to the remote server can come from any of Files.com's available IP Addresses.

Cleaning Up Incomplete Multipart Uploads in S3 Emulation Mode

When using Google Cloud Storage (GCS) in S3 compatibility mode with Files.com, uploads use the Multipart Upload process, just like Amazon S3.

If multipart uploads are not completed or aborted, the uploaded parts can remain stored indefinitely, consuming storage space and potentially incurring costs.

To prevent this, configure a GCS Object Lifecycle Management rule that automatically aborts incomplete multipart uploads after a set period.

The following is an example GCS Lifecycle Rule:

{
  "rule": [
    {
       action {
         type = "AbortIncompleteMultipartUpload" # Abort incomplete uploads after 7 days
      }
       condition {
         age = 7
      }
    }
  ]
}

This rule automatically aborts any multipart uploads older than seven days and deletes their parts.

Add Remote Server Mount

Remote Server Mounts are created by mounting them onto an empty folder in Files.com. We recommend against mounting onto the Root of your site, although that is supported if you need it.

Add Sync

After creating the Remote Server, you can use it to perform Syncs between your remote server and Files.com.

Automations

Folders configured with a Remote Server Mount to Google Cloud can also be used with automations. You can include Google Cloud Storage buckets as source locations or destinations for your automations.

Case Sensitivity

Be aware of case sensitivity differences when copying, moving, or syncing files and folders between Google Cloud Storage and other storage locations. Google Cloud Storage is a case sensitive system, whereas other systems may not be. Files can be overwritten, and folders can have their contents merged, if their case insensitive names match.

Folder Representation Using Slash Files

Google Cloud Storage does not natively support hierarchical folders and instead stores data in a flat namespace. Files.com represents folder structures in Google Cloud Storage using slash files, a convention that simulates directories while remaining compatible with Google's underlying storage model.