If you’ve spent any real time inside a terminal, you already know that not all terminal emulators are created equal. GNOME Terminal gets the job done for casual use, but the moment you start juggling dozens of SSH sessions, tailing logs across multiple servers, or running tmux panes with heavy scrollback, its limitations start to show. That’s usually the point where sysadmins and developers go looking for something faster, and Kitty almost always comes up in that search.

Kitty is a GPU-accelerated terminal emulator built by Kovid Goyal, the same developer behind Calibre. It renders text using OpenGL instead of leaning on the CPU for every character draw, which sounds like a minor technical detail until you’re scrolling through a 50,000-line log file and notice there’s zero lag. On Ubuntu 26.04 LTS, codenamed “Resolute Raccoon,” the installation process has a few quirks worth knowing about, especially since this release ships Wayland-only by default and drops Xorg entirely from the standard desktop image.

This guide walks through three legitimate installation paths: the APT package manager (the path most people should take), the official installer script maintained by Kovid Goyal himself, and building from source for anyone managing custom images or needing a specific patch level. Along the way, we’ll cover GPU rendering checks, Wayland-specific configuration quirks, common failure modes, and the kind of tuning tips that actually matter once Kitty becomes your daily driver rather than a novelty install.

None of this is theoretical. These are the same steps used when provisioning developer workstations and jump boxes that need a terminal capable of handling heavy multiplexing without choking. Whether you’re setting this up on a single desktop or baking it into a golden image for a fleet of engineering laptops, the process below reflects what actually works in production, not just what’s documented in a README.

Why Kitty Over GNOME Terminal or Alacritty

Before diving into commands, it’s worth addressing the obvious question: why bother switching at all?

GNOME Terminal (now called Console in recent Ubuntu releases) is fine for light use, but it renders through the CPU and lacks native tab/split support without relying on tmux or screen. Alacritty, another GPU-accelerated option, is blazing fast but deliberately minimal — no tabs, no ligature support, and configuration requires editing a YAML or TOML file with almost no built-in UI feedback.

Kitty sits in a sweet spot. It has native tabs and window splitting (called “layouts”), supports font ligatures, handles true color and Unicode rendering properly, and includes a scriptable remote control protocol that lets you control running Kitty instances from external scripts. That last feature alone is a big deal for anyone building custom dashboards or automation around their terminal workflow, something that comes up a lot when integrating monitoring output directly into a live pane.

It’s also worth mentioning graphics protocol support. Kitty implements its own terminal graphics protocol, which means tools like chafa, icat, or certain neofetch-style utilities can render actual images inline in the terminal, not ASCII approximations. If you’ve never seen a PNG preview render directly inside a terminal window during an SSH session, it’s a genuinely useful party trick that occasionally has real utility, like previewing a chart output from a Python script without leaving the shell.

System Requirements and Pre-Installation Checks

Ubuntu 26.04 LTS ships with GNOME 50 and Linux kernel 7.0 as its baseline, running Wayland exclusively on standard desktop installations. Kitty works well under Wayland, but there are a handful of environment variables and rendering behaviors that differ from the old Xorg days, and skipping the pre-checks below is how people end up filing bug reports for problems that aren’t actually bugs.

Run through this checklist first:

• Confirm you’re actually on Ubuntu 26.04 LTS with lsb_release -a. Point releases and interim versions sometimes get confused with the LTS branch, and dependency versions can differ enough to matter.
• Check available disk space with df -h /. Kitty’s binary footprint is small, typically under 50MB installed, but if you’re planning to add Nerd Fonts or icon fonts for a proper prompt setup, budget an extra 100–200MB.
• Verify your GPU driver stack is functional. Run glxinfo | grep "OpenGL renderer" — if the command isn’t found, install it first with sudo apt install mesa-utils. Kitty depends on a working OpenGL 3.3+ context, and on headless servers or VMs without proper GPU passthrough, this step will save you a confusing troubleshooting session later.
• If you’re on a VM (VirtualBox, VMware, or a cloud instance with a virtual desktop), make sure 3D acceleration is enabled in the hypervisor settings. Kitty will still launch without it in most cases by falling back to software rendering, but performance suffers noticeably, and on some minimal VM configurations it refuses to start entirely.

A quick real-world note: I’ve seen Kitty installs fail silently on stripped-down cloud VM images specifically because mesa-utils and basic X11/Wayland client libraries weren’t part of the base image. If you’re provisioning a fresh Ubuntu 26.04 cloud instance purely for a GUI session over VNC or RDP, don’t assume the graphics stack is complete just because the desktop environment boots.

Method 1: Installing Kitty via APT (Recommended for Most Users)

For the vast majority of use cases, the APT route is the right call. It integrates with your system’s update cycle, resolves dependencies automatically, and doesn’t leave orphaned files scattered across your home directory when you eventually want to remove it. Kitty has lived in Ubuntu’s Universe repository since the 18.04 era, and that packaging relationship hasn’t changed on 26.04.

Step 1: Update Your Package Lists

Always start with a full update. Skipping this step is one of the most common reasons people hit dependency resolution errors mid-install.

sudo apt update && sudo apt upgrade -y

On a fresh 26.04 install this might pull down a fair number of packages, especially if you’re setting up a machine that hasn’t been touched since first boot. Give it time; don’t interrupt it.

Step 2: Confirm the Universe Repository Is Enabled

Kitty is packaged in Universe, not Main, which means it’s community-maintained rather than officially supported by Canonical directly (though in practice it’s stable and well-tracked). Most desktop installs of Ubuntu enable Universe out of the box, but minimal server images and some cloud-optimized builds don’t.

sudo add-apt-repository universe
sudo apt update

If Universe was already enabled, this command is a harmless no-op. No need to check first; just run it.

Step 3: Install Kitty

sudo apt install kitty

That’s genuinely the entire command. APT resolves the dependency chain automatically, pulling in fontconfig, the rendering libraries Kitty needs, and any shared library dependencies tied to the OpenGL stack.

Step 4: Verify the Installation

kitty --version
apt info kitty

The version output confirms the binary runs correctly, and apt info shows you exactly which repository the package came from along with its installed size, which is useful if you’re auditing package provenance on a managed fleet.

One caveat worth flagging directly: the version shipped in Ubuntu’s repositories tends to lag a few point releases behind Kovid Goyal’s upstream releases. If you need the absolute latest features (new graphics protocol extensions, recent bug fixes), that’s when Method 2 becomes relevant.

Method 2: Installing Kitty via the Official Installer Script

When you need the newest release, the maintainer provides an installer script that downloads a pre-built binary and installs it entirely within your user’s home directory, no root permissions required for the install itself (though you’ll need sudo for a few dependency checks on the system side).

curl -L https://sw.kovidgoyal.net/kitty/installer.sh | sh /dev/stdin

This pulls the latest stable release and drops it into ~/.local/kitty.app/. A few things happen automatically: desktop integration files get generated, and a kitty.desktop entry appears so it shows up in your application launcher.

There’s a legitimate security consideration here worth pausing on: piping a remote script directly into sh is a common vector people warn about, and for good reason. Before running this on a production jump box or a machine handling sensitive credentials, it’s worth downloading the script first and reading through it rather than blindly piping it.

curl -L https://sw.kovidgoyal.net/kitty/installer.sh -o kitty-installer.sh
less kitty-installer.sh
sh kitty-installer.sh

This two-step approach costs you thirty extra seconds and eliminates the “what exactly did I just execute as my user” question. On personal workstations it’s a minor formality; on anything touching production infrastructure, it’s not optional in most shops with a real security policy.

Fixing the PATH Issue

The installer places the binary at ~/.local/kitty.app/bin/kitty, and that location isn’t in your shell’s PATH by default. This trips up a lot of people who run the install, then get “command not found” when typing kitty afterward.

Symlink the binaries into a directory that’s already on your PATH:

mkdir -p ~/.local/bin
ln -sf ~/.local/kitty.app/bin/kitty ~/.local/kitty.app/bin/kitten ~/.local/bin/

Then confirm ~/.local/bin is actually referenced in your shell configuration:

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

If you’re on Zsh instead of Bash (common if you’ve set up Oh My Zsh), swap .bashrc for .zshrc in that command.

Updating Kitty Installed via the Script

Re-running the exact same installer command upgrades an existing script-based install in place:

curl -L https://sw.kovidgoyal.net/kitty/installer.sh | sh /dev/stdin

This is one advantage the installer script has over APT: you’re not waiting on Debian package maintainers to catch up to upstream releases. The tradeoff is that you’re now responsible for tracking updates yourself instead of getting them bundled into your regular apt upgrade cycle.

Method 3: Building Kitty from Source

Compiling from source rarely makes sense for a desktop user, but it matters in specific scenarios: contributing to Kitty’s codebase, applying a custom patch, building for an architecture without pre-built binaries, or maintaining a hardened build pipeline where every binary running on a system has to be compiled in-house rather than downloaded pre-built.

Step 1: Install Build Dependencies

sudo apt install -y python3 build-essential libdbus-1-dev libx11-dev libxkbcommon-dev \
libxkbcommon-x11-dev libxcb-shape0-dev libxcb-xfixes0-dev libxcb-randr0-dev \
libxcb-render-util0-dev libxcb-shm0-dev libxcb-xinerama0-dev libpng-dev \
libgl1-mesa-dev libxrandr-dev libfontconfig1-dev libharfbuzz-dev

That’s a heavier dependency list than most people expect for what looks like a simple terminal application, but it reflects Kitty’s actual feature set: font rendering with HarfBuzz for proper ligature and complex script support, XCB bindings for window management, and direct OpenGL bindings for the rendering pipeline.

Step 2: Clone the Repository

git clone https://github.com/kovidgoyal/kitty.git
cd kitty

Step 3: Build

make

The build process compiles Kitty’s C core along with its Python-based configuration and UI layers. On a modern multi-core machine this typically finishes in a couple of minutes; on older or resource-constrained hardware, expect it to take longer and consume noticeable CPU during compilation.

Step 4: Install System-Wide (Optional)

sudo make install

Or, if you’d rather test without touching system directories, run it directly from the build folder:

./kitty/launcher/kitty

This is genuinely useful for verifying a build works before committing to a system-wide install, especially when testing a specific git branch or a cherry-picked patch that hasn’t landed in a stable release yet.

Wayland-Specific Configuration on Ubuntu 26.04

Since Ubuntu 26.04 LTS drops Xorg from the default desktop session entirely, it’s worth addressing Wayland behavior directly rather than assuming everything just works identically to older releases.

Kitty runs natively under Wayland using its own Wayland backend, and in most cases you won’t need to touch anything. But there are two situations where explicit configuration helps.

If you’re running Kitty through a remote desktop protocol (VNC, RDP, or NoMachine) where the Wayland compositor forwarding is imperfect, forcing XWayland compatibility mode sometimes resolves rendering artifacts:

GDK_BACKEND=x11 kitty

This forces GTK-based rendering paths through XWayland instead of native Wayland, trading a small amount of performance for compatibility. It’s a workaround, not a permanent fix, but it’s useful when debugging whether a rendering issue is Wayland-specific or a broader driver problem.

For clipboard integration issues (a genuinely common complaint on Wayland across many applications, not just Kitty), confirm wl-clipboard is installed:

sudo apt install wl-clipboard

Without it, copy-paste behavior between Kitty and other Wayland-native applications can behave inconsistently, particularly with middle-click paste, which Wayland handles differently than Xorg did.

Basic Configuration to Get Started

A fresh Kitty install runs with sane defaults, but almost nobody sticks with them for long. Configuration lives at ~/.config/kitty/kitty.conf, and the directory needs creating manually on a first-time install:

mkdir -p ~/.config/kitty
nano ~/.config/kitty/kitty.conf

A reasonable starting configuration for someone coming from a default terminal setup:

font_family JetBrains Mono
font_size 12.0
enable_audio_bell no
window_padding_width 6
confirm_os_window_close 0
scrollback_lines 10000

That scrollback_lines value matters more than it looks. The default scrollback in most terminal emulators is modest, and if you’re tailing verbose application logs or debugging a build process with heavy output, bumping this up avoids losing critical context to a scroll buffer that filled up mid-investigation.

For font rendering, installing a proper Nerd Font pays off if you use a shell prompt theme like Powerlevel10k or Starship, both of which rely on special glyphs for icons and separators:

sudo apt install fonts-jetbrains-mono

Then reference the correct font name in kitty.conf and restart Kitty for the change to apply.

SSH and Remote Session Compatibility

Here’s something that catches people off guard the first time: Kitty uses xterm-kitty as its TERM value by default. This is fine locally, but the moment you SSH into a remote server that doesn’t have the kitty terminfo entry installed, you’ll see broken rendering, missing colors, or outright errors from applications like vim or tmux that rely on terminfo capabilities.

Two ways to handle this. The quick fix, useful when you’re SSHing into a box you don’t control and can’t install terminfo on:

Host *
    SetEnv TERM=xterm-256color

Add that to ~/.ssh/config, and every SSH session will report a widely-supported terminal type instead of Kitty’s own identifier.

The more correct fix, if you manage the remote server, is copying Kitty’s terminfo entry over so the remote system understands xterm-kitty natively and unlocks Kitty-specific features like underline styles and better color support:

kitty +kitten ssh user@remote-host

This kitten ssh wrapper is bundled with Kitty specifically to solve this problem, and it handles copying the terminfo automatically on connection. For anyone managing a fleet of servers and jumping between them constantly, this is worth aliasing over plain ssh in your shell config.

Troubleshooting Common Installation Issues

“Kitty exits immediately after launch”

This almost always traces back to the OpenGL check we mentioned earlier. Run kitty --debug-gl from another terminal (GNOME Terminal, for instance) to see the actual error output, since Kitty crashing on launch won’t leave useful logs visible otherwise. If the output mentions failing to create an OpenGL context, the GPU driver stack is the problem, not Kitty itself. Update your graphics drivers with sudo ubuntu-drivers autoinstall and reboot.

“Command not found” after installing via the script

Covered above, but worth repeating because it’s the single most common support question: the PATH symlink step gets skipped. Double-check with which kitty after sourcing your shell config, and if it returns nothing, the symlink either wasn’t created or your PATH export didn’t take effect.

Fonts render as boxes or missing glyphs

This usually means the configured font doesn’t include the glyphs being requested, often icon fonts from a prompt theme. Install a proper Nerd Font variant and update font_family in kitty.conf accordingly. Running fc-list | grep -i "font name" confirms whether fontconfig actually sees the font installed on the system.

Slow performance despite GPU acceleration

Check whether Kitty fell back to software rendering by running:

kitty --debug-gl 2>&1 | grep -i renderer

If the output shows llvmpipe or a similar software renderer instead of your actual GPU model, the hardware acceleration path isn’t engaging. On VMs, this typically means 3D acceleration needs enabling in hypervisor settings. On bare metal, it usually points to missing or improperly installed proprietary GPU drivers.

Package conflicts during APT install

Occasionally, third-party PPAs or manually installed .deb packages for other terminal emulators leave behind conflicting alternatives entries. Run:

sudo apt --fix-broken install
sudo dpkg --configure -a

before retrying the Kitty install if APT reports dependency conflicts it can’t resolve automatically.