/opt has a narrower, more specific purpose than most other top-level directories: it exists purely as a designated home for optional, third-party software that does not fit the way the rest of the system organizes installed programs.

What “optional” means here

The Filesystem Hierarchy Standard defines /opt for add-on software packages, typically ones that are self-contained and installed independently of the distribution’s own package manager:

ls /opt
# google/  spotify/  jetbrains/

ls /opt/google/chrome/
# chrome  chrome-sandbox  resources/  locales/

The key distinguishing feature is self-containment. A package that installs into /opt generally brings its own copies of libraries and resources rather than relying heavily on shared system libraries the way most distribution-packaged software in /usr does. This trades a larger install footprint (since libraries are not shared) for isolation: the package is less likely to conflict with system library versions, and less likely to be affected by other software’s updates.

/opt vs /usr: two different philosophies

# /usr: shared, distribution-managed layout
/usr/bin/firefox          # binary
/usr/lib/firefox/         # its libraries, some possibly shared
/usr/share/doc/firefox/   # documentation, tracked by the package manager

# /opt: self-contained, vendor-managed layout
/opt/google/chrome/chrome            # binary
/opt/google/chrome/libwidevinecdm.so  # bundled library, not shared
/opt/google/chrome/resources/        # everything else the app needs

Software installed through apt install, dnf install, or pacman -S becomes part of the distribution’s package database, with files scattered across the standard shared hierarchy and tracked file-by-file. Software that installs into /opt is typically managed separately, sometimes with its own internal update mechanism (Chrome and many commercial applications check for updates themselves rather than relying entirely on the system package manager), and its files stay grouped together under one directory rather than interleaved with everything else.

The naming convention inside /opt

/opt/<vendor>/<product>/
# examples:
/opt/google/chrome/
/opt/spotify/
/opt/jetbrains/pycharm-2026.1/

Most well-behaved packages that install into /opt follow a vendor/product naming pattern, which keeps things organized when multiple third-party applications from different sources coexist on the same machine. This convention is not strictly enforced by the operating system, but it is widely followed enough that you can usually guess which vendor a given /opt subdirectory belongs to just from its name.

Getting software in /opt onto your PATH

Because /opt/vendor/product/bin is not part of the default PATH environment variable, a binary installed there is not automatically runnable by typing its name:

# Check your current PATH
echo $PATH

# Running the binary directly by full path always works
/opt/jetbrains/pycharm-2026.1/bin/pycharm.sh

# Vendors commonly work around this by creating a symlink
# into a directory that IS already on PATH
ls -la /usr/local/bin/chrome
# lrwxrwxrwx 1 root root 34 Jul  9 /usr/local/bin/chrome -> /opt/google/chrome/chrome

# Or you can add it yourself in your shell profile
echo 'export PATH="$PATH:/opt/jetbrains/pycharm-2026.1/bin"' >> ~/.bashrc
source ~/.bashrc

Some installers handle this automatically by creating a desktop entry (a .desktop file under /usr/share/applications) that points at the full path inside /opt, which is why an application can appear correctly in your desktop environment’s application menu even though it is not runnable directly from a terminal by name.

Uninstalling software from /opt

# Check for a bundled uninstaller first
ls /opt/vendorname/productname/
cat /opt/vendorname/productname/uninstall.sh 2>/dev/null

# If installed via a .deb or .rpm that happens to place files in /opt,
# the package manager can still remove it cleanly
dpkg -l | grep productname
sudo apt remove productname

# If it is a raw tarball extraction with no installer, manual removal
# is generally safe since /opt software is self-contained
sudo rm -rf /opt/vendorname/productname

# Check for leftover symlinks, desktop entries, or PATH additions
grep -rn "vendorname" ~/.bashrc ~/.profile 2>/dev/null
ls /usr/share/applications/ | grep -i productname

Because /opt software is designed to be self-contained, removing the directory is usually enough to uninstall the application itself, but it is worth checking for leftover PATH entries in your shell configuration, desktop menu entries, and any systemd service files if the software installed a background service, since those live outside /opt and a raw rm -rf will not clean them up.

Why /opt shows up less than it used to

Several newer distribution methods have emerged that achieve a similar goal, isolated, non-interfering software installation, without specifically targeting /opt:

# AppImage: a single executable file, runs from anywhere, no installation
chmod +x ./SomeApp.AppImage
./SomeApp.AppImage

# Flatpak: sandboxed, its own runtime, tracked by flatpak itself
flatpak install flathub org.example.App
flatpak run org.example.App

# Snap: similar sandboxed model, tracked by snapd
sudo snap install some-app

These formats existed either in limited form or not at all when /opt became a standard convention decades ago. They solve the same underlying problem, third-party software that should not interfere with the system’s own package-managed libraries, in ways that do not necessarily involve installing anything into /opt at all. As a result, /opt remains standard and supported, but a smaller share of new third-party software specifically chooses to install there compared to a decade ago.

Frequently Asked Questions

What is the /opt directory used for?

The name /opt stands for “optional.” It is reserved by the Filesystem Hierarchy Standard for add-on, third-party software packages, particularly ones that are self-contained: bundling their own binaries, libraries, and resources inside a single dedicated subdirectory rather than spreading files across the shared /usr hierarchy the way distribution-packaged software does.

What kind of software typically installs into /opt?

Commercial and proprietary software distributed outside a distribution’s official package repositories commonly installs into /opt. Google Chrome, for example, installs to /opt/google/chrome. Many vendor-provided applications, some development tools distributed as standalone bundles (like certain JetBrains IDEs or some versions of the Java Development Kit), and self-hosted application stacks packaged as tarballs also frequently land here.

What is the difference between /opt and /usr?

/usr holds software installed by the distribution’s package manager, integrated into a shared directory layout where binaries, libraries, and documentation from many different packages are interleaved together in common directories like /usr/bin and /usr/lib. /opt holds software that keeps everything for one specific application self-contained inside its own subdirectory, typically named after the vendor and product, such as /opt/vendorname/productname, making it easy to see exactly what belongs to what.

How does software in /opt get added to my PATH?

Because /opt/vendor/product/bin is not part of the default PATH environment variable, software installed there usually needs an explicit step to become runnable by typing its name directly. Vendors handle this in different ways: some create a symbolic link from a directory already in PATH (like /usr/local/bin) into the /opt installation, some provide a setup script that appends to your shell profile, and some simply document that you must add the directory manually with something like export PATH=“$PATH:/opt/vendor/product/bin” in your .bashrc.

Is it safe to delete a directory under /opt to uninstall software?

It is usually safer than deleting from /usr, since software in /opt is self-contained and generally does not share files with anything else on the system, but you should check for an uninstall script first. Many packages that install to /opt ship an uninstall.sh script or provide an entry in your package manager even though the files live in /opt. Removing the directory manually with rm -rf usually works cleanly, but can leave behind leftover configuration in your home directory, desktop shortcuts, or systemd service files that a proper uninstaller would have also removed.

Why do some Linux users say /opt is used less often than it used to be?

The rise of containerization (Docker, Podman), universal package formats (Flatpak, Snap, AppImage), and language-specific package managers has given third-party software several alternative distribution methods that did not exist or were not mainstream when /opt became a standard convention. An AppImage, for instance, achieves a similar goal (self-contained, does not interfere with system packages) without needing to be installed into /opt at all; it simply runs from wherever the file is saved. This has reduced, though not eliminated, how often modern software specifically targets /opt for installation.