How to Install Apache Cassandra on Ubuntu 26.04, 24.04 and 22.04

Apache Cassandra makes sense on Ubuntu when one database node is not enough: it spreads data across a cluster, keeps writes available during node failures, and scales by adding machines instead of replacing the whole database tier. You can install Apache Cassandra on Ubuntu 26.04, 24.04, and 22.04 with Apache’s APT repository; the package name is cassandra, and the default branch used here is Cassandra 5.0.

The setup installs OpenJDK 17, adds Apache’s Cassandra repository in DEB822 format, verifies the service, and then handles the cqlsh difference between Ubuntu releases. It installs the local Cassandra server through APT, not Flatpak. Composer commands such as composer require cassandra/cassandra install PHP project dependencies only; they do not install the Cassandra server or system service.

These steps cover Ubuntu 26.04 (resolute), 24.04 (noble), and 22.04 (jammy). The repository source uses your system’s APT architecture instead of hard-coding amd64, so the same source format follows the architecture metadata Apache publishes for Cassandra.

Cassandra’s default JVM sizing is heavy for small VMs. Use at least 4GB of RAM for a simple test node, and plan more memory for production so the JVM heap and OS page cache both have room. If your system is smaller, reduce heap settings in /etc/cassandra/cassandra-env.sh before expecting reliable startup.

Install Apache Cassandra on Ubuntu

Update Ubuntu and Install Java

Refresh APT first so Ubuntu uses current package metadata before Java and Cassandra are installed.

sudo apt update
sudo apt upgrade -y

These commands use sudo for administrative tasks. If your account cannot use sudo yet, add the user to sudoers first or run the commands from an account that already has admin rights; the Ubuntu sudoers guide explains how to add a new user to sudoers on Ubuntu.

Cassandra 5.0 can run on Java 11 or Java 17, and the Apache package accepts either runtime. Install OpenJDK 17 here because it is available on Ubuntu 26.04, 24.04, and 22.04; the OpenJDK 17 guide for Ubuntu has a deeper Java walkthrough if you need one.

sudo apt install -y curl gpg openjdk-17-jre-headless

Confirm the Java runtime before adding the Cassandra repository.

java -version

openjdk version "17.0.18" 2026-01-20
OpenJDK Runtime Environment (build 17.0.18+8-Ubuntu-1)
OpenJDK 64-Bit Server VM (build 17.0.18+8-Ubuntu-1, mixed mode, sharing)

Add the Apache Cassandra APT Repository

If you previously tested Cassandra from an older APT source file, remove that legacy source before creating the new one. Keeping multiple Cassandra source files can leave duplicate repository targets or stale Signed-By paths.

sudo rm -f /etc/apt/sources.list.d/cassandra.sources
sudo rm -f /etc/apt/sources.list.d/cassandra.sources.list
sudo rm -f /etc/apt/keyrings/apache-cassandra.gpg
sudo rm -f /etc/apt/keyrings/apache-cassandra.asc

Download Apache’s Cassandra signing keys and store them as a dedicated keyring. The curl command fetches the key file, and gpg --dearmor --yes converts it into the binary keyring format APT expects without prompting on reruns.

curl -fsSL https://downloads.apache.org/cassandra/KEYS | sudo gpg --dearmor --yes -o /usr/share/keyrings/apache-cassandra.gpg

Create the DEB822 source file for Cassandra 5.0. The 50x suite tracks the 5.0 release branch, while dpkg --print-architecture writes the architecture APT should request from Apache’s repository.

printf '%s\n' \
'Types: deb' \
'URIs: https://debian.cassandra.apache.org' \
'Suites: 50x' \
'Components: main' \
"Architectures: $(dpkg --print-architecture)" \
'Signed-By: /usr/share/keyrings/apache-cassandra.gpg' \
| sudo tee /etc/apt/sources.list.d/apache-cassandra.sources > /dev/null

Check the file before APT reads it. On a typical 64-bit Ubuntu host, the architecture line should be amd64.

cat /etc/apt/sources.list.d/apache-cassandra.sources

Types: deb
URIs: https://debian.cassandra.apache.org
Suites: 50x
Components: main
Architectures: amd64
Signed-By: /usr/share/keyrings/apache-cassandra.gpg

Refresh APT and confirm that the cassandra package now resolves from Apache’s repository.

sudo apt update
apt-cache policy cassandra

cassandra:
  Installed: (none)
  Candidate: 5.0.8
  Version table:
     5.0.8 500
        500 https://debian.cassandra.apache.org 50x/main amd64 Packages

Install the Cassandra Package

Install Cassandra from the Apache repository. The package installs an LSB init script, creates the cassandra service account, and enables the service through systemd’s compatibility layer.

sudo apt install -y cassandra

Verify the installed server version.

cassandra -v

5.0.8

The package starts and enables Cassandra automatically. Check the enabled and active states, then give the service a short startup window before connecting.

systemctl is-enabled cassandra
systemctl is-active cassandra

enabled
active

Confirm the local CQL listener on port 9042. A successful check shows Cassandra listening on 127.0.0.1:9042.

ss -H -ltn 'sport = :9042'

LISTEN 0      4096   127.0.0.1:9042 0.0.0.0:*

Install cqlsh on Ubuntu

The Cassandra package includes /usr/bin/cqlsh, but that bundled client still expects Python 3.6 through 3.11. Ubuntu 22.04 ships Python 3.10, so the bundled client works there. Ubuntu 24.04 and 26.04 ship newer Python releases, so use a small virtual environment and a /usr/local/bin/cqlsh wrapper on those releases instead.

Use Bundled cqlsh on Ubuntu 22.04

On Ubuntu 22.04, verify the bundled client directly.

cqlsh --version

cqlsh 6.2.0

Install cqlsh on Ubuntu 26.04 and 24.04

On Ubuntu 26.04 and 24.04, install the standalone cqlsh package in a dedicated virtual environment. This avoids --break-system-packages, keeps the Cassandra Python driver outside Ubuntu’s system Python, and places the working wrapper ahead of the bundled /usr/bin/cqlsh. The Ubuntu virtual environment guide explains how Python virtual environments work on Ubuntu if you want the background.

sudo apt install -y python3-venv
sudo python3 -m venv /opt/cqlsh-venv
sudo /opt/cqlsh-venv/bin/python -m pip install --upgrade pip
sudo /opt/cqlsh-venv/bin/python -m pip install cqlsh
sudo ln -sf /opt/cqlsh-venv/bin/cqlsh /usr/local/bin/cqlsh
hash -r

Verify that your shell finds the wrapper in /usr/local/bin and that the standalone client runs.

command -v cqlsh
cqlsh --version

/usr/local/bin/cqlsh
cqlsh 6.2.2

Connect to the Local Cassandra Node

Connect to the local node after Cassandra has had time to finish startup. A simple DESCRIBE CLUSTER check proves that the client can reach the server over CQL.

printf 'DESCRIBE CLUSTER;\nEXIT;\n' | cqlsh 127.0.0.1 9042

Cluster: Test Cluster
Partitioner: Murmur3Partitioner
Snitch: DynamicEndpointSnitch

The PyPI cqlsh package may print a warning that it was built against Cassandra 5.0.0 when it connects to Cassandra 5.0.8. The cluster description output confirms the connection worked; keep an eye on that warning after future Cassandra point releases.

Choose a Cassandra Release Branch

Cassandra 5.0 is the normal choice for new Ubuntu installs. Apache also publishes 4.1 and 4.0 repository suites for older clusters, but those branches depend on Java 8 or 11 packages rather than the Java 17 runtime used in the main 5.0 path.

Repository suite	Current package	Java package dependency	Use case
50x	5.0.8	OpenJDK 17 or OpenJDK 11	Recommended for new deployments
41x	4.1.11	OpenJDK 11 or OpenJDK 8	Existing 4.1 clusters or compatibility testing
40x	4.0.20	OpenJDK 11 or OpenJDK 8	Legacy 4.0 clusters that cannot move yet

To install a 4.x branch, change only the Suites: line in /etc/apt/sources.list.d/apache-cassandra.sources, then install the Java version required by that branch before starting Cassandra. Do not mix multiple Cassandra suites on the same host.

Configure Apache Cassandra

Cassandra stores its configuration files in /etc/cassandra/. The main configuration file is cassandra.yaml, which controls cluster settings, networking, storage paths, and performance parameters. Data is stored in /var/lib/cassandra/ and logs are written to /var/log/cassandra/.

By default, Cassandra listens on several ports: 9042 (CQL client connections), 7000 (inter-node cluster communication), and 7199 (JMX monitoring). On a single-node development setup, these ports are bound to localhost and pose minimal risk. For production deployments or multi-node clusters, configure UFW firewall rules to restrict access to trusted networks only.

JVM Configuration

For JVM-level adjustments such as heap size and garbage collection settings, edit the /etc/cassandra/cassandra-env.sh file. Add JVM arguments to the JVM_OPTS variable, which Cassandra reads at startup. Startup options like heap size can also be configured in /etc/default/cassandra. If you need to configure the JAVA_HOME environment variable for your system, see our Java environment path guide for Ubuntu.

Enable User Authentication

By default, Cassandra allows unauthenticated access, which is acceptable for development but should be changed for production deployments. Before modifying the configuration, create a backup:

sudo cp /etc/cassandra/cassandra.yaml /etc/cassandra/cassandra.yaml.backup

Open the configuration file for editing:

sudo nano /etc/cassandra/cassandra.yaml

Locate and modify the following parameters to enable password authentication:

authenticator: org.apache.cassandra.auth.PasswordAuthenticator
authorizer: org.apache.cassandra.auth.CassandraAuthorizer
roles_validity_in_ms: 0
permissions_validity_in_ms: 0

Setting the validity values to 0 disables caching of role and permission information, which is useful during initial setup. In production, you may want to increase these values to reduce authentication overhead.

Save the file and restart Cassandra to apply the changes:

sudo systemctl restart cassandra

Create an Administrative Superuser

After enabling authentication, the default credentials are cassandra / cassandra. Connect using these credentials:

cqlsh -u cassandra -p cassandra

Create a new superuser account. Replace admin and your_secure_password with your desired username and a strong password:

CREATE ROLE admin WITH PASSWORD = 'your_secure_password' AND SUPERUSER = true AND LOGIN = true;

Exit the shell and reconnect with your new account:

cqlsh -u admin -p your_secure_password

Disable the default cassandra account to prevent unauthorized access:

ALTER ROLE cassandra WITH PASSWORD = 'disabled_account' AND SUPERUSER = false AND LOGIN = false;
REVOKE ALL PERMISSIONS ON ALL KEYSPACES FROM cassandra;

Grant full permissions to your new administrative account:

GRANT ALL PERMISSIONS ON ALL KEYSPACES TO admin;

Configure Automatic Login

To avoid entering credentials each time you connect, configure a cqlshrc file. Create the directory and copy the sample configuration:

mkdir -p ~/.cassandra
sudo cp /etc/cassandra/cqlshrc.sample ~/.cassandra/cqlshrc
sudo chown $USER:$USER ~/.cassandra/cqlshrc
chmod 600 ~/.cassandra/cqlshrc

Edit the file to add your credentials:

nano ~/.cassandra/cqlshrc

Locate the [authentication] section and add your username and password:

[authentication]
username = admin
password = your_secure_password

Storing passwords in plain text files carries security risks. Ensure the cqlshrc file has restrictive permissions (chmod 600) and consider using environment variables or a secrets manager for production environments.

Rename the Cluster

The default cluster name is “Test Cluster,” which should be changed for production deployments. Update the system table:

cqlsh

UPDATE system.local SET cluster_name = 'Production Cluster' WHERE KEY = 'local';

Exit cqlsh and update the cluster name in the cassandra.yaml configuration file:

sudo nano /etc/cassandra/cassandra.yaml

Find the cluster_name setting near the top of the file and change it to match:

cluster_name: 'Production Cluster'

Flush the system keyspace and restart Cassandra to apply the change:

nodetool flush system
sudo systemctl restart cassandra

The connection banner displays the new cluster name when you reconnect to cqlsh.

Update Apache Cassandra

Updates within the same Cassandra branch, such as 5.0.7 to 5.0.8, come through the configured Apache repository. Use APT to refresh package metadata and upgrade only the Cassandra package.

sudo apt update
sudo apt install --only-upgrade -y cassandra

After upgrading, restart the Cassandra service to load the new version:

sudo systemctl restart cassandra

Verify the updated server version after the restart.

cassandra -v

For major version upgrades, such as 4.1 to 5.0, consult the official Apache Cassandra installation documentation and the matching upgrade notes before changing the repository suite. Major upgrades can require data format migrations, configuration changes, and rolling cluster planning.

Remove Apache Cassandra

Remove Cassandra in stages so you can keep data and configuration if you are only reinstalling the package.

Stop and Disable the Service

Stop the Cassandra service and disable it from starting on boot:

sudo systemctl stop cassandra
sudo systemctl disable cassandra

Remove the Cassandra Package

Uninstall the Cassandra package and purge its package-managed configuration. Keep dependency cleanup separate so APT does not remove unrelated packages that were already marked autoremovable.

sudo apt remove --purge -y cassandra

Confirm that the package no longer has an installed ii state in dpkg.

dpkg -l cassandra | grep '^ii' || echo "cassandra package is not installed"

cassandra package is not installed

If APT reports unused packages afterward, review the list first. Run the removal only when the preview contains packages you actually want to remove.

sudo apt autoremove --dry-run

Remove the Repository Configuration

Delete the DEB822 source file and dedicated Apache keyring, then remove any legacy source files from older setups. Refresh APT afterward so the cassandra package no longer appears as an install candidate.

sudo rm -f /etc/apt/sources.list.d/apache-cassandra.sources
sudo rm -f /etc/apt/sources.list.d/cassandra.sources
sudo rm -f /etc/apt/sources.list.d/cassandra.sources.list
sudo rm -f /usr/share/keyrings/apache-cassandra.gpg
sudo rm -f /etc/apt/keyrings/apache-cassandra.gpg
sudo rm -f /etc/apt/keyrings/apache-cassandra.asc
sudo apt update

Remove Data Directories (Optional)

The following commands permanently delete all Cassandra data, including databases, commit logs, and saved caches. Back up any important data before proceeding.

sudo rm -rf /var/lib/cassandra
sudo rm -rf /var/log/cassandra
sudo rm -rf /etc/cassandra

If you installed the standalone cqlsh virtual environment on Ubuntu 26.04 or 24.04, remove the venv and wrapper too.

The next cleanup commands delete the standalone cqlsh virtual environment and any saved user-level cqlsh settings. Do not remove ~/.cassandra if it contains connection profiles or credentials you still need.

sudo rm -rf /opt/cqlsh-venv
sudo rm -f /usr/local/bin/cqlsh
hash -r

Remove any user-level cqlsh configuration files:

rm -rf ~/.cassandra

Clear the shell’s cached command paths, then verify that the Cassandra server command and the optional standalone cqlsh wrapper are gone.

hash -r
command -v cassandra || echo "cassandra command not found"
command -v cqlsh || echo "cqlsh command not found"

cassandra command not found
cqlsh command not found

Confirm the package is no longer available from the repository:

apt-cache policy cassandra

cassandra:
  Installed: (none)
  Candidate: (none)
  Version table:

Troubleshooting

Cassandra Service Fails to Start

If the service fails to start, check recent Cassandra logs and confirm the host has enough free memory for the default JVM sizing.

journalctl -u cassandra -n 80 --no-pager
free -h

Common causes include insufficient memory for the default heap calculation, incorrect file permissions under /var/lib/cassandra, or running an older 4.x branch with the wrong Java version.

Connection Refused When Using cqlsh

If cqlsh reports “Connection refused,” ensure Cassandra has fully started. The service can take 30-60 seconds to initialize. Check the service status and wait for it to complete startup:

systemctl status cassandra --no-pager

You can also monitor the Cassandra log file for startup progress:

tail -f /var/log/cassandra/system.log

Look for a message containing “Startup complete” to confirm the service is ready to accept connections.

Bundled cqlsh Reports Unsupported Python Version

If you see “Warning: unsupported version of Python, required 3.6-3.11” when running cqlsh, your shell is still using the bundled client from /usr/bin/cqlsh. Errors that mention cqlshlib, cqlshmain.py, auth_provider, or authproviderhandling.py usually point to the same kind of client and Python-driver mismatch. On Ubuntu 26.04 and 24.04, install the virtual-environment wrapper from the cqlsh section above, then run hash -r or open a new shell so /usr/local/bin/cqlsh wins on your PATH.

Port 9042 Already in Use

If Cassandra fails to start or cqlsh cannot connect, another service may be using port 9042. Check which process is using the port:

sudo lsof -nP -iTCP:9042 -sTCP:LISTEN

If another Cassandra instance or service is running, stop it before starting Cassandra. If you need to run multiple instances, configure Cassandra to use a different port in /etc/cassandra/cassandra.yaml by modifying the native_transport_port setting.

Conclusion

Apache Cassandra is running on Ubuntu from Apache’s APT repository, with the service enabled and a working cqlsh path for your release. Before moving past a single local node, lock down the CQL and gossip ports, tune heap settings for the hardware, and back up /var/lib/cassandra before major upgrades.