Overview

Xelon HQ Object Storage provides an S3-compatible API for storing and retrieving unstructured data. It is ideal for static assets, backups, logs, and any data that benefits from HTTP-based access. Objects are organized into buckets and accessed via standard S3 tooling and SDKs.

Creating an S3 User

Before you can create buckets or upload objects, you need an S3 user associated with your organization.

Region Selection

Each S3 user is bound to a specific region group at creation time:

• Single region — Data stays in one location.
• Replicated region — Data is automatically copied to a second region. Replicated regions cost exactly twice as much per GB as single regions.

Storage Quota Plans

The Storage Quota selector shows available plans as cards. Plans are managed centrally and may include any of the following sizes:

Each plan card shows the monthly price in CHF. Replicated regions show the doubled price. Quota applies per S3 user, uploads are blocked once the quota is reached, and billing is settled at the end of each month.

Generating Access Keys

Each S3 user requires access keys (an access key and a secret key) to authenticate API requests.

Managing Access Keys

You can manage existing keys from the Manage S3 Access Keys dialog:

• View keys: All active access keys are listed with their creation date.
• Delete a key: Click Delete next to any key and confirm with your password to revoke it. Applications using that key will immediately lose access.
• Rotate keys: Create a new key before deleting the old one to avoid downtime during key rotation.

Creating a Bucket

Bucket List Columns

The bucket list table includes an Object Lock column (showing Enabled or Disabled) and a Versioning column with a dropdown toggle that allows you to enable or disable versioning on existing buckets. The Versioning toggle is disabled when Object Lock is on (versioning is permanently enabled in that case).

IP Restrictions per Bucket

Restrict S3 access to a bucket so that only requests from approved IP addresses or CIDR ranges are allowed. All other requests are denied at the storage layer.

Browsing Buckets with the File Manager

The File Manager is a built-in web UI for working with bucket contents directly in the browser — no S3 client, AWS CLI, or third-party tool required. Use it for ad-hoc uploads, downloads, folder organization, or quickly verifying that an automation pipeline produced the expected files.

Opening the File Manager

1. Navigate to Virtual Datacenter > S3 Object Storage and open the Buckets tab.
2. Locate the bucket and open its action menu.
3. Click File Manager. The session is created on the fly and the browser opens directly inside the bucket root.

The modal title shows the bucket name ("File Manager — my-bucket"). Sessions are tied to the S3 user that owns the bucket.

Available Operations

Limits and Notes

• Same bucket only. Copy and move operations stay inside the current bucket. Cross-bucket copies require an S3 client (AWS CLI, mc, or your own integration).
• One bucket per session. The session token is bound to the S3 user that owns the bucket. To browse a bucket owned by a different S3 user, open File Manager from that bucket's action menu.
• IP restrictions block File Manager. Because requests are proxied by Xelon HQ, a bucket with active IP restrictions cannot be browsed via File Manager. The action item is disabled with a hint message in that case.
• Object Lock is respected. Files protected by an active retention period cannot be deleted; the operation will fail with the underlying S3 error.
• Browser-based uploads. Files travel through your browser. For large files (multi-GB), using aws s3 cp or mc is faster and more reliable than the browser uploader.

Deleting a Bucket

To delete a bucket, select it from the bucket list and click Delete. Confirm the deletion when prompted.

Connecting with S3 Tools

Configure the AWS CLI to work with Xelon Object Storage by setting up a named profile. Use the zone of your S3 user as the region (e.g., zh1 for Zürich, ch1 for Aargau/Lupfig):

aws configure --profile xelon
# AWS Access Key ID: <your-access-key-id>
# AWS Secret Access Key: <your-secret-access-key>
# Default region name: zh1
# Default output format: json

Then use the --endpoint-url flag to direct requests to the Xelon S3 endpoint:

# List buckets
aws --profile xelon --endpoint-url https://<s3-endpoint> s3 ls

# Upload a file
aws --profile xelon --endpoint-url https://<s3-endpoint> s3 cp ./backup.tar.gz s3://my-bucket/

# Download a file
aws --profile xelon --endpoint-url https://<s3-endpoint> s3 cp s3://my-bucket/backup.tar.gz ./

# Sync a directory
aws --profile xelon --endpoint-url https://<s3-endpoint> s3 sync ./data/ s3://my-bucket/data/

Encryption at Rest

Xelon Object Storage does not currently apply server-side encryption (SSE) automatically. Buckets created through Xelon HQ do not enable SSE-S3, SSE-KMS, or SSE-C at the object-storage layer — objects are stored on the underlying Ceph cluster as you upload them.

If you need a hard guarantee that data is encrypted at rest with keys you control, use client-side encryption: encrypt before uploading. The key never leaves your environment, which is the strongest sovereignty model and works without any platform-side feature.

Example 1: One-off file encryption with OpenSSL

OpenSSL is preinstalled on virtually every Linux and macOS system — useful for ad-hoc encrypt-then-upload of single files or archives:

# Encrypt a file with AES-256-CBC and a password-derived key
openssl enc -aes-256-cbc -salt -pbkdf2 \
  -in mydata.tar -out mydata.tar.enc

# Upload the encrypted file
aws --profile xelon --endpoint-url https://<s3-endpoint> \
    s3 cp mydata.tar.enc s3://my-bucket/

# Later: download and decrypt
aws --profile xelon --endpoint-url https://<s3-endpoint> \
    s3 cp s3://my-bucket/mydata.tar.enc ./
openssl enc -d -aes-256-cbc -pbkdf2 \
  -in mydata.tar.enc -out mydata.tar

OpenSSL prompts for a passphrase at encrypt and decrypt time. Store the passphrase securely — without it the data is unrecoverable.

Example 2: Stronger key management with GPG

GnuPG (gpg) provides proper public/private key pairs and integrates with hardware tokens such as YubiKey or smartcards. It is the right choice when multiple people or services need to read the same backups, or when you want hardware-backed key storage:

# One-time: generate a keypair if you don't have one
gpg --full-generate-key

# Encrypt for one or more recipients
gpg --encrypt --recipient your-key-id mydata.tar
# produces mydata.tar.gpg

# Upload
aws --profile xelon --endpoint-url https://<s3-endpoint> \
    s3 cp mydata.tar.gpg s3://my-bucket/

# Decrypt later (private key is required)
gpg --decrypt mydata.tar.gpg > mydata.tar

You can encrypt for multiple recipients in the same operation (each holding their own private key), which is convenient for shared backups within a team.

Example 3: Transparent encryption for sync and backup with rclone

For continuous backup or sync workloads, manual per-file encryption is impractical. rclone provides a crypt backend that wraps any S3-compatible remote and encrypts both file contents and names transparently:

# 1. Configure your Xelon S3 endpoint as a remote (e.g., named "xelon")
rclone config
#   Storage type: s3
#   Provider: Other
#   Access key + Secret key: your S3 keys
#   Endpoint: https://<s3-endpoint>
#   Region: zh1 (or ch1 — match your S3 user's zone)

# 2. Create a "crypt" remote that wraps the S3 remote
rclone config
#   Name: xelon-crypt
#   Storage: crypt
#   Remote: xelon:my-bucket/encrypted/
#   Filename encryption: standard
#   Directory name encryption: true
#   Password + salt: choose strong values — store them safely

# 3. From now on, use xelon-crypt: as if it were a normal remote
rclone copy /local/data xelon-crypt:
rclone sync /local/data xelon-crypt:

Files appear in the underlying bucket with scrambled names and AES-encrypted content. The crypt backend is widely used in production backup pipelines and is well audited.

Best Practices

• Use separate S3 users per application to isolate access and simplify key rotation.
• Rotate access keys regularly by generating a new token, updating your applications, then deleting the old token.
• Use meaningful bucket names that reflect the project and environment (e.g., myapp-prod-assets).
• Enable versioning for buckets containing critical data to protect against accidental overwrites.
• Set lifecycle policies for temporary data such as logs to automatically expire old objects.
• Avoid storing secrets in object storage. Use a dedicated secrets manager instead.