Home / Tutorials / Configure Cloud Storage

Configure Cloud Storage for Backup & Restore

Set up AWS S3 or Azure Blob storage so Quemsi can back up in one environment and restore in another—cloud object storage is reachable over the internet from every agent you run.

Why Use Cloud Storage?

Local disk storage works well for a single host or demo. It fails as soon as you need agents in different environments to share the same backup packages.

Why cloud object storage matters

  • Cross-environment access: Agents in production, UAT, and development can all reach the same bucket or container over the internet.
  • Backup here, restore there: Take a snapshot in one environment and restore it into another without copying files by hand.
  • You keep control: Credentials stay with your company setup; the Quemsi agent reads and writes your storage directly—data does not pass through Quemsi SaaS.
  • Local still valid: Use local disk for single-machine demos. Choose cloud storage when multiple environments must share backups.

Supported providers today

Quemsi currently supports AWS S3 and Azure Blob Storage. Additional providers (for example Google Cloud Storage) may be added later. Pick either supported option—one shared cloud target is enough for cross-environment backup and restore.

Quick Navigation

Configure AWS S3 Drive

A drive holds credentials and the cloud location. Flows do not use the drive directly—you bind it into a Storage in the next section.

Prerequisites

  • An S3 bucket (or permission for the agent to create/access one)
  • An IAM user or role with Access Key ID and Secret Access Key that can read and write the bucket
  • At least one Quemsi agent online (required for Test connection)
1

Open AWS S3 Drives

In the Quemsi console, go to Company Setup → AWS S3 Drives, then click Add AWS S3 Drive.

Direct path: /setup/awss3drives/add

2

Fill in the drive fields

Match the labels in the form:

  • Name* — URL-friendly id (A-Z, a-z, 0-9, -, _). Immutable after create.
  • Title* — Display name shown in the UI.
  • Storage Root* — Key prefix inside the bucket (for example quemsi or backups/prod). Quemsi stores packages under this prefix.
  • Capacity* — Soft limit in the UI, e.g. 10 GB or 500 MB.
  • Access Key* — AWS Access Key ID (or env var name if using environment variables).
  • Secret Key* — AWS Secret Access Key (or env var name).
  • Region* — e.g. us-east-1, eu-west-1.
  • Bucket Name* — Target S3 bucket name.

Use environment variable

Enable Use environment variable to avoid storing secrets in the console. When enabled, put environment variable names in both Access Key and Secret Key (for example AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY). The agent resolves both from its process environment.

3

Test connection, then Save

Click Test connection with an online agent. Quemsi verifies bucket access (for example via a head-bucket check). When the test succeeds, click Save.

AWS S3 Drive ready

Your company-scoped S3 drive is saved. Continue to Create a Storage so backup and restore flows can use it.

Configure Azure Blob Drive

Same two-layer model as S3: the drive holds credentials; a Storage points at the drive for use in flows.

Prerequisites

  • An Azure Storage Account
  • The account name and an account key (or an env var that holds the key on the agent)
  • At least one Quemsi agent online for Test connection
1

Open Azure Blob Drives

In the Quemsi console, go to Company Setup → Azure Blob Drives, then click Add Azure Blob Drive.

Direct path: /setup/azureblobdrives/add

2

Fill in the drive fields

  • Name* — URL-friendly id; immutable after create.
  • Title* — Display name.
  • Storage Root* — Treated as the blob container name (created if missing). Use a simple container name such as quemsi-backups, not a nested path.
  • Capacity* — Soft limit, e.g. 10 GB.
  • Account Name* — Azure Storage Account name (always the real account name; builds https://{account}.blob.core.windows.net).
  • Account Key* — Storage account key, or an environment variable name when the checkbox is enabled.

Use environment variable

When Use environment variable is enabled, only Account Key is treated as an env var name (for example AZURE_STORAGE_KEY). Account Name stays the literal storage account name.

Storage Root vs path

The form may describe Storage Root as a directory path. For Azure Blob drives, enter the container name. Path segments under that container are set later as the Storage Root Path.

3

Test connection, then Save

Click Test connection with an online agent, then Save when the test succeeds.

Azure Blob Drive ready

Your company-scoped Azure drive is saved. Continue to Create a Storage so flows can target it.

Create a Storage from the Drive

Quemsi uses two layers:

Cloud storages are company-scoped, so every agent in the company can use the same Storage name for backup and restore.

1

Open Storages

Go to Agent Setup → Storages, then click Add Storage.

Direct path: /setup/storages/add

You can also create a drive from the Storage form via the + next to Drive; Quemsi returns you to the Storage form afterward.

2

Configure the Storage

  • Name* / Title* — Id and display name for the storage (flows reference the name).
  • Type* — Choose AWS S3 Storage or Azure Blob Storage.
  • Drive* — Select the drive you created above.
  • Root Path* — Path under the drive with no leading or trailing slash (for example prod-snapshots or shared/uat).
  • Retention* — noretention or default.
  • Size Limit* — e.g. 5 GB (required in the form; needed when retention is enabled).
3

Save

Click Save. Agents receive the updated model so the Storage is available in flow builders.

Storage ready for flows

You now have a cloud Storage name that any environment with an online agent can use to write backups and read restores.

Use Storage in Backup & Restore

This section is a short pointer—not a full flow tutorial. Once the Storage exists, wire it into flows by name.

1

Backup to cloud

In a backup (or snapshot) flow, set the destination to your Storage. The agent uploads versioned packages to S3 or Azure Blob using the drive credentials.

2

Restore from cloud

In a restore flow, use a Stored Data source that points at the same Storage name. An agent in another environment downloads the packages and restores into its local datasource.

Same Storage across environments

Because cloud drives and cloud storages are company-scoped and reachable over the internet, production can write a snapshot and development can restore it—without shared local disks or manual file copies.

For end-to-end workflows, continue with:

Best Practices

Least-privilege credentials

Grant only the bucket or container permissions Quemsi needs (list, read, write). Prefer a dedicated IAM user or Azure key scoped to that storage.

Prefer environment variables on agents

Keep secrets on the agent host (or orchestrator secrets) and store only variable names in the drive configuration when possible.

Always test with an online agent

Connection tests run on an agent. If no agent is online, save carefully and re-test once one connects.

Do not rely on local drives for multi-env

Local storages stay on one machine. Use AWS S3 or Azure Blob whenever you need backup in one environment and restore in another.

Ready to back up across environments?

Create your cloud drive and Storage, then run a backup in one environment and a restore in another using the same Storage name.

Get Started Free

Next Steps