Installing Software Outside the AppCenter in elementary OS
elementary OS keeps things tidy by curating nearly every piece of software through its own AppCenter, but no curated store can hold every tool a person actually wants to run. Drivers, niche utilities, internal corporate apps, and the occasional piece of legacy software all live outside that storefront. For users down here in Australia — whether you're based in Melbourne, sitting somewhere in regional Queensland with intermittent NBN coverage, or working remotely from a coastal town in Western Australia — knowing how to bring those programs onto your machine without breaking the curated experience is a practical skill worth picking up.
That's where the platform's sideloading feature comes in. It's a deliberate mechanism that lets the system install packages from outside the AppCenter while still respecting the sandboxing and security model that makes elementary OS feel so calm. Once you understand the rules, sideloading stops being something you avoid and starts becoming a routine part of managing your own computer.
What Sideloading Means in elementary OS
Sideloading, in plain terms, is the act of installing a piece of software on your computer using a method the operating system did not package by default. On elementary OS this almost always means installing a .deb file, a Flatpak from a third-party remote, or an AppImage that runs without a traditional installer. The system watches for these installations and labels them under a section in the AppCenter so you always know what came from where, which is a small but significant quality-of-life detail.
The reason the developers built it this way is transparency. AppCenter packages are paid for, reviewed, and signed by the elementary team. Anything that arrives through a different channel is marked accordingly, including the name of the developer or upstream project that built it. If something goes wrong with an update or a security patch, the source is recorded. That record might sound bureaucratic, but it pays off the first time a piece of software misbehaves and you need to track down who shipped it.
A common point of confusion is whether sideloading is the same as piracy or sidestepping payment. It isn't. Many free and open-source programs simply don't have a maintainer willing to shepherd an AppCenter package, so users grab them directly from the developer's website or a community repository. Others are commercial applications whose vendors prefer to handle distribution themselves — think of enterprise tools, audio plugins, or proprietary hardware companions that almost everyone in Brisbane's small studios or Adelaide's medical research precincts relies on daily.
Preparing Your System for Sideloaded Packages
Before pulling anything in, a few quick checks keep the experience smooth. First, confirm your elementary OS installation is fully updated through the AppCenter's update panel, so the libraries a sideloaded program depends on are current. Skip this and you'll often hit missing-dependency errors during install — usually solvable, but annoying when the fix is just a system update you hadn't grabbed yet.
Second, install the practical tools that handle several formats in one go. flatpak is the most common, and elementary OS ships with the runtime preconfigured for the Flathub remote, so most Flatpaks will install without further setup. For native packages you'll want apt plus a few helpers. A single command pulls in curl, wget, and gdebi, the last of which resolves dependencies for .deb files automatically rather than leaving you to chase them through error messages.
Storage is rarely an issue on modern machines, but if you're running elementary OS on a smaller SSD — say, a 256 GB drive that came in a budget laptop from JB Hi-Fi — be aware that sideloaded apps frequently install larger dependency trees than their AppCenter counterparts. Flatpaks in particular can pull in shared runtimes weighing several hundred megabytes. If disk space is tight, prune the Flatpak uninstallers you no longer need, because leftover runtimes are the usual reason a fresh machine fills up faster than expected.
Finally, take a moment to decide where downloads will land. By default, browsers stash everything in ~/Downloads, which is fine for the odd installer but becomes messy once you start building up a personal software folder. Creating a ~/Apps directory and pointing your browser there keeps the slop to a minimum and makes future uninstalls easier.
Installing Deb Packages Safely
The humble .deb file is the bread-and-butter format for Debian-derived distributions, and elementary OS inherits that foundation wholesale. Most direct downloads — proprietary audio drivers from a vendor's site, internal tools shipped by an employer, or a piece of research software shared by a colleague — arrive in this form. The install is usually a double-click through the graphical installer, but knowing what's happening underneath is worthwhile.
When you double-click a .deb, the system opens a package installer that asks for your password, runs a dependency check, and writes the program into the standard Linux filesystem locations. If the check fails, gdebi from the terminal is the more diagnostic path. It reads the same metadata as the GUI installer but tells you precisely which library is missing, which is helpful when a download is partial or when a package targets a newer Ubuntu base than what elementary OS currently ships.
For users on the east coast managing intermittent connections — a familiar story for anyone working from a farm in central NSW or commuting on a regional V/Line service with patchy Wi-Fi — installing over the NBN from a flaky café hotspot is asking for trouble with larger packages. Drop the file via a wired connection at home, or sideload during off-peak hours when Telstra and Optus throttling eases up. A corrupted .deb looks identical to a good one until you try to install it, and the error messages can be cryptic.
A small number of commercial vendors ship Linux software as compressed archives that include a .deb plus a licence key file or installer script. Read the README inside the archive before running anything. The install flow occasionally asks for a sudo password inside the script, and you want to be sure the script is doing what it claims rather than burying something unwanted inside.
Using Flatpak and Other External Sources
Flatpak is the modern sandboxed format favoured by projects that want a single build to run across many Linux distributions. The format pairs well with elementary OS because it sits behind the same AppCenter interface — sideloaded Flatpaks appear there with a clear "Installed (Sideloaded)" tag and don't conflict with the curated listings.
The usual workflow is straightforward. Find the Flatpak reference on a project's site (often shown as a flatpak install command), copy it, and run it in a terminal. The first install prompts you to add the Flathub remote if it's not already configured; accept that prompt and authentication proceeds under your normal user account. Once the program is on the system, you'll find it in the application launcher alongside everything else, indistinguishable in daily use.
A niche but genuinely useful alternative is AppImage, which is essentially a self-contained executable that runs without installation. Download the file, mark it executable from the file manager's permissions panel, and double-click. AppImages are popular among one-off utilities — screen recorders, audio tools, retro emulators — and they leave almost no trace when you delete the file, which appeals to anyone who likes their filesystem tidy. The trade-off is no automatic updates, so jot the version down somewhere if it matters to you.
For Australian users integrating with enterprise stacks, especially those running cloud and edge workloads out of local data centres, applications distributed through the edge computing community frequently arrive as signed Flatpaks or self-contained bundles. Knowing how to verify those signatures before installing is a small habit that pays off whenever the software originates from a vendor you haven't worked with before.
Keeping the System Tidy After Installing Outside Sources
The last and most easily forgotten step is hygiene. Sideloaded software does not vanish cleanly when you delete its folder. Configuration files linger in ~/.config, cached assets pile up in ~/.cache, and the package database continues to record the install long after the binary itself is gone. A regular pass through the system helps.
For Flatpaks, flatpak list shows everything installed across every remote, and flatpak uninstall removes both the app and any orphan runtimes it no longer needs. Run flatpak repair once in a while — it walks the user-space installation and tidies references that have gone stale. For .deb packages, apt list --installed | grep is the quick way to find what was added by name, and sudo apt remove handles the uninstall cleanly, including any extra libraries pulled in only for that program.
A useful habit is to keep a short text file in ~/Apps listing the name, source URL, and install date of anything sideloaded. It looks old-fashioned, but when you want to migrate to a fresh install — which many Australian users do every couple of years when the laptop refreshes — that file cuts the rebuild time from an afternoon to a coffee break. Spare a few minutes every quarter to keep it accurate and you'll thank yourself the next time a hard drive needs cloning.
Sideloading on elementary OS is a deliberate, documented pathway designed to coexist with the AppCenter rather than replace it. The platform respects that you have software needs no curator can predict, and it gives you a way to install confidently while still showing clearly what came from where. Treat the AppCenter listings as the path of least resistance, drop to Flatpak or direct downloads when a tool genuinely isn't curated, and keep light records of what you install. Do that, and your machine stays predictable, repairable, and yours to command — which is, after all, the quiet promise an operating system like this one tries to keep.
