S3 OBJECT STORAGE - Hikube

Triple-replicated S3 buckets, hosted in Switzerland.

S3-compatible object storage, automatically replicated across 3 Swiss datacenters. Auto-generated credentials, single endpoint, compatible with all your existing tools.

Compatible
AWS CLI
boto3
mc
rclone
Velero
Restic
s3cmd

3 DC

Synchronous replication (Geneva - Gland - Lucerne)

S3 v4

Signature AWS full compatibility

1 YAML

Enough to create a bucket

0 config

Automatically generated credentials
How it works

One manifest, that's all

Just one object to declare for a fully operational bucket. Credentials, access and replication are automatically taken care of...

  • Single resource provisioning
    A single object to declare with a name. The bucket, credentials and accesses are created automatically.

  • Credentials isolated per bucket
    Each bucket has its own accessKeyID / accessSecretKey pair. No shared keys between buckets.

  • A single endpoint for all your buckets
    All buckets can be accessed via https://prod.s3.hikube.cloud. A single endpoint to configure in your tools.

  • Transparent triple replication
    Your data is automatically distributed across 3 Swiss datacenters. Zero data loss even in the event of a complete site failure.

  • HTTPS access only
    Encryption in transit on all accesses. No anonymous access, a valid key is always required.

Frame 11492

Automatic switchover

The loss of a complete datacenter means no loss of data and no downtime. Failover is transparent to your applications.
Quick start

A bucket ready in 5 minutes

Three steps: create the bucket with your users, retrieve the generated credentials, connect your S3 tool.

Declare a bucket and its users in YAML. Credentials are automatically generated for each user and linked to the bucket. Connect your usual S3 tool. Nothing else to configure.

  • Bucket and users declared together
    Each bucket is created with its users. Credentials are automatically generated and linked to each user in the bucket.

  • Credentials ready without configuration
    Credentials are generated automatically and accessible directly from your interface or tools.

  • Plug in your usual S3 tool
    AWS CLI, boto3, rclone, Velero. Point to prod.s3.hikube.cloud with your credentials. Zero code rewriting.

bash
 # Configure a dedicated profile
aws configure --profile hikube
# Access Key ID: $S3_ACCESS_KEY
# Secret Access Key: $S3_SECRET_KEY
# Region: (empty)
# Format: json

# Upload a file
aws s3 cp fichier.txt \
"s3://$BUCKET_NAME/file.txt" \
-- endpoint-url "$S3_ENDPOINT" \
--profile hikube

# List contents
aws s3 1s "s3://$BUCKET_NAME/" \
-- endpoint-url "$S3_ENDPOINT" \
--profile hikube

 

bash
# Configure an alias
mc alias set hikube \
"$S3_ENDPOINT" \
"$S3_ACCESS_KEY" \
"$S3_SECRET_KEY"

# Upload a file
mc cp fichier.txt \
"hikube/$BUCKET_NAME/"

# List contents
mc ls "hikube/$BUCKET_NAME/"

 

python
import boto3
import os

s3 = boto3.client(
"s3",
endpoint_url=os.environ["S3_ENDPOINT"],
aws_access_key_id=os. environ["S3_ACCESS_KEY"],
aws_secret_access_key=os. environ["$3_SECRET_KEY"],
)

bucket = os.environ["BUCKET_NAME"]

#Upload
s3. upload_file ("local.txt", bucket, "remote.txt")

#List objects
resp = s3.list_objects_v2(Bucket=bucket)
for obj in resp. get("Contents", []):
print(obj["Key"], obj["Size"])

Compatibility

Works with your existing tools

The Hikube endpoint is compatible with AWS S3 signature v4. No SDK or proprietary plug-in required. Configure your usual tool by pointing to https://prod.s3.hikube.cloud.

AWS CLI

Command-line file management. Dedicated profile with --endpoint-url.

mc (MinIO)

Versatile S3 client. Alias configured in one command.

rclone

Synchronization and data migration. Remote s3 with Minio provider.

Velero

Backups from Kubernetes clusters to S3 Hikube.

Restic

Backup of databases (PostgreSQL, MySQL, ClickHouse) to S3.

boto3

AWS Python SDK. Compatible without modification, simply point to the endpoint_url.

s3cmd

Alternative CLI S3. Configure host_base to the Hikube endpoint.

AWS SDKs

Go, Java, Node.js. All AWS S3 SDKs work natively.

Use cases

What teams store on Hikube

S3 object storage covers a wide spectrum of needs, from cluster backup to static assets and data pipelines.

BACKUP

Kubernetes backups with Velero

S3 destination for cluster backups and persistent volumes. One-click restore from a Hikube bucket.

Velero Restic
CI/CD

Artifacts and build images

Storage of container images, compiled binaries and GitOps artifacts between pipeline stages.

AWS CLI mc rclone
Web assets

Static files and media

Images, videos, PDFs and web assets served directly from S3. Compatible with CDNs and nginx proxies.

boto3 AWS SDK
Data

Data lake and analytical storage

Centralization of CSV, Parquet and JSON files for ETL, BI tools and S3-compatible analytical engines.

DuckDB Spark boto3
Logs

Long-term archiving

Application logs, audit logs and compliance archives continuously exported to S3 via Fluent Bit or Logstash.

Fluent Bit rclone
ML / AI

Datasets and model checkpoints

Storage of training datasets and model checkpoints accessible from Kubernetes GPU pods.

boto3 mc AWS SDK
Why S3 sovereign

Object storage without cloud dependency

S3 object storage has become a de facto standard for cloud-native applications: it decouples storage from compute, simplifies data sharing between services, and integrates natively into all modern pipelines. However, this dependency creates a real lock-in point: your data lives with an American hyperscaler, subject to its pricing policy and jurisdiction.

Hikube offers an S3-compatible alternative hosted in Switzerland, with the same level of integration: same protocol, same SDKs, same tools. Your applications don't notice the difference, but your data remains in Switzerland, under your control.

Triple replication on three independent Swiss sites guarantees the same durability as hyperscalers, with no configuration complexity. It's automatic and transparent from the moment the bucket is created.

markup-cropped (1)

Full S3 compatibility, zero rewriting

API compatible with AWS S3 signature v4. Your existing applications point to the Hikube endpoint without code modification.

markup-cropped (1)

Native Kubernetes integration

Bucket and credentials managed as Kubernetes resources. Auto-generated secrets, injectable directly into your pods.

markup-cropped (1)

Data in Switzerland, RGPD compliance

Infrastructure operated entirely in Switzerland. No transfers outside Europe.

markup-cropped (1)

Predictable pricing

No egress charges to your Hikube clusters. What you see is what you pay.

FAQ

Questions about S3 Object Storage

Do my AWS tools work without modification?

Yes, as long as you point to the Hikube endpoint and use the credentials of the generated Secret. The API is compatible with AWS S3 signature v4 - AWS CLI, boto3, rclone, Velero, Restic and all AWS SDKs work without code modification.

Why is bucketName different from metadata.name?

The metadata.name identifies the Kubernetes resource in your tenant. The bucketName in the Secret is the internal identifier generated in the SeaweedFS backend - it's a UUID that guarantees global uniqueness. Always use the Secret's spec.bucketName value for S3 operations, not the manifest name.

How do I inject credentials into a Kubernetes pod?

Secret bucket-<name> is automatically generated in your namespace. Reference it in your Deployment via envFrom or mount it as a volume. Never extract keys in plain text in your Git manifests or repositories - always use the Secret reference.

Is it possible to list all buckets from the endpoint?

No - a bucket's credentials give access only to that bucket. A command like mc ls hikube or aws s3 ls without a target bucket will return an AccessDenied error. Always target your bucket directly: mc ls hikube/$BUCKET_NAME/.

What happens if I delete the Bucket resource?

Deleting the Kubernetes resource permanently deletes the bucket and all the data it contains. This operation is irreversible - check your backups before proceeding. The associated Secret is also deleted.

How durable is the data?

Data is triple-replicated in 3 independent Swiss datacenters (Geneva, Gland, Lucerne). The complete loss of a datacenter does not result in data loss or service unavailability. Replication is synchronous and fully automatic - no configuration required on your side.