What is the Civo object storage endpoint URL?

Civo object store endpoints follow the pattern https://objectstore. .civo.com with the region code in lowercase, for example https://objectstore.lon1.civo.com in London or https://objectstore.fra1.civo.com in Frankfurt. The endpoint depends on the region the store was created in. Every store also shows its own endpoint in the Civo dashboard and returns it in the objectstore_endpoint field of the Civo REST API.

Can I use s3cmd or rclone with Civo Object Storage?

Yes, both work, and so do the AWS CLI and any other S3 compatible client. For s3cmd, set host_base and host_bucket in ~/.s3cfg to the regional hostname such as objectstore.fra1.civo.com and fill in access_key and secret_key. For rclone, create a remote with type = s3, provider = Other, endpoint = https://objectstore.fra1.civo.com and the same key pair. For the AWS CLI, pass --endpoint-url https://objectstore.fra1.civo.com on each command.

Why does my Civo object storage access key not work?

The usual cause is the region. Civo states that object stores are region specific and that credentials are tied to the region where they were created, so a key created in FRA1 will not authenticate against the LON1 endpoint even though it belongs to the same account. Create the credential while the dashboard is set to the store's region. The second common cause is a client that never received the endpoint, or an s3cmd host_bucket left at its default, so the request goes to Amazon instead of Civo.

Is there a GUI for Civo object storage on a Mac?

CivoCloudManager is a native macOS app, macOS 15 or later, on the Mac App Store, and it is Civo aware: it reads the endpoint and the access keys for each store from the Civo API, so there is nothing to configure. It browses with breadcrumbs and downloads single files, a multi-selection or a whole folder recursively, while uploads and deletions stay with the CLI. Generic S3 clients such as Cyberduck or Transmit also connect to Civo once you type the endpoint and paste both keys per store.

What does Pause do to my data in a Civo object store?

Pause copies every object into a central object store called civo-cloud-manager inside your own Civo account, compares the copied keys and sizes against the source, and only then deletes the original store so it stops costing. Resume recreates the store under the same name with the same credential, copies the objects back and verifies keys and sizes again before clearing the vault. The data never leaves your Civo account, and the verification is by name and size rather than a content hash.

Browse Civo Object Storage over S3 on macOS.

The regional endpoint, working configuration for s3cmd, rclone and the AWS CLI, and what a native client does differently.

Civo Object Storage speaks S3, so almost any S3 client can talk to it once two things are right: the endpoint of the region the store lives in, and a credential created in that same region. Civo's own documentation walks through s3cmd and leaves the rest of the tooling to you. This page gives the raw configuration for s3cmd, rclone and the AWS CLI, then shows the path CivoCloudManager takes, which is to read the endpoint and the access keys straight out of the Civo API so there is nothing to configure by hand.

Configuring an S3 client for Civo

01

Find the endpoint for your region.

Civo builds object store endpoints as https://objectstore.<region>.civo.com with the region code in lowercase, so a store in London is reached at https://objectstore.lon1.civo.com and one in Frankfurt at https://objectstore.fra1.civo.com. Each store also prints its own endpoint in the Civo dashboard and returns it in the objectstore_endpoint field of the REST API. Per Civo's region feature overview, object stores are available in LON1, FRA1, NYC1 and MUM1, and not in PHX1.
02

Create a credential in that same region.

Every Civo object store is private and needs an access key ID and a secret key. Create the credential in the Civo dashboard under Object Stores while the region selector is set to the store's region, or with the Civo CLI. The command civo objectstore credential export -a <access_key> prints the pair as AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_DEFAULT_REGION and AWS_HOST, ready to paste into a shell.
03

s3cmd: host_base and host_bucket.

In ~/.s3cfg, under [default], set host_base = objectstore.fra1.civo.com, host_bucket = objectstore.fra1.civo.com, bucket_location = fra1, use_https = True, signature_v2 = False, plus access_key and secret_key. Giving host_bucket the same hostname as host_base keeps s3cmd on path style addressing, which is what Civo answers on. Then s3cmd ls lists your stores, s3cmd ls s3://STORENAME lists one, s3cmd put file.tar s3://STORENAME/backups/ uploads, and s3cmd get -r s3://STORENAME/backups/ pulls a whole prefix down. Without a config file the same two values go on the command line as --host= and --host-bucket=.
04

rclone: a remote of type s3, provider Other.

Run rclone config and pick s3, or write the block into ~/.config/rclone/rclone.conf directly: under [civo] set type = s3, provider = Other, env_auth = false, access_key_id and secret_access_key from the credential, region = fra1, endpoint = https://objectstore.fra1.civo.com and acl = private. After that rclone lsd civo: lists stores, rclone ls civo:STORENAME lists objects, rclone copy ./dir civo:STORENAME/dir -P syncs a folder up with progress, and rclone ncdu civo:STORENAME gives a text mode browser. The same settings work as one-off flags: --s3-provider Other --s3-endpoint https://objectstore.fra1.civo.com --s3-region fra1.
05

AWS CLI: --endpoint-url on every call.

The AWS CLI needs no Civo specific plugin, only the endpoint on each command: aws s3 ls --endpoint-url https://objectstore.fra1.civo.com, then aws s3 ls s3://STORENAME --endpoint-url ... and aws s3 cp file.tar s3://STORENAME/ --endpoint-url ... . Credentials come from AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY or a named profile, with AWS_DEFAULT_REGION set to the Civo region code so the Signature V4 scope matches. One footnote for recent versions: AWS CLI 2.23 and later adds a CRC64NVME checksum to uploads by default, which not every S3 compatible endpoint accepts, so if a put fails with a checksum error set AWS_REQUEST_CHECKSUM_CALCULATION=when_required and AWS_RESPONSE_CHECKSUM_VALIDATION=when_required.

The trap that costs an hour: keys are bound to one region

Civo's documentation is explicit about it in two sentences that are easy to skim past: object stores are region specific, and credentials to manage and access object stores are tied to the region where they were created. A key made while the dashboard sat on FRA1 will not authenticate against the LON1 endpoint, even though it is the same account and the same billing. The symptom is an authentication or signature error that looks like a typo in the secret, so the natural reaction is to regenerate the key, which produces another key in the same wrong region. Check the region selector first, create the credential next to the store, and only then suspect the config.

What the command line does not cover

For scripting, backups and CI, s3cmd, rclone and the AWS CLI are the right answer and nothing here replaces them. What they do not give you is a look at a store: a folder tree, sizes at a glance, a selection you can drag out. Generic Mac S3 clients such as Cyberduck or Transmit fill that gap, but they know nothing about Civo, so you enter the endpoint, paste both keys per store and keep them in sync by hand every time a credential rotates.

The app path: no endpoint to enter at all

CivoCloudManager authenticates once with your Civo API key and reads the object store list from the Civo REST API v2, which already carries the endpoint and the linked credential for each store. It builds the S3 client from that, so there is no endpoint field, no key pasting and no config file. The S3 layer is plain Swift: AWS Signature V4 computed with CryptoKit HMAC-SHA256, no AWS SDK and no Electron. It does ListObjects v2 with continuation tokens, breadcrumb navigation over common prefixes, multi-select, and recursive folder download with a running progress line. Being honest about the shape of it: the browser reads and downloads. Uploads and deletions still belong to s3cmd or rclone. The app needs macOS 15 or later.

Access keys behind Touch ID instead of a dotfile

This is the part that is worth an install even if you keep the CLI. A working s3cmd setup means the secret key sits in ~/.s3cfg in plaintext, and the same is true for rclone.conf and ~/.aws/credentials. Any process running as your user can read all three, and so can anything that walks your home directory. CivoCloudManager keeps the Civo API key in the macOS Keychain, and revealing an object store secret access key in the interface requires Touch ID or the system password first. The limit is obvious and worth stating: the moment you copy a key out into a terminal, it is a plaintext file again.

Pause and Resume for stores you are not using

An idle store still bills for its allocated size. Pause copies every object into a central object store named civo-cloud-manager, growing that vault first if the data does not fit, compares the copied keys and sizes against the source, and only deletes the original store when they match. The line item disappears from the Civo bill. Resume recreates the store under the same name with the same credential, copies the objects back, verifies keys and sizes again, then clears the vault. Up to four objects move at a time. The honest limits: verification compares names and sizes rather than hashing content, transfers buffer whole objects in memory, and the remote manifest is written after the source is deleted, with a local manifest as the fallback.

Which client for which job

All four talk to the same S3 API on the same endpoint. The difference is where the configuration lives, where the secret ends up, and what you can see.

Task	s3cmd	rclone	AWS CLI	CivoCloudManager
Endpoint configuration	host_base and host_bucket in ~/.s3cfg	endpoint in the remote	--endpoint-url on every call	read from the Civo API
Where the secret key ends up	~/.s3cfg, plaintext	rclone.conf, plaintext	~/.aws/credentials, plaintext	macOS Keychain, Touch ID to reveal
Browsing a store visually	no	rclone ncdu, text mode	no	yes, breadcrumb file browser
Upload and delete objects	yes	yes	yes	not in the browser
Recursive folder download	s3cmd get -r	rclone copy	aws s3 cp --recursive	yes, with progress
Pause an idle store to stop paying	no	no	no	yes, vault with verify before delete
Runs in CI	yes	yes	yes	no, it is a Mac app

Civo Object Storage over S3, answered

What is the Civo object storage endpoint URL?: Civo object store endpoints follow the pattern https://objectstore.<region>.civo.com with the region code in lowercase, for example https://objectstore.lon1.civo.com in London or https://objectstore.fra1.civo.com in Frankfurt. The endpoint depends on the region the store was created in. Every store also shows its own endpoint in the Civo dashboard and returns it in the objectstore_endpoint field of the Civo REST API.
Can I use s3cmd or rclone with Civo Object Storage?: Yes, both work, and so do the AWS CLI and any other S3 compatible client. For s3cmd, set host_base and host_bucket in ~/.s3cfg to the regional hostname such as objectstore.fra1.civo.com and fill in access_key and secret_key. For rclone, create a remote with type = s3, provider = Other, endpoint = https://objectstore.fra1.civo.com and the same key pair. For the AWS CLI, pass --endpoint-url https://objectstore.fra1.civo.com on each command.
Why does my Civo object storage access key not work?: The usual cause is the region. Civo states that object stores are region specific and that credentials are tied to the region where they were created, so a key created in FRA1 will not authenticate against the LON1 endpoint even though it belongs to the same account. Create the credential while the dashboard is set to the store's region. The second common cause is a client that never received the endpoint, or an s3cmd host_bucket left at its default, so the request goes to Amazon instead of Civo.
Is there a GUI for Civo object storage on a Mac?: CivoCloudManager is a native macOS app, macOS 15 or later, on the Mac App Store, and it is Civo aware: it reads the endpoint and the access keys for each store from the Civo API, so there is nothing to configure. It browses with breadcrumbs and downloads single files, a multi-selection or a whole folder recursively, while uploads and deletions stay with the CLI. Generic S3 clients such as Cyberduck or Transmit also connect to Civo once you type the endpoint and paste both keys per store.
What does Pause do to my data in a Civo object store?: Pause copies every object into a central object store called civo-cloud-manager inside your own Civo account, compares the copied keys and sizes against the source, and only then deletes the original store so it stops costing. Resume recreates the store under the same name with the same credential, copies the objects back and verifies keys and sizes again before clearing the vault. The data never leaves your Civo account, and the verification is by name and size rather than a content hash.

Guides

Step by step, and honest comparisons.

Deep dives

Targeted reads for each Civo product.

Every Civo surface CivoCloudManager touches has its own page with the specifics, the trade-offs, and the architecture details. Pick the one closest to what you do today.

Skip the endpoint configuration.

CivoCloudManager reads the endpoint and the access keys from your own Civo account, so the store opens instead of needing a config file. Free menu-bar tier, one-time purchase for the full dashboard on the Mac App Store.

Download on the Mac App Store

Requires macOS 15 (Sequoia) or newer.

Back to the homepage