About Shared Resources

Shared resources belong to your organisation rather than to any one application. You create a resource once, then attach it to as many application environments as you need, and Quant Cloud injects the connection details into each of those environments for you.

Two kinds of resource are available:

• Object storage, an S3 bucket for user uploads, generated files, backups, or anything else your application needs to keep outside its container filesystem.
• Managed caches, an organisation-scoped Valkey cache that several applications can share.

You will find them under Cloud → Resources in the dashboard, and you can also create or attach them while creating an application.

Why resources are separate from applications

A container filesystem does not survive a deploy, and every environment gets its own. Anything you want to keep, or to share between environments, has to live somewhere else. Persistent volumes solve part of this for a single environment, and shared resources solve the rest by giving you storage and caching that sit outside any application entirely.

This also means a resource outlives the applications using it. Deleting an environment does not delete the bucket its files are in.

Creating a resource

Open Cloud → Resources, choose Create Resource, and give it a name. Names must start with a lowercase letter or number and contain only lowercase letters, numbers and hyphens, between 2 and 41 characters.

For a managed cache you also choose a storage cap between 1 and 50 GB, which is the maximum amount of data the cache will hold. The cap cannot be changed after creation.

Provisioning takes a few minutes. A resource has to finish provisioning before you can attach it. The Resources page shows the status, and an attach request against a resource that is still provisioning is refused.

Adding resources while creating an application

Every application creation path (starter kit, pre-built app, GitHub import and manual configuration) has a Resources section. For each resource type you choose one of:

• Not needed, the default.
• Create a new resource, where you give the resource a name (and a storage cap for a cache). The resource is created in your organisation and attached to the new application’s production environment.
• Attach an existing resource, where you pick one of the organisation’s resources. This option is disabled when the organisation has none of that type yet.

Some starter kits recommend a cache or object storage. When a kit does, the wizard pre-selects Attach an existing resource if your organisation already has one of that type, and Create a new resource if it does not. You can change either choice.

The attachment happens as a step of the deployment, shown as Provisioning Resources on the progress screen. The production environment is created asynchronously, so this step waits for it, usually a few minutes for an application with a managed database, before it attaches. A resource created here is an ordinary organisation resource and appears under Cloud → Resources like any other.

Attaching a resource to an environment

You can attach from two places.

On Cloud → Resources, expand a resource and choose the application and environment you want to connect. This is the place to attach one resource to several environments at once.

On an application’s Environments page, the Resources card lists the organisation resources attached to each of that application’s environments, with a Detach button on each, and an attach form where you pick a resource and an environment. This is the place to see everything one application uses.

You can attach the same resource to as many environments as you like, including environments in different applications. Each environment can have one attachment per resource type. An environment can use one bucket and one cache at the same time, but not two buckets.

Naming the injected variables

When you attach a resource from Cloud → Resources you can set an optional environment variable prefix. Without one, an object storage attachment injects S3_BUCKET; with a prefix of MEDIA it injects MEDIA_S3_BUCKET instead.

Use a prefix when an environment already sets variables of the same name, or when you want the purpose of the resource to be obvious in your configuration. The prefix applies to every variable the attachment injects, including the credentials, so a prefixed cache attachment produces MEDIA_REDIS_USER rather than REDIS_USER.

Attachments made during application creation or from the Environments page use the unprefixed names.

Detaching

Detaching removes the credentials from the environment and then redeploys it so that the stale references are dropped. The environment is briefly interrupted while that deploy runs, so detach at a time when a short outage is acceptable.

Detaching does not delete the resource or its contents. The bucket and everything in it stays until you delete the resource itself.

Permissions

Viewing resources requires the browse_content permission. Creating and attaching them requires write_applications, and deleting them requires delete_applications. The Resources page is part of Quant Cloud, so it needs a Teams Lite subscription or higher, an active trial, or an administrator override.