Server-Side Encryption (SSE-C)

Relution can encrypt the objects it stores in an S3-compatible bucket using Server-Side Encryption with a Customer-Provided Key (SSE-C). With SSE-C, Relution sends the encryption key with every request, and the storage backend uses it to encrypt objects on write and decrypt them on read. The backend never stores the key itself - keeping it safe is solely the administrator’s responsibility.

Read before enabling: SSE-C takes effect immediately on startup and Relution does not encrypt objects that already exist in the bucket. Only enable it on a clean instance with an empty bucket, or encrypt all existing objects first. If the key is lost, all encrypted data is permanently lost. See Important Notes below for details.

SSE-C vs. KMS encryption: SSE-C is not the same as client-side encryption via AWS KMS (added in Relution 26.3.3 →). With KMS, a customer managed key (CMK) is held and managed by AWS KMS. With SSE-C, the key is provided by Relution on each request and stored only by the administrator. These two mechanisms are mutually exclusive - only SSE-C or KMS or neither can be enabled, but never both at the same time.

Prerequisites

A working S3-compatible object storage setup - see Connect object storage →.
An object storage backend that supports SSE-C. We have verified support with SeaweedFS and Hetzner Object Storage. Other S3-compatible backends may work but have not been tested.
A 256-bit encryption key (see below).

Generating the Key

SSE-C requires a 256-bit (32-byte) key, provided as a Base64-encoded string. Generate one with openssl:

openssl rand -base64 32

Store the resulting value securely. If this key is lost, all encrypted objects in the S3 bucket can no longer be decrypted and are permanently lost.

Configuration

SSE-C is activated as soon as a key is configured. The key can either be provided inline via the relution.storage.s3.serverSideEncryption.key property (options A and B) or supplied as a file via relution.storage.s3.serverSideEncryption.keyFile (option C). If both are set, the key file takes precedence.

Option A: Using application.yml

Add the serverSideEncryption block to the application.yml:

relution:
  storage:
    resourceStorageType: S3
    s3:
      customEndpoint: http://seaweedfs:8333
      accessKey: %YOUR-ACCESS-KEY%
      secretKey: %YOUR-SECRET-KEY%
      bucketName: relution
      serverSideEncryption:
        key: %YOUR-BASE64-KEY%

Option B: Using Environment Variables

Add the following environment variable to the relution service in the compose.yml:

services:
  relution:
    environment:
      - RELUTION_STORAGE_S3_SERVERSIDEENCRYPTION_KEY=%YOUR-BASE64-KEY%

Option C: Key as a file

New in 26.5

Instead of providing the key inline, it can be read from a file. This is particularly useful when the key is mounted into the container as a Docker or Kubernetes secret. The path to the key file is configured via relution.storage.s3.serverSideEncryption.keyFile:

relution:
  storage:
    s3:
      serverSideEncryption:
        keyFile: /path/to/ssec.key

Or via the corresponding environment variable:

services:
  relution:
    environment:
      - RELUTION_STORAGE_S3_SERVERSIDEENCRYPTION_KEYFILE=/path/to/ssec.key

The file must contain the same Base64-encoded 256-bit key as the inline value (for example, generated with openssl rand -base64 32). A trailing newline is harmless because the value is trimmed; binary or hexadecimal keys are rejected.

On startup, Relution logs the read with Reading SSE-C key from file <path>. If the file is missing or does not contain a 32-byte key, startup aborts with a corresponding error message.

Important Notes

No migration of existing files: SSE-C takes effect immediately when Relution starts with the key configured. Relution does not encrypt objects that already exist in the bucket. Only use SSE-C on a clean instance with an empty bucket, or encrypt all existing S3 objects before starting Relution with the key. Otherwise, previously stored objects will remain unencrypted and may become inaccessible.

Losing the key means losing all data: The storage backend does not store the key - keeping it safe is solely the administrator’s responsibility. If the key is lost, all encrypted objects in the bucket become permanently unrecoverable, and Relution can no longer serve apps or resources from object storage. Keep the key in a secure, backed-up location.

Key rotation requires re-encryption: Rotating the key is the administrator’s responsibility. Relution does not re-encrypt objects when the key changes. To rotate the key, all existing objects in the bucket must be re-encrypted with the new key (for example, by copying them with the new key) before starting Relution with the updated configuration. Starting Relution with a new key while objects are still encrypted with the old one will make those objects inaccessible.

Mutually exclusive with KMS: Server-side (SSE-C) and client-side (KMS) encryption cannot be active at the same time. Configure at most one of them.

Customer Hub

Server-Side Encryption (SSE-C)

Prerequisites #

Generating the Key #

Configuration #

Option A: Using application.yml #

Option B: Using Environment Variables #

Option C: Key as a file #

Important Notes #