Cassandra

Overview

Apache Cassandra is a distributed wide-column NoSQL database built for write-heavy workloads, linear scaling and no single point of failure. This template deploys a Cassandra 5.0 cluster (cassandra:5.0) of replicas nodes in one location, each node on its own persistent volume, with password authentication enabled, a weekly nodetool repair cron job, and optional scheduled backups to AWS S3 or GCS. Cluster credentials are not template values. Cassandra reads its superuser password, application role and keyspace from a dictionary secret you create before installing, so no password passes through Helm or lands in the release.

This template does not create a GVC. It deploys into an existing GVC that you already have — the one you pass with --gvc. Use a GVC with exactly one location: the template declares no per-location settings and forms a single-location cluster, so a GVC with several locations is not a supported shape for it.

What Gets Created

Resource	Name	Purpose	Optional
Workload	`RELEASE_NAME-cassandra`	Cassandra nodes (stateful, `replicas` replicas, container `cassandra`, CQL on port `9042`)	—
Volume set	`RELEASE_NAME-cassandra-data`	One volume per node mounted at `/var/lib/cassandra`, with autoscaling	—
Secret	`RELEASE_NAME-cassandra-config`	The `cassandra.yaml` template, completed with the node’s address and seed list at container start	—
Secret	`RELEASE_NAME-cassandra-init`	The startup script: rack configuration, JMX credentials and the first-boot bootstrap	—
Identity	`RELEASE_NAME-cassandra-identity`	Identity the workloads run as; carries the Cloud Account binding when backups are on	—
Policy	`RELEASE_NAME-cassandra-policy`	Grants the identity `reveal` on the two secrets above, on your credentials secret, and on the backup config secret	—
Workload	`RELEASE_NAME-cassandra-repair`	Cron job running `nodetool repair` on every node (container `repair`)	`repair.enabled: true` (the default)
Secret	`RELEASE_NAME-cassandra-credentials`	Dictionary holding only the backup bucket and region — despite the name, no credentials	`backup.enabled: true`
Workload	`RELEASE_NAME-cassandra-backup`	Cron job exporting the application keyspace with `cqlsh COPY TO`	`backup.enabled: true` with `backup.type: logical`
Container	`backup` sidecar in `RELEASE_NAME-cassandra`	Takes a `nodetool snapshot` on each node and syncs it to the bucket	`backup.enabled: true` with `backup.type: physical`

The template creates no credential secret of its own. The superuser password, application username, password and keyspace live only in the secret you create.

Prerequisites

One dictionary secret must exist before you install. It holds the credentials you type into every client and connection string. Secrets are org-level, so no GVC flag is involved.

Create the credentials secret

A dictionary secret holding exactly four keys. superuserPassword is the password of the built-in cassandra role, used for JMX and by the repair and backup jobs; username, password and keyspace are the application role and its keyspace, created on first boot. The keyspace value must be a valid unquoted CQL identifier (lowercase letters, digits and underscores):

cpln secret create-dictionary --name SECRET_NAME \
  --entry superuserPassword='YOUR-SUPERUSER-PASSWORD' \
  --entry username=myuser \
  --entry password='YOUR-STRONG-PASSWORD' \
  --entry keyspace=mykeyspace

Set credentialsSecretName to this name. Secret names are org-wide, so give each release its own.

Read the secret back later

Pass -o yaml. A bare cpln secret reveal prints only a summary table, not the values:

cpln secret reveal SECRET_NAME -o yaml

Create the secret before installing, or the deployment wedges silently. The template refuses to render when credentialsSecretName is blank, but a name that points at a secret which does not exist installs successfully and then never starts. The container never runs, so cpln logs returns zero lines. The one place the reason appears is status.versions[].message:

cpln workload get-deployments RELEASE_NAME-cassandra --gvc GVC_NAME -o yaml

The secret SECRET_NAME no longer exists. Workload updates are paused until the
secret is added or the reference to the secret removed.

Use get-deployments — plain cpln workload get has no versions key. Once the secret exists the deployment recovers on its own after several minutes, or run cpln workload force-redeployment RELEASE_NAME-cassandra --gvc GVC_NAME to skip the wait.

Backups need a bucket and a Control Plane Cloud Account before they can be enabled — see Backing Up. Nothing else is required.

Installation

Create the prerequisite secret, then install with the name of that secret. The defaults give you three nodes of 1 CPU and 4 GiB each, a replication factor of 1, weekly repair and no backups:

cpln helm install RELEASE_NAME oci://ghcr.io/controlplane-com/templates/cassandra \
  --version 1.1.1 --gvc GVC_NAME \
  --set credentialsSecretName=SECRET_NAME

UI

Browse, install, and manage templates visually

CLI

Manage templates from your terminal

Terraform

Declare templates in your Terraform configurations

Pulumi

Declare templates in your Pulumi programs

Configuration

Each block below is the shipped default for that part of values.yaml.

Cluster Size and Replication

replicas: 3
# replicationFactor must not exceed replicas
replicationFactor: 1

These are two separate settings that work together:

replicas — how many Cassandra nodes run. The token ring is split across them, so more nodes means more capacity and throughput.
replicationFactor — how many copies of each partition the application keyspace keeps. With a factor of 3 every row exists on three nodes, and reads and writes at QUORUM consistency succeed while one of them is down.

replicationFactor must not exceed replicas; the template refuses to render otherwise (replicationFactor (3) cannot exceed replicas (1)). The system_auth keyspace, which holds roles and passwords, is always replicated to every node regardless of replicationFactor.

The default replication factor of 1 keeps a single copy of each partition. For anything you cannot afford to lose, set replicationFactor: 3 with at least three replicas and read and write at QUORUM.

Credentials

# REQUIRED PREREQUISITE SECRET — CREATE IT BEFORE YOU INSTALL.
# A `dictionary` secret holding exactly four keys: `superuserPassword`
# (the built-in `cassandra` role), `username`, `password` and `keyspace`.
# If it does not exist at install time the deployment WEDGES silently —
# `cpln logs` returns nothing at all. See Prerequisites in the README for
# the exact `cpln secret create-dictionary` command.
credentialsSecretName: my-cassandra-credentials

The workloads read the secret through cpln://secret/... references, so the values appear in neither the Helm release nor the stored workload spec.

The credentials are applied once, by node 0 on the cluster’s first boot, and a flag file in its data directory (/var/lib/cassandra/.bootstrapped) stops them from being applied again. Changing the secret afterwards does not change the cluster — it only changes what clients and the cron jobs present, which then fails. To rotate on an existing cluster, follow Rotating Credentials.

Image and Resources

image: cassandra:5.0
cpu: 1
memory: 4Gi
# JVM heap: leave ~50% of container memory for off-heap (bloom filters, page cache, etc.)
# Cassandra 5.x uses G1GC — only MAX_HEAP_SIZE is valid; HEAP_NEWSIZE is ignored.
jvmHeapSize: 2G
clusterName: my-cassandra

cpu and memory apply to each node. Keep jvmHeapSize at roughly half of memory: Cassandra relies on off-heap memory for bloom filters, caches and the OS page cache. Choose clusterName before the first install — Cassandra stores it in the data directory and a node refuses to start when the configured name differs from the stored one.

Storage

volumes:
  data:
    initialCapacity: 10
    autoscaling:
      maxCapacity: 100
      minFreePercentage: 20
      scalingFactor: 1.5

Each node gets its own general-purpose-ssd volume, mounted at /var/lib/cassandra and holding the data, commit log and saved caches. Capacities are in GiB; the volume grows by scalingFactor whenever free space drops below minFreePercentage, up to maxCapacity.

Multi-Zone

multiZone:
  enabled: false

When true, Control Plane spreads the nodes across availability zones within the location. Verify that your location supports multi-zone before enabling it.

Zone placement applies to the nodes, not to the data. The template creates its keyspaces with SimpleStrategy, which ignores racks and zones when choosing where a partition’s replicas live, so a zone outage can take more than one replica of the same partition with it. Treat surviving a full zone outage as unverified with this template; the protection you can rely on is replicationFactor: 3 with QUORUM, which tolerates one node down.

Internal Access

internal_access:
  type: same-gvc
  workloads:

type accepts same-gvc, same-org or workload-list; for workload-list, list each allowed workload under workloads as an item of the form //gvc/GVC_NAME/workload/WORKLOAD_NAME.

Type	Who can connect on port `9042`
`same-gvc`	Every workload in the same GVC
`same-org`	Every workload in the organization
`workload-list`	Only the workloads listed under `workloads`

With workload-list and logical backups enabled, include the backup job itself — //gvc/GVC_NAME/workload/RELEASE_NAME-cassandra-backup — or its runs cannot reach the cluster. A change to internal_access can take a few minutes to take effect; re-test rather than trusting the first response.

Repair

repair:
  enabled: true
  # Cron schedule for full cluster repair (must run within gc_grace_seconds = 10 days)
  schedule: "0 2 * * 0"

Cassandra is eventually consistent: a node that misses writes while it is down drifts from its peers, and nodetool repair reconciles the replicas. Repair must complete on every node at least once within gc_grace_seconds (10 days by default) or deleted data can reappear after a node recovers. The RELEASE_NAME-cassandra-repair cron job runs a full repair on each node in turn, authenticating over JMX with superuserPassword; the default weekly schedule fits inside the 10-day window with margin. Repair is resource-intensive on large datasets — schedule it for a low-traffic window rather than disabling it.

Backup

backup:
  enabled: false
  type: logical   # options: logical, physical
  image: ghcr.io/controlplane-com/backup-images/cassandra-backup:5.0
  schedule: "0 2 * * *"   # daily at 2am UTC

  resources:
    cpu: 250m
    memory: 256Mi

  provider: aws   # options: aws, gcp

  aws:
    bucket: my-backup-bucket
    region: us-east-1
    cloudAccountName: my-backup-cloudaccount
    policyName: my-s3-policy
    prefix: cassandra/backups

  gcp:
    bucket: my-backup-bucket
    cloudAccountName: my-cloud-account
    prefix: cassandra/backups

The bucket and Cloud Account must exist first — see Backing Up for the two modes, the per-provider steps and the IAM policy.

Connecting

What	Address	Notes
CQL (same GVC)	`RELEASE_NAME-cassandra.GVC_NAME.cpln.local:9042`	Allowed by the default `internal_access.type: same-gvc`. Always use the fully qualified name. This is the address the template’s own backup job uses.
External	—	The template exposes no public endpoint. From your own machine, use `cpln port-forward` as shown below.
Application credentials	`cpln secret reveal SECRET_NAME -o yaml`	The `username`, `password` and `keyspace` entries of your prerequisite secret.
Superuser	`cassandra` / the `superuserPassword` entry	For operations only — never put it in an application.

Verify the cluster from inside a node. The credentials are already in the container’s environment, so nothing is typed on the command line. Every node should report UN (up, normal):

cpln workload exec RELEASE_NAME-cassandra --gvc GVC_NAME --replica RELEASE_NAME-cassandra-0 --container cassandra -- sh -c \
  'nodetool -u cassandra -pw "$CASS_SUPERUSER_PASSWORD" status'

cpln workload exec RELEASE_NAME-cassandra --gvc GVC_NAME --replica RELEASE_NAME-cassandra-0 --container cassandra -- sh -c \
  'cqlsh 127.0.0.1 9042 -u "$CASS_APP_USER" -p "$CASS_APP_PASSWORD" -e "SELECT now() FROM system.local"'

To use cqlsh from your own machine without opening the firewall, forward the port and connect to 127.0.0.1 with the application credentials:

cpln port-forward RELEASE_NAME-cassandra 9042:9042 --gvc GVC_NAME

cqlsh 127.0.0.1 9042 -u USERNAME -p PASSWORD -k KEYSPACE

Operations

Backing Up

Two modes are available; backup.type selects one. Neither mode saves the schema — keep your CREATE KEYSPACE and CREATE TABLE statements in version control, because both restore paths load data into tables that already exist. Backups keep no retention of their own; expire old folders with a bucket lifecycle rule.

Mode	What runs	What is written to the bucket
`logical`	The `RELEASE_NAME-cassandra-backup` cron job on `backup.schedule`. It connects to the cluster as the `cassandra` superuser and runs `cqlsh COPY TO` on every table of the keyspace named in your secret.	One gzip CSV per table: `PREFIX/YYYY-MM-DDTHH-MM-SSZ/KEYSPACE/TABLE.csv.gz`. Portable and small-dataset friendly; only the application keyspace is included.
`physical`	A `backup` sidecar container on every node, running `nodetool snapshot` on `backup.schedule` and clearing the snapshot after upload. The Cassandra workload gains outbound internet access so the sidecar can reach the bucket.	The snapshot’s SSTables for every keyspace, one folder per node: `PREFIX/YYYY-MM-DDTHH-MM-SSZ/RELEASE_NAME-cassandra-N/KEYSPACE/TABLE-UUID/snapshots/backup-TIMESTAMP/`. Faster for large datasets; restored node by node.

AWS S3

Create an S3 bucket. Set backup.aws.bucket to its name and backup.aws.region to its region.
If you do not have a Control Plane Cloud Account for AWS, follow the Create a Cloud Account guide. Set backup.aws.cloudAccountName to its name.
Create an IAM policy with the following JSON, replacing YOUR_BUCKET_NAME, and set backup.aws.policyName to its name. The template attaches this policy to the identity and nothing else, so the bucket in it is the only storage the backup can reach:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject",
                "s3:ListBucket",
                "s3:GetObjectVersion",
                "s3:DeleteObjectVersion",
                "s3:GetBucketLocation",
                "s3:AbortMultipartUpload",
                "s3:ListBucketMultipartUploads",
                "s3:ListMultipartUploadParts"
            ],
            "Resource": [
                "arn:aws:s3:::YOUR_BUCKET_NAME",
                "arn:aws:s3:::YOUR_BUCKET_NAME/*"
            ]
        }
    ]
}

Set backup.aws.prefix to the folder path for the backups, then set backup.enabled: true, backup.provider: aws and your backup.type.

GCS

Create a GCS bucket. Set backup.gcp.bucket to its name.
If you do not have a Control Plane Cloud Account for GCP, follow the Create a Cloud Account guide. Set backup.gcp.cloudAccountName to its name.
Add the Storage Admin role to the GCP service account associated with the Cloud Account. The template additionally binds the identity to roles/storage.objectAdmin on exactly the bucket in backup.gcp.bucket.
Set backup.gcp.prefix to the folder path for the backups, then set backup.enabled: true, backup.provider: gcp and your backup.type.

Check a run in the container logs. A logical run ends with Logical backup complete. Timestamp: ...; a physical run logs Physical backup complete. Tag: ... from each node:

cpln logs '{gvc="GVC_NAME", workload="RELEASE_NAME-cassandra-backup"}' --limit 50 --since 24h

cpln logs '{gvc="GVC_NAME", workload="RELEASE_NAME-cassandra"} |= "backup complete"' --limit 50 --since 24h

Restoring a Backup

Both restore paths are /usr/local/bin/restore.sh in the backup image, driven by RESTORE_TIMESTAMP — the YYYY-MM-DDTHH-MM-SSZ folder name under your prefix. The keyspace and tables must already exist; the script loads data, it does not recreate schema.

These procedures match the chart’s configuration and the backup image’s restore.sh, but they have not been rehearsed against a live install of this template. Rehearse on a throwaway release before you depend on them.

Physical restore. Backups are per node, and the script restores the folder named after the node it runs on, so it must run in the backup sidecar of every node in turn. It downloads that node’s SSTables onto the node’s data volume, loads them into the live tables with nodetool import — no restart — and deletes the download. Repeat for -1, -2 and so on; because each node owns a different token range, restoring only one node leaves the cluster with incomplete data:

cpln workload exec RELEASE_NAME-cassandra --gvc GVC_NAME --replica RELEASE_NAME-cassandra-0 --container backup -- sh -c \
  'RESTORE_TIMESTAMP=2026-05-15T02-00-00Z /usr/local/bin/restore.sh'

Logical restore — unverified path. The script downloads PREFIX/TIMESTAMP/KEYSPACE/*.csv.gz and replays each file into its table with cqlsh COPY FROM; rows whose primary key is in the backup are overwritten, rows that are not are left in place. It needs the environment the RELEASE_NAME-cassandra-backup job runs with — BACKUP_PROVIDER, BACKUP_BUCKET, BACKUP_PREFIX, AWS_REGION for S3, and CASSANDRA_HOST, CASSANDRA_PORT, CASSANDRA_USER, CASSANDRA_PASSWORD, CASSANDRA_KEYSPACE — but that job is a cron workload with no long-running container to exec into. Running it means starting the backup image with that environment, bucket access and network access to the cluster, with RESTORE_TIMESTAMP set and /usr/local/bin/restore.sh as the command. This has not been exercised with the template.

Rotating Credentials

The secret is read only on the cluster’s first boot, so a rotation happens inside Cassandra first, and the secret and the running workloads are then brought in line. Do the three steps together: the nodes’ JMX password file is written from the secret at container start, and the repair and backup jobs authenticate with the secret’s superuserPassword, so a mismatch between the two makes those jobs fail until the redeploy.

Change the passwords inside Cassandra

Open a cqlsh session as the superuser through the port-forward shown under Connecting (-u cassandra -p SUPERUSER-PASSWORD) and run whichever of these you are rotating:

ALTER ROLE 'USERNAME' WITH PASSWORD = 'NEW-STRONG-PASSWORD';
ALTER USER cassandra WITH PASSWORD 'NEW-SUPERUSER-PASSWORD';

Update the secret

Set the password and/or superuserPassword entries of your dictionary secret to the new values, so applications reading the secret and the cron jobs — which start a fresh container on every run — authenticate with them.

Redeploy the nodes

A running replica keeps the environment it started with; updating the secret does not restart it. Force a redeployment so each node’s environment and JMX password file match the secret:

cpln workload force-redeployment RELEASE_NAME-cassandra --gvc GVC_NAME

Upgrading From 1.0.x

Template versions up to 1.0.1 took the cluster credentials as plain Helm values and shipped working defaults for them — supersecretpassword for the built-in cassandra role and password for the application role. Version 1.1.0 removed all four keys; the upgrade is in place and changes nothing on the data volumes.

	1.0.x	1.1.0 and later
Credentials	`superuserPassword`, `username`, `password`, `keyspaceName` values	`credentialsSecretName` → a dictionary secret you create
Where the passwords live	The Helm release	Only the secret you create

Carrying the old values forward stops the upgrade. The removed keys are rejected at render, so cpln helm upgrade fails and your existing release is left untouched and running:

Error: execution error at (cassandra/templates/identity.yaml:1:4): cassandra: superuserPassword,
username, password and keyspaceName were REMOVED — they are now a `dictionary` secret you create,
named by credentialsSecretName, holding the keys `superuserPassword`, `username`, `password` and
`keyspace`. Delete them from your values. See Prerequisites in the README.

Recover the credentials the cluster already uses

Bootstrap runs once and is flagged on disk, so an existing cluster keeps whatever it was created with. Take the values from your current values file — before upgrading.

Create the secret with those same values

Follow Prerequisites. keyspaceName becomes the keyspace entry. Different values here do not change the cluster — they just leave clients and the cron jobs unable to authenticate.

Remove the old keys and upgrade

Delete all four, set credentialsSecretName, then upgrade.

Rotate anything that came from a default

supersecretpassword and password were published in the public template repository, so treat them as compromised and follow Rotating Credentials.

Upgrading From 1.1.0

Version 1.1.1 removes aws::ReadOnlyAccess from the backup identity; it only affects releases with backup.provider: aws. That AWS managed policy granted read access to every bucket in your AWS account and contained no write actions, so it never carried the backup itself — but it was silently supplying any read action your bucket-scoped policy happened to omit. Before upgrading, make sure your IAM policy contains the full action list under Backing Up; if it already matches, no action is needed. The identity now carries cpln-connector and your bucket-scoped policy only. Nothing else changes.

Scaling and Availability

Vertical. Raise cpu and memory together with jvmHeapSize (about half of memory); the data volumes grow on their own within volumes.data.autoscaling. Adding nodes. Raise replicas and upgrade; the new nodes join the ring and the repair job and seed list follow the new count. New nodes do not stream existing data when they join — every node in this template is a seed, and Cassandra seed nodes do not auto-bootstrap. Once each new node shows UN in nodetool status, stream its share of the data onto it with nodetool rebuild, naming the cluster’s datacenter (the template sets it to the GVC location, for example aws-us-east-1), then run nodetool cleanup on every pre-existing node to drop the ranges they no longer own. This procedure follows the upstream topology changes guidance and has not been exercised against a live install of this template:

cpln workload exec RELEASE_NAME-cassandra --gvc GVC_NAME --replica RELEASE_NAME-cassandra-3 --container cassandra -- sh -c \
  'nodetool -u cassandra -pw "$CASS_SUPERUSER_PASSWORD" rebuild -- aws-us-east-1'

cpln workload exec RELEASE_NAME-cassandra --gvc GVC_NAME --replica RELEASE_NAME-cassandra-0 --container cassandra -- sh -c \
  'nodetool -u cassandra -pw "$CASS_SUPERUSER_PASSWORD" cleanup'

Removing nodes is not covered by this template. Cassandra requires a node to be decommissioned (nodetool decommission) before it leaves the ring; lowering replicas without that is unverified and may lose data. Node loss. Each node’s data lives on its own volume and comes back with it after a restart, and each node runs nodetool drain before it stops. While a node is down, the partitions for which it holds the only copy are unavailable — with the default replicationFactor: 1 that is every partition it owns. With replicationFactor: 3 and QUORUM, the cluster keeps serving reads and writes with one node down. Surviving a full zone outage is unverified; see Multi-Zone.

Troubleshooting

The workload never becomes ready and cpln logs is empty

Symptom: cpln helm install reported success, the deployment never reaches ready, and cpln logs returns no lines. cpln workload get-deployments RELEASE_NAME-cassandra --gvc GVC_NAME -o yaml shows under status.versions[].message:

The secret SECRET_NAME no longer exists. Workload updates are paused until the
secret is added or the reference to the secret removed.

Cause: credentialsSecretName names a secret that does not exist (or was created in a different org).Fix: Create the secret as shown in Prerequisites, then run cpln workload force-redeployment RELEASE_NAME-cassandra --gvc GVC_NAME or wait several minutes for the deployment to recover on its own.

First install sits at Waiting for all 3 replicas to join before bootstrapping

Symptom: The cluster is slow to accept the application credentials and node 0’s logs show Waiting for all 3 replicas to join before bootstrapping..., possibly followed by WARN: Timed out waiting for all replicas — proceeding with available nodes.Cause: Node 0 creates the roles and keyspace only after every node has joined the ring, so that token ranges are final first. It waits up to ten minutes before proceeding with whatever has joined.Fix: Wait. If the warning appears, check the other nodes’ logs with cpln logs '{gvc="GVC_NAME", workload="RELEASE_NAME-cassandra"}' --limit 50 --since 10m for why they did not join, and run nodetool status as shown under Connecting until every node reports UN.

Install fails with replicationFactor cannot exceed replicas

Symptom: cpln helm install or upgrade exits with:

Error: execution error at (cassandra/templates/workload-cassandra.yaml:1:4): replicationFactor (3) cannot exceed replicas (1)

Cause: You asked for more copies of each partition than there are nodes to hold them.Fix: Set replicas to at least replicationFactor and run the command again. Nothing was changed by the failed run.

Upgrade fails with superuserPassword, username, password and keyspaceName were REMOVED

Symptom: cpln helm upgrade exits with the render error quoted under Upgrading From 1.0.x and nothing is changed.Cause: Your values still set one of the four keys that 1.1.0 removed.Fix: Create the prerequisite secret with the cluster’s existing credentials, delete the four keys, set credentialsSecretName, and upgrade again.

Clients are rejected with Bad credentials after the secret was changed

Symptom: cqlsh or a driver fails with code=0100 [Bad credentials] message="Provided username USERNAME and/or password are incorrect" using the values currently in the secret.Cause: The secret is applied only on the cluster’s first boot. Editing it later changes what clients present, not the roles stored in Cassandra.Fix: Authenticate with the credentials the cluster was created with, then follow Rotating Credentials to bring Cassandra, the secret and the workloads back in line.

The repair job logs Replica N repair failed

Symptom: The logs of RELEASE_NAME-cassandra-repair show WARN: Replica 1 repair failed. and end with ERROR: 1 replica(s) failed repair.Cause: The job connects to each node over JMX with the secret’s superuserPassword. The usual reason is that this value no longer matches what the nodes started with — a rotation that updated the secret without redeploying the nodes, or the reverse — or the node was down during the run.Fix: Confirm every node reports UN with nodetool status, then complete Rotating Credentials so the secret and the nodes agree, and wait for the next scheduled run.

Backup run fails with AccessDenied on the S3 upload

Symptom: The backup logs show the export or snapshot finishing, then An error occurred (AccessDenied) when calling the PutObject operation.Cause: The IAM policy named in backup.aws.policyName is missing an action, or its Resource does not match backup.aws.bucket. From 1.1.1 nothing else on the identity fills the gap.Fix: Update the policy to the full action list under Backing Up with both the bucket ARN and BUCKET/*, then wait for the next scheduled run and check its logs.

Important Notes

Create the credentials secret before installing. A missing secret wedges the deployment with no log output; the only diagnostic is status.versions[].message from cpln workload get-deployments.
Use a GVC with a single location. The template has no per-location settings and forms a single-location cluster.
The default replication factor is 1. Set replicationFactor: 3 with at least three replicas and use QUORUM before storing anything you cannot afford to lose.
Credentials apply only on first boot. Rotate inside Cassandra first, then update the secret and force a redeployment — in that order, together.
Keep repair running. Every node must be repaired at least once every 10 days or deleted data can reappear.
Backups do not include the schema. Keep your CQL schema in version control; both restore paths load data into existing tables.
New nodes do not stream data by themselves. After raising replicas, run nodetool rebuild on each new node and nodetool cleanup on the old ones.
Firewall changes are not instant. Allow a few minutes after changing internal_access before concluding a knob is broken.

External References

Cassandra Documentation

Official Apache Cassandra documentation

Repair

Anti-entropy repair and gc_grace_seconds

Cassandra Driver Matrix

Client drivers for connecting to Cassandra

Backup Image Source

Source of backup.sh and restore.sh used by this template

Cassandra Template

View the source files, default values, and chart definition

Template Catalog

Templates

Overview

What Gets Created

Prerequisites

Installation

UI

CLI

Terraform

Pulumi

Configuration

Cluster Size and Replication

Credentials

Image and Resources

Storage

Multi-Zone

Internal Access

Repair

Backup

Connecting

Operations

Backing Up

Restoring a Backup

Rotating Credentials

Upgrading From 1.0.x

Upgrading From 1.1.0

Scaling and Availability

Troubleshooting

Important Notes

External References

Cassandra Documentation

Repair

Cassandra Driver Matrix

Backup Image Source

Cassandra Template

​Overview

​What Gets Created

​Prerequisites

​Installation

UI

CLI

Terraform

Pulumi

​Configuration

​Cluster Size and Replication

​Credentials

​Image and Resources

​Storage

​Multi-Zone

​Internal Access

​Repair

​Backup

​Connecting

​Operations

​Backing Up

​Restoring a Backup

​Rotating Credentials

​Upgrading From 1.0.x

​Upgrading From 1.1.0

​Scaling and Availability

​Troubleshooting

​Important Notes

​External References

Cassandra Documentation

Repair

Cassandra Driver Matrix

Backup Image Source

Cassandra Template

Overview

What Gets Created

Prerequisites

Installation

Configuration

Cluster Size and Replication

Credentials

Image and Resources

Storage

Multi-Zone

Internal Access

Repair

Backup

Connecting

Operations

Backing Up

Restoring a Backup

Rotating Credentials

Upgrading From 1.0.x

Upgrading From 1.1.0

Scaling and Availability

Troubleshooting

Important Notes

External References