Wie lautet die Endpoint-URL von Civo Object Storage?

Civo-Object-Store-Endpoints folgen dem Muster https://objectstore. .civo.com mit dem Regionscode in Kleinbuchstaben, zum Beispiel https://objectstore.lon1.civo.com in London oder https://objectstore.fra1.civo.com in Frankfurt. Der Endpoint hängt an der Region, in der der Store angelegt wurde. Jeder Store zeigt seinen Endpoint außerdem im Civo-Dashboard und liefert ihn im Feld objectstore_endpoint der Civo REST API.

Kann ich s3cmd oder rclone mit Civo Object Storage nutzen?

Ja, beides funktioniert, und die AWS CLI und jeder andere S3-kompatible Client ebenso. Für s3cmd setzt du host_base und host_bucket in ~/.s3cfg auf den regionalen Hostnamen, etwa objectstore.fra1.civo.com, und trägst access_key und secret_key ein. Für rclone legst du ein Remote mit type = s3, provider = Other, endpoint = https://objectstore.fra1.civo.com und demselben Schlüsselpaar an. Für die AWS CLI hängst du --endpoint-url https://objectstore.fra1.civo.com an jeden Befehl.

Warum funktioniert mein Civo-Object-Storage-Access-Key nicht?

Meistens liegt es an der Region. Civo schreibt, dass Object Stores regionsspezifisch sind und Zugangsdaten an der Region hängen, in der sie erzeugt wurden. Ein Key aus FRA1 authentifiziert sich also nicht gegen den LON1-Endpoint, obwohl er zum selben Account gehört. Leg die Zugangsdaten an, während das Dashboard auf der Region des Stores steht. Der zweithäufigste Grund ist ein Client, der den Endpoint nie bekommen hat, oder ein host_bucket in s3cmd, das auf dem Default steht, sodass die Anfrage bei Amazon statt bei Civo landet.

Gibt es eine GUI für Civo Object Storage auf dem Mac?

CivoCloudManager ist eine native macOS-App, macOS 15 oder neuer, im Mac App Store, und sie kennt Civo: Endpoint und Access Keys jedes Stores liest sie aus der Civo-API, es gibt also nichts zu konfigurieren. Sie navigiert mit Breadcrumbs und lädt einzelne Dateien, eine Mehrfachauswahl oder einen ganzen Ordner rekursiv herunter, während Uploads und Löschungen bei der CLI bleiben. Generische S3-Clients wie Cyberduck oder Transmit verbinden sich ebenfalls mit Civo, sobald du den Endpoint eintippst und pro Store beide Keys einfügst.

Was macht Pause mit meinen Daten in einem Civo Object Store?

Pause kopiert jedes Objekt in einen zentralen Object Store namens civo-cloud-manager innerhalb deines eigenen Civo-Accounts, vergleicht die kopierten Keys und Größen mit der Quelle und löscht erst dann den Originalstore, damit er nichts mehr kostet. Resume legt den Store unter demselben Namen mit denselben Zugangsdaten neu an, kopiert die Objekte zurück und prüft Keys und Größen erneut, bevor der Vault geräumt wird. Die Daten verlassen deinen Civo-Account nie, und die Prüfung läuft über Name und Größe, nicht über einen Hash des Inhalts.

Civo Object Storage am Mac per S3 durchsehen.

Der regionale Endpoint, funktionierende Konfiguration für s3cmd, rclone und die AWS CLI, und was ein nativer Client anders macht.

Civo Object Storage spricht S3, also kommt fast jeder S3-Client damit klar, sobald zwei Dinge stimmen: der Endpoint der Region, in der der Store liegt, und Zugangsdaten aus genau dieser Region. Civos eigene Doku führt durch s3cmd und überlässt dir den Rest der Werkzeuge. Diese Seite liefert die rohe Konfiguration für s3cmd, rclone und die AWS CLI und zeigt danach den Weg von CivoCloudManager, das Endpoint und Access Keys direkt aus der Civo-API liest, sodass es nichts von Hand einzutragen gibt.

Einen S3-Client für Civo einrichten

01

Endpoint deiner Region finden.

Civo baut Object-Store-Endpoints nach dem Muster https://objectstore.<region>.civo.com mit dem Regionscode in Kleinbuchstaben. Ein Store in London liegt also unter https://objectstore.lon1.civo.com, einer in Frankfurt unter https://objectstore.fra1.civo.com. Jeder Store zeigt seinen Endpoint außerdem im Civo-Dashboard und liefert ihn im Feld objectstore_endpoint der REST-API. Laut Civos Übersicht der Regions-Features gibt es Object Stores in LON1, FRA1, NYC1 und MUM1, nicht in PHX1.
02

Zugangsdaten in derselben Region anlegen.

Jeder Civo Object Store ist privat und braucht eine Access Key ID und einen Secret Key. Leg die Zugangsdaten im Civo-Dashboard unter Object Stores an, während der Regionswähler auf der Region des Stores steht, oder nimm die Civo CLI. Der Befehl civo objectstore credential export -a <access_key> gibt das Paar als AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_DEFAULT_REGION und AWS_HOST aus, fertig zum Einfügen in eine Shell.
03

s3cmd: host_base und host_bucket.

In ~/.s3cfg unter [default] setzt du host_base = objectstore.fra1.civo.com, host_bucket = objectstore.fra1.civo.com, bucket_location = fra1, use_https = True, signature_v2 = False, dazu access_key und secret_key. Derselbe Hostname in host_bucket wie in host_base hält s3cmd bei Path-Style-Adressierung, und darauf antwortet Civo. Danach listet s3cmd ls deine Stores, s3cmd ls s3://STORENAME einen einzelnen, s3cmd put file.tar s3://STORENAME/backups/ lädt hoch und s3cmd get -r s3://STORENAME/backups/ holt ein ganzes Präfix herunter. Ohne Config-Datei gehen dieselben zwei Werte als --host= und --host-bucket= auf die Kommandozeile.
04

rclone: ein Remote vom Typ s3, Provider Other.

rclone config starten und s3 wählen, oder den Block direkt in ~/.config/rclone/rclone.conf schreiben: unter [civo] setzt du type = s3, provider = Other, env_auth = false, access_key_id und secret_access_key aus den Zugangsdaten, region = fra1, endpoint = https://objectstore.fra1.civo.com und acl = private. Danach listet rclone lsd civo: die Stores, rclone ls civo:STORENAME die Objekte, rclone copy ./dir civo:STORENAME/dir -P schiebt einen Ordner mit Fortschrittsanzeige hoch und rclone ncdu civo:STORENAME gibt dir einen Browser im Textmodus. Dieselben Einstellungen funktionieren auch als einmalige Flags: --s3-provider Other --s3-endpoint https://objectstore.fra1.civo.com --s3-region fra1.
05

AWS CLI: --endpoint-url bei jedem Aufruf.

Die AWS CLI braucht kein Civo-Plugin, nur den Endpoint an jedem Befehl: aws s3 ls --endpoint-url https://objectstore.fra1.civo.com, dann aws s3 ls s3://STORENAME --endpoint-url ... und aws s3 cp file.tar s3://STORENAME/ --endpoint-url ... . Die Zugangsdaten kommen aus AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY oder aus einem benannten Profil, mit AWS_DEFAULT_REGION auf dem Civo-Regionscode, damit der Signature-V4-Scope passt. Eine Fußnote für neuere Versionen: ab AWS CLI 2.23 hängt an Uploads standardmäßig eine CRC64NVME-Prüfsumme, die nicht jeder S3-kompatible Endpoint akzeptiert. Scheitert ein Put mit einem Checksum-Fehler, setz AWS_REQUEST_CHECKSUM_CALCULATION=when_required und AWS_RESPONSE_CHECKSUM_VALIDATION=when_required.

Die Falle, die eine Stunde kostet: Keys hängen an einer Region

Civos Doku sagt es in zwei Sätzen, über die man leicht hinwegliest: Object Stores sind regionsspezifisch, und Zugangsdaten für Verwaltung und Zugriff hängen an der Region, in der sie erzeugt wurden. Ein Key, der entstand, während das Dashboard auf FRA1 stand, authentifiziert sich nicht gegen den LON1-Endpoint, obwohl es derselbe Account und dieselbe Abrechnung ist. Das Symptom ist ein Authentifizierungs- oder Signaturfehler, der wie ein Tippfehler im Secret aussieht, also erzeugt man den Key neu und bekommt einen zweiten Key in derselben falschen Region. Erst den Regionswähler prüfen, die Zugangsdaten neben dem Store anlegen und dann erst die Config verdächtigen.

Was die Kommandozeile nicht abdeckt

Für Skripte, Backups und CI sind s3cmd, rclone und die AWS CLI die richtige Antwort, und nichts hier ersetzt sie. Was sie nicht liefern, ist ein Blick in einen Store: ein Ordnerbaum, Größen auf einen Blick, eine Auswahl, die du herausziehen kannst. Generische Mac-S3-Clients wie Cyberduck oder Transmit füllen die Lücke, wissen aber nichts über Civo. Du trägst also den Endpoint ein, fügst pro Store beide Keys ein und hältst das bei jeder Rotation von Hand nach.

Der Weg der App: gar kein Endpoint zum Eintragen

CivoCloudManager meldet sich einmal mit deinem Civo API Key an und liest die Liste der Object Stores aus der Civo REST API v2, in der Endpoint und zugehörige Zugangsdaten pro Store schon drinstehen. Daraus baut die App den S3-Client, es gibt also kein Endpoint-Feld, kein Einfügen von Keys und keine Config-Datei. Die S3-Schicht ist schlichtes Swift: AWS Signature V4 mit CryptoKit-HMAC-SHA256, kein AWS-SDK und kein Electron. Die App macht ListObjects v2 mit Continuation Tokens, Breadcrumb-Navigation über Common Prefixes, Mehrfachauswahl und rekursiven Ordner-Download mit laufender Fortschrittszeile. Zur Form gehört die ehrliche Angabe: der Browser liest und lädt herunter. Uploads und Löschungen bleiben bei s3cmd oder rclone. Die App braucht macOS 15 oder neuer.

Access Keys hinter Touch ID statt in einer Dotfile

Das ist der Teil, der eine Installation wert ist, selbst wenn du bei der CLI bleibst. Ein funktionierendes s3cmd-Setup heißt, dass der Secret Key im Klartext in ~/.s3cfg steht, und dasselbe gilt für rclone.conf und ~/.aws/credentials. Jeder Prozess, der unter deinem Benutzer läuft, kann alle drei lesen, und alles, was durch dein Home-Verzeichnis läuft, ebenso. CivoCloudManager hält den Civo API Key im macOS Keychain, und wer einen Secret Access Key eines Object Stores in der Oberfläche sehen will, braucht vorher Touch ID oder das Systempasswort. Die Grenze ist offensichtlich und gehört gesagt: sobald du einen Key ins Terminal kopierst, liegt er wieder in einer Klartextdatei.

Pause und Resume für Stores, die du gerade nicht brauchst

Ein ungenutzter Store kostet weiterhin für seine zugewiesene Größe. Pause kopiert jedes Objekt in einen zentralen Object Store namens civo-cloud-manager, vergrößert diesen Vault vorher, wenn die Daten nicht hineinpassen, vergleicht die kopierten Keys und Größen mit der Quelle und löscht den Originalstore erst, wenn beides übereinstimmt. Der Posten verschwindet aus der Civo-Rechnung. Resume legt den Store unter demselben Namen mit denselben Zugangsdaten neu an, kopiert die Objekte zurück, prüft Keys und Größen erneut und räumt danach den Vault. Bis zu vier Objekte laufen gleichzeitig. Die ehrlichen Grenzen: die Prüfung vergleicht Namen und Größen und hasht keine Inhalte, Transfers puffern ganze Objekte im Speicher, und das Manifest im Vault wird erst nach dem Löschen der Quelle geschrieben, mit einem lokalen Manifest als Rückfall.

Welcher Client für welche Aufgabe

Alle vier sprechen dieselbe S3-API auf demselben Endpoint. Der Unterschied liegt darin, wo die Konfiguration steht, wo das Secret landet und was du sehen kannst.

Aufgabe	s3cmd	rclone	AWS CLI	CivoCloudManager
Endpoint-Konfiguration	host_base und host_bucket in ~/.s3cfg	endpoint im Remote	--endpoint-url bei jedem Aufruf	aus der Civo-API gelesen
Wo der Secret Key landet	~/.s3cfg, Klartext	rclone.conf, Klartext	~/.aws/credentials, Klartext	macOS Keychain, Touch ID zum Anzeigen
Store visuell durchsehen	nein	rclone ncdu, Textmodus	nein	ja, Datei-Browser mit Breadcrumbs
Objekte hochladen und löschen	ja	ja	ja	nicht im Browser
Rekursiver Ordner-Download	s3cmd get -r	rclone copy	aws s3 cp --recursive	ja, mit Fortschritt
Ungenutzten Store pausieren und sparen	nein	nein	nein	ja, Vault mit Prüfung vor dem Löschen
Läuft in CI	ja	ja	ja	nein, es ist eine Mac-App

Civo Object Storage per S3, beantwortet

Wie lautet die Endpoint-URL von Civo Object Storage?: Civo-Object-Store-Endpoints folgen dem Muster https://objectstore.<region>.civo.com mit dem Regionscode in Kleinbuchstaben, zum Beispiel https://objectstore.lon1.civo.com in London oder https://objectstore.fra1.civo.com in Frankfurt. Der Endpoint hängt an der Region, in der der Store angelegt wurde. Jeder Store zeigt seinen Endpoint außerdem im Civo-Dashboard und liefert ihn im Feld objectstore_endpoint der Civo REST API.
Kann ich s3cmd oder rclone mit Civo Object Storage nutzen?: Ja, beides funktioniert, und die AWS CLI und jeder andere S3-kompatible Client ebenso. Für s3cmd setzt du host_base und host_bucket in ~/.s3cfg auf den regionalen Hostnamen, etwa objectstore.fra1.civo.com, und trägst access_key und secret_key ein. Für rclone legst du ein Remote mit type = s3, provider = Other, endpoint = https://objectstore.fra1.civo.com und demselben Schlüsselpaar an. Für die AWS CLI hängst du --endpoint-url https://objectstore.fra1.civo.com an jeden Befehl.
Warum funktioniert mein Civo-Object-Storage-Access-Key nicht?: Meistens liegt es an der Region. Civo schreibt, dass Object Stores regionsspezifisch sind und Zugangsdaten an der Region hängen, in der sie erzeugt wurden. Ein Key aus FRA1 authentifiziert sich also nicht gegen den LON1-Endpoint, obwohl er zum selben Account gehört. Leg die Zugangsdaten an, während das Dashboard auf der Region des Stores steht. Der zweithäufigste Grund ist ein Client, der den Endpoint nie bekommen hat, oder ein host_bucket in s3cmd, das auf dem Default steht, sodass die Anfrage bei Amazon statt bei Civo landet.
Gibt es eine GUI für Civo Object Storage auf dem Mac?: CivoCloudManager ist eine native macOS-App, macOS 15 oder neuer, im Mac App Store, und sie kennt Civo: Endpoint und Access Keys jedes Stores liest sie aus der Civo-API, es gibt also nichts zu konfigurieren. Sie navigiert mit Breadcrumbs und lädt einzelne Dateien, eine Mehrfachauswahl oder einen ganzen Ordner rekursiv herunter, während Uploads und Löschungen bei der CLI bleiben. Generische S3-Clients wie Cyberduck oder Transmit verbinden sich ebenfalls mit Civo, sobald du den Endpoint eintippst und pro Store beide Keys einfügst.
Was macht Pause mit meinen Daten in einem Civo Object Store?: Pause kopiert jedes Objekt in einen zentralen Object Store namens civo-cloud-manager innerhalb deines eigenen Civo-Accounts, vergleicht die kopierten Keys und Größen mit der Quelle und löscht erst dann den Originalstore, damit er nichts mehr kostet. Resume legt den Store unter demselben Namen mit denselben Zugangsdaten neu an, kopiert die Objekte zurück und prüft Keys und Größen erneut, bevor der Vault geräumt wird. Die Daten verlassen deinen Civo-Account nie, und die Prüfung läuft über Name und Größe, nicht über einen Hash des Inhalts.

Anleitungen

Schritt für Schritt, und ehrliche Vergleiche.

Vertiefen

Eigene Seite pro Civo-Produkt.

Jede Civo-Fläche, die CivoCloudManager bedient, hat eine eigene Seite mit Details, Trade-offs und Architektur. Wähl die, die deinem Arbeitstag am nächsten kommt.

Spar dir die Endpoint-Konfiguration.

CivoCloudManager liest Endpoint und Access Keys aus deinem eigenen Civo-Account, der Store geht also auf, statt eine Config-Datei zu verlangen. Menüleisten-Tier kostenlos, das volle Dashboard als einmaliger Kauf im Mac App Store.

Im Mac App Store laden

Benötigt macOS 15 (Sequoia) oder neuer.

Zurück zur Startseite