Cloud file storage
Overview​
Cloud file storage is a reusable connection to a cloud storage bucket or container that MessageGears uses for optimized bulk file operations. Once configured, a cloud file storage location can be selected anywhere Accelerator needs a place to stage or retrieve files, including:
MessageGears supports three file storage types: Google Cloud Storage, Amazon S3, and Azure Blob Storage.
Whichever type you choose, Accelerator performs the same four operations against the storage location: it writes staged files, reads them back, lists the contents of the bucket or container, and deletes files it no longer needs. The identity you configure must therefore be able to read, write, list, and delete objects — the provider tabs below spell out the exact permissions.
Accelerator cleans up after itself — for example, a daily job removes FastCache files once no Blueprint references them. Some files are intentionally long-lived: FastCache files backing active Blueprints stay in storage for as long as the Blueprint uses them, and Audience Recording output remains until you've ingested it. Don't apply object expiration or retention rules that automatically delete objects from the bucket, container, or path Accelerator uses — they can remove files Accelerator or your downstream processes still need.
If your bucket or container restricts network access (a storage firewall, VPC/VNet rules, or private endpoints), you will need to allow traffic from your MessageGears environment before Test Connection will succeed. Contact MessageGears Support for the egress IP addresses for your environment.
Creating a new file storage​
- Navigate to Admin > System configuration > File Storage.
- Click Add New File Storage.
- Enter a unique Name. This is how the file storage will be referenced elsewhere in Accelerator (Database Connections, FastCache Settings, Audience Recording, etc.), so it must not match the name of an existing file storage.
- Select a File Storage Type. The remaining fields change depending on the type selected (see the tabs below).
- Optionally check Default Client to authenticate using the credentials of the environment Accelerator runs in (for example, an AWS instance role, GCP attached service account, or Azure managed identity) instead of entering keys or secrets. When checked, the credential fields for the selected type are not required — you supply only the bucket or container details. This option applies mainly to self-hosted deployments where the Accelerator host itself has been granted access to the storage.
- Fill out the remaining fields for the selected file storage type.
- Click Test Connection to confirm Accelerator can authenticate and reach the bucket or container before saving.
- Click Save.
Secret fields (AWS Secret, GCS Credentials, Azure Account Key, Azure Client Secret) are stored encrypted and are never displayed again after saving. When editing an existing file storage, these fields appear blank — leave them blank to keep the stored value, or enter a new value to replace it.
Storage types​
Select your storage provider:
Google Cloud Storage
Amazon S3
Azure Blob Storage
Fields
- Bucket (required) - The name of the GCS bucket Accelerator will read from and write to.
- Path - An optional folder path within the bucket.
- Credentials (required) - The GCP service account credentials used to authenticate to the bucket. Paste the full contents of the service account's JSON key file.
Setting up in Google Cloud
Complete these steps in the Google Cloud Console before creating the file storage in Accelerator:
-
Create a bucket (or choose an existing one): go to Cloud Storage > Buckets > Create. The default bucket settings work — in particular, keep uniform bucket-level access enabled (Accelerator never sets per-object ACLs). Note the bucket name — you'll enter it in the Bucket field.
-
Create a dedicated service account: go to IAM & Admin > Service Accounts > Create Service Account. Give it a recognizable name such as
messagegears-file-storage. -
Grant the service account access to the bucket: on the bucket's Permissions tab, click Grant Access, add the service account as a principal, and assign the Storage Object Admin (
roles/storage.objectAdmin) role. This grants the object read, write, list, and delete permissions Accelerator needs, scoped to that bucket only.If you prefer a custom role, it must include these permissions:
storage.objects.get,storage.objects.create,storage.objects.list, andstorage.objects.delete. -
Create a JSON key for the service account: on the service account's Keys tab, click Add Key > Create new key > JSON, and download the key file. Paste the entire contents of this file into the Credentials field in Accelerator.
You should now have everything the Accelerator form asks for:
| Accelerator field | Where it comes from |
|---|---|
| Bucket | The bucket name from step 1 |
| Path | Optional — a folder within the bucket, if you want Accelerator confined to one |
| Credentials | The full contents of the JSON key file from step 4 |
Treat the JSON key file like a password — it grants access to your bucket. Share it only through a secure channel and delete downloaded copies once the file storage is configured.
Fields
- AWS Key (required) - The AWS access key ID used to authenticate to the bucket.
- AWS Secret (required) - The AWS secret access key paired with the AWS Key above.
- Bucket (required) - The name of the S3 bucket Accelerator will read from and write to.
- Path - An optional folder path within the bucket.
- Region (required) - The AWS region the bucket is hosted in (for example,
us-east-1).
Setting up in AWS
Complete these steps in the AWS Console before creating the file storage in Accelerator:
-
Create a bucket (or choose an existing one): go to S3 > Create bucket. The default bucket settings work, including ACLs disabled (bucket owner enforced) and Block Public Access turned on. Note the bucket name and its AWS region — you'll enter both in Accelerator.
-
Create a dedicated IAM user: go to IAM > Users > Create user. Give it a recognizable name such as
messagegears-file-storage. The user needs programmatic access only — no console access. -
Attach a least-privilege policy granting access to the bucket:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": "arn:aws:s3:::YOUR_BUCKET_NAME"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:PutObjectAcl",
"s3:DeleteObject",
"s3:AbortMultipartUpload"
],
"Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/*"
}
]
}Accelerator uploads files using multipart uploads and sets the
bucket-owner-full-controlACL on each upload, which is whys3:PutObjectAclands3:AbortMultipartUploadare included. If you restrict access to a folder path, scope the second statement's resource to that prefix (for example,arn:aws:s3:::YOUR_BUCKET_NAME/messagegears/*) and match it to the Path field. -
Create an access key: on the user's Security credentials tab, click Create access key. Enter the access key ID in the AWS Key field and the secret access key in the AWS Secret field.
You should now have everything the Accelerator form asks for:
| Accelerator field | Where it comes from |
|---|---|
| AWS Key | The access key ID from step 4 |
| AWS Secret | The secret access key from step 4 |
| Bucket | The bucket name from step 1 |
| Path | Optional — a folder within the bucket, matching any prefix restriction in your policy |
| Region | The bucket's AWS region from step 1 |
S3 file storage authenticates with an access key pair. IAM role assumption (a role ARN) and custom endpoints are not supported for this connection type.
Accelerator uploads files in multipart chunks. As a housekeeping best practice, we recommend adding a bucket lifecycle rule that deletes incomplete multipart uploads after 7 days (S3 > your bucket > Management > Create lifecycle rule) — a standard rule for any bucket that receives multipart uploads. This rule only removes leftover parts from uploads that never finished; it doesn't touch completed files, which Accelerator manages itself (see the retention note above).
Azure Blob Storage was added as a file storage type in Accelerator 26.1.1.
Azure Blob Storage supports two authentication methods, toggled via checkbox: Use Account Key or Use AAD Authentication. Only one can be selected at a time.
Fields (both methods)
- Container (required) - The name of the Azure Blob container Accelerator will read from and write to.
- Path - An optional folder path within the container.
- Account Name (required) - The name of the Azure Storage account that owns the container.
Use Account Key
- Account Key (required) - The Azure Storage account's shared access key, or a SAS token (see below).
Use AAD Authentication
Authenticates using an Azure Active Directory (AAD) service principal instead of a shared account key.
- Tenant ID (required) - The Azure AD tenant ID associated with the service principal.
- Client ID (required) - The application (client) ID of the registered Azure AD service principal.
- Client Secret (required) - The client secret generated for the Azure AD service principal.
Setting up in Azure
Complete these steps in the Azure Portal before creating the file storage in Accelerator:
- Create a storage account (or choose an existing one): go to Storage accounts > Create. The storage account name is what you'll enter in the Account Name field.
- Create a container in the storage account: on the storage account page, go to Data storage > Containers > + Container. The container name is what you'll enter in the Container field.
- Choose an authentication method and complete the matching steps below.
Option 1: Account key
On the storage account page, go to Security + networking > Access keys, click Show next to key1, and copy the Key value into the Account Key field in Accelerator. An account key grants full access to the storage account's data, so prefer AAD authentication (Option 2) if your security policies call for scoped, revocable access.
Option 2: AAD service principal
- Register an application: in Microsoft Entra ID (Azure Active Directory), go to App registrations > New registration. After registering, copy the Directory (tenant) ID and Application (client) ID from the app's Overview page — these are the Tenant ID and Client ID fields in Accelerator.
- Create a client secret: on the app registration's Certificates & secrets tab, click New client secret and copy the secret's Value (not the Secret ID) into the Client Secret field. The value is only shown once, immediately after creation.
- Grant the app access to the container: on the storage account (or container) page, go to Access Control (IAM) > Add role assignment, select the Storage Blob Data Contributor role, and assign it to the registered application. This grants the blob read, write, list, and delete permissions Accelerator needs. Accelerator only ever operates inside the one container, so scoping the assignment to the container is sufficient if you prefer the tighter grant.
You should now have everything the Accelerator form asks for:
| Accelerator field | Where it comes from |
|---|---|
| Container | The container name from step 2 (of Setting up in Azure) |
| Path | Optional — a folder within the container |
| Account Name | The storage account name from step 1 (of Setting up in Azure) |
| Account Key (Option 1) | Access keys > key1 > Key |
| Tenant ID / Client ID (Option 2) | The app registration's Overview page |
| Client Secret (Option 2) | The secret Value from Certificates & secrets |
Client secrets expire (180 days by default when created in the portal). Track the expiration date and rotate the secret in both Azure and Accelerator before it lapses, or the file storage connection will stop working.
SAS tokens
A shared access signature (SAS) token can be used in place of the account key: paste the SAS token into the Account Key field and Accelerator will detect and use it automatically. Generate it either way:
- Scoped to the one container (recommended): on the container's Settings > Shared access tokens page, with at minimum the Read, Create, Write, Delete, and List permissions.
- Account-level: on the storage account under Security + networking > Shared access signature, with the Blob service, Container and Object resource types, and the same permissions as above.
Note that SAS tokens have an expiry date — the connection will stop working when the token lapses, so track the expiration and plan to rotate it.
Azure Blob Storage file storage connects to the Azure public cloud (*.blob.core.windows.net). Azure Government, Azure China, and custom endpoints are not supported.
Troubleshooting
- Test Connection fails with a 403 /
AuthorizationFailure- The credential is being rejected. For account keys, confirm the key was copied in full with no whitespace. For SAS tokens, confirm the token hasn't expired and includes the Blob service, Container + Object resource types, and read/write/list/delete/create permissions. For AAD, confirm the role assignment has finished propagating (this can take a few minutes after assignment). - Test Connection fails but the credentials are correct - Check whether the storage account's Networking settings restrict access to selected networks. Accelerator's egress IPs must be allowed.
- Test Connection succeeds at first but fails after some time - Client secrets and SAS tokens expire. Generate a new one and update the file storage configuration.