Object Storage

An object storage resource is an S3 bucket owned by your organisation. Attach it to an environment and Quant Cloud creates a dedicated access key for that attachment and writes the connection details into the environment’s secrets.

Use it for anything your application needs to keep beyond the life of a container: user uploads, generated assets, exports, or backups.

Creating a bucket

Open Cloud → Resources and choose Create Resource, with Object storage as the type. Names must start with a lowercase letter or number and contain only lowercase letters, numbers and hyphens, between 2 and 41 characters.

You can also create a bucket in the Resources section of any application creation wizard. It is created in your organisation and attached to the new application’s production environment once that environment exists. See About Shared Resources.

Wait for the resource to finish provisioning before you attach it from the Resources page. The creation wizard handles this wait for you.

Attaching it to an environment

Expand the resource on Cloud → Resources, pick the application and environment, and optionally set an environment variable prefix. You can also attach from the Resources card on an application’s Environments page, or during application creation.

On attach, Quant Cloud creates an IAM user for that attachment, generates an access key for it, and writes five variables into the environment’s secrets:

Variable	Contents
S3_ENDPOINT	The S3 endpoint, https://s3.<region>.amazonaws.com
S3_REGION	The bucket’s region
S3_BUCKET	The bucket name
S3_ACCESS_KEY_ID	Access key for this attachment
S3_SECRET_ACCESS_KEY	Secret key for this attachment

With a prefix of MEDIA, these become MEDIA_S3_ENDPOINT, MEDIA_S3_BUCKET and so on.

What the credentials can do

Each attachment has its own IAM user and key, and the key is scoped to the bucket: it can list the bucket and read, write and delete objects anywhere in it. It cannot see any other bucket. Because the scope is the whole bucket, every environment attached to the same resource sees the same objects, so if two applications share a bucket they must agree on the key layout, for example by writing under a per-application top-level folder.

Revoking one environment’s access does not affect any other environment using the same bucket, because each attachment’s key is separate.

Connecting your application

The variables follow the names most S3 client libraries expect, so in many cases the configuration is direct. The endpoint is the standard regional AWS endpoint, so virtual-hosted addressing works and you do not need to force path-style requests.

// PHP, using the AWS SDK
$client = new Aws\S3\S3Client([
    'version'  => 'latest',
    'region'   => getenv('S3_REGION'),
    'endpoint' => getenv('S3_ENDPOINT'),
    'credentials' => [
        'key'    => getenv('S3_ACCESS_KEY_ID'),
        'secret' => getenv('S3_SECRET_ACCESS_KEY'),
    ],
]);

# Drupal, in settings.php via the s3fs module
$settings['s3fs.access_key'] = getenv('S3_ACCESS_KEY_ID');
$settings['s3fs.secret_key'] = getenv('S3_SECRET_ACCESS_KEY');
$config['s3fs.settings']['bucket'] = getenv('S3_BUCKET');
$config['s3fs.settings']['region'] = getenv('S3_REGION');

If you set a prefix when attaching, read the prefixed names instead.

When the credentials take effect

The secrets are written as soon as you attach, but a running container only sees them on its next deploy, so redeploy the environment once you have attached the bucket. For an attachment made during application creation, the initial deployment picks the secrets up and no extra step is needed.

Removing access

Detaching deletes the attachment’s IAM user and access key, then redeploys the environment so it stops referencing secrets that no longer exist. The environment is briefly interrupted during that deploy.

The bucket and its contents are untouched by a detach. Deleting the resource is what removes the data, and that cannot be undone.