apt remove vs purge vs autoremove, explained

What apt remove, purge and autoremove each do

apt remove deletes a package but keeps its configuration files. apt purge deletes the package and its configuration files. apt autoremove deletes packages that were installed only to satisfy another package's dependencies and that nothing needs any more. Autoremove is only as safe as the "automatic" marks it reads, so read its dry run before you let it act.

APT (Advanced Package Tool) is the layer you type commands into. Under it, dpkg (the Debian package manager) unpacks .deb files and keeps the record of what is installed. A conffile is a configuration file that dpkg tracks for a package. Most of the difference between remove and purge comes down to conffiles.

You will run each command on a test package and read what the system reports. The output depends on your release and on what is already installed. So this guide tells you what to look at and explains the result. It does not print a list you should expect to see.

Use a test server, and record your release

Autoremove acts on the whole system, not on one package. Do these steps on a throwaway VPS or a container, not on a server you care about. First record what you are running, because the APT version decides which manual applies.

cat /etc/os-release
apt --version
sudo apt-get update

The manual pages for APT 2.8.3 on Ubuntu 24.04 and APT 3.2.0 on Ubuntu 26.04 use the same wording for remove, purge, autoremove, autopurge and the simulate option. Debian 13 now provides APT 3.0.4 through security updates, with the same wording. If apt --version shows something else, read man apt-get on your own server before you trust any line below.

Debian's November 4, 2026 security advisory recommends upgrading APT: version 3.0.4 fixes CVE-2026-109518, which allows a man-in-the-middle attacker to replace a package after verification and execute code as root.

apt-get update downloads fresh package lists from your sources. Run it before the first install so APT knows the current versions.

Install a package that brings a dependency

The test package is jq, a small JSON tool. Its Ubuntu package pages list libjq1 as a dependency on 24.04, and libjq1 plus libonig5 on 26.04. Ask APT what it would do before it does it:

apt-get -s install jq

-s means simulate. The manual describes it as "No action; perform a simulation of events that would occur based on the current system state but do not actually change the system." A simulated run prints one line per dpkg step: Inst for unpack, Conf for configure and Remv for remove. Read the Inst lines. Which packages does APT plan to add? A library that is already on your system gets no Inst line, because there is nothing to add.

Now install it for real:

sudo apt-get install -y jq

Which packages are marked manual, and which automatic?

APT keeps one mark per package: manual or automatic. Print both lists and filter them down to the packages from the last step.

apt-mark showmanual | grep -E '^(jq|libjq1|libonig5)(:|$)'
apt-mark showauto | grep -E '^(jq|libjq1|libonig5)(:|$)'

Compare the two outputs. Which list holds the package you named on the command line? Which list holds the packages APT chose for you?

The marks matter because of one rule in the apt-mark manual: "Once an automatically installed package is no longer depended on by any manually installed package it is considered no longer needed." The automatic mark does not make a package temporary. It means "keep this only while something manual needs it".

What does apt remove leave behind?

Remove the parent package, then check the dependencies again.

sudo apt-get remove jq
apt-mark showauto | grep -E '^(jq|libjq1|libonig5)(:|$)'
apt-get -s autoremove

Read the output of remove. Which packages did it say it would remove: only jq, or the libraries too? Then read the Remv lines from the simulated autoremove. Which packages does autoremove now propose, and why those?

The reason is in the manual: autoremove "is used to remove packages that were automatically installed to satisfy dependencies for other packages and are now no longer needed." Check each proposed package against that sentence. Was it marked automatic in your showauto output? Is any manual package left that needs it?

If the simulation lists packages you never touched, read each one. Those were already automatic and unneeded before you started. An earlier removal may have left them, or someone may have changed a mark. This is the real reason to simulate first: autoremove acts on the whole system's history, not only on your last command. When the list is what you want, run it:

sudo apt-get autoremove

apt remove vs purge: what changes in dpkg -l?

jq may be a poor test for purge, so check before you move on. Reinstall it and ask dpkg whether it ships any conffiles:

sudo apt-get install -y jq
dpkg-query -W -f='${Conffiles}\n' jq

The dpkg manual explains why the answer matters. Remove "removes everything except conffiles and other data cleaned up by the postrm script". And: "If there is no DEBIAN/conffiles control file nor DEBIAN/postrm script, this command is equivalent to calling --purge." The postrm script is the package's own clean-up script, which dpkg runs after removal. A package with no conffiles and no postrm leaves nothing for purge to do.

For a package that does keep configuration, use nano, a small text editor. Its file list on Ubuntu 24.04 includes a file under /etc. Install it, then record what it put in /etc and which files dpkg treats as conffiles. Also create a settings file in your home directory, as a stand-in for your own data.

sudo apt-get install -y nano
dpkg -L nano | grep '^/etc'
dpkg-query -W -f='${Conffiles}\n' nano
echo '# my own nano settings' > ~/.nanorc

The dpkg-query manual marks the Conffiles field as internal. If that command prints nothing, run dpkg-query -s nano and look for a Conffiles line in the full record. Write down every path these commands print. You need them after the package is gone.

Now remove it and read the state dpkg records:

sudo apt-get remove nano
dpkg -l nano

The first three columns of dpkg -l show the desired action, the package status and any error, in that order. The dpkg-query manual defines the letters. Desired action: u unknown, i install, h hold, r remove, p purge. Status: n not-installed, c config-files, i installed, plus a few half-finished states. Which two letters start the nano line? Run ls -l on each /etc path you recorded. Is it still there?

Read the letters at the start of the line, not the column positions. The manual says the output format "varies automatically to fit the terminal width".

Now purge the package you already removed. The apt manual says you "can get rid of these leftovers by calling purge even on already removed packages."

sudo apt-get purge nano
dpkg -l nano
ls -l ~/.nanorc

Does dpkg -l still show a line for nano? Run ls -l on the /etc paths again. What is left? And is your ~/.nanorc still there?

Purge deletes the package's conffiles. The dpkg manual states the limit of its configuration-file handling: it covers "files in system directories, not configuration files written to individual users' home directories." Your check of ~/.nanorc shows what that means on your own system.

Ubuntu's server documentation writes the same operation as apt remove --purge and adds a caution: "This may or may not be what you want, so use it with caution." The harder case is files a package creates for itself after install. dpkg only knows the files it unpacked. The dpkg-query manual says dpkg -L "will not list extra files created by maintainer scripts". For files like these, the dpkg manual says "dpkg won't remove them by itself", and the package's postrm script "has to take care of their removal during purge". So whether a database's data directory survives purge depends on that one package's script. Before you purge anything that stores data, list its data directory, purge on a test box, and list it again. If the disk still looks full after a purge, why df and du disagree about free space covers the next places to look.

Is apt autoremove safe?

Autoremove is safe when the marks are right. It is dangerous when a package you rely on carries an automatic mark. That happens in ordinary ways:

• A package arrived as a dependency, and later you started to use it directly. Using a package does not change its mark.
• Someone ran apt-mark auto on it.
• Someone installed it with the apt-get option that marks fresh installs as automatic. Check the exact spelling of that option with man apt-get on your release.
• Someone ran apt-mark minimize-manual, which the manual says marks "(transitive) dependencies of metapackages as automatically installed".

You can watch the mark decide the outcome with jq, which you installed again in the purge section:

sudo apt-mark auto jq
apt-get -s autoremove
sudo apt-mark manual jq
apt-get -s autoremove

Does jq appear in the first simulation? Does it appear in the second? Explain each answer from the rule above. apt-mark manual, says the manual, "will prevent the package from being automatically removed if no other packages depend on it." So the fix for a tool you rely on is one command. Run it the day you notice you depend on that tool.

Two more protections exist. apt-mark hold stops a package from being "automatically installed, upgraded or removed". It also freezes upgrades, so it is a heavier tool than apt-mark manual. And apt.conf has a NeverAutoRemove list: "Never autoremove packages that match the regular expression(s)."

One habit removes most of the risk. Do not use apt-get remove --auto-remove. The manual says that with install or remove, the option "acts like running the autoremove command". It joins the two steps, so you never see the separate list. Run remove, simulate autoremove, read it, then run it.

apt-get autopurge is "a shortcut for autoremove --purge". It also deletes the conffiles of everything autoremove takes. Use it only after the plain simulation looks right.

What about old kernels?

Kernel packages are a separate case. The apt.conf manual describes a Protect-Kernels option that "tells apt autoremove that kernels are protected". A container does not boot its own kernel, so the exercise above cannot show them. Cleaning up old kernels on Ubuntu covers which kernels to keep and how to remove the rest.

apt or apt-get for these commands?

The apt manual calls apt "an end user interface" with options "better suited for interactive usage". Ubuntu's server documentation says "The apt-get command should be used in scripts". This guide uses apt-get for one more reason: the simulate option and autopurge are documented in the apt-get manual, and the apt manual for Debian 13 does not mention autopurge. For typing remove or purge by hand, either works.

When a removal goes wrong

A removal that stops halfway can leave dpkg with unfinished work, and later commands then complain about it. Fixing broken packages with apt and dpkg walks through that recovery. If your server installs updates on its own, read how unattended upgrades are configured on Ubuntu before you trust any list of automatic packages. On Rocky, Alma or Fedora the commands have different names, and the dnf and apt command equivalents maps them. Those systems also keep a transaction log, which undoing an update with dnf history explains.

FAQ

Does apt purge delete files in my home directory?

The dpkg manual says its configuration-file handling applies to files in system directories, not to configuration files in users' home directories. Purge deletes the conffiles dpkg tracks for the package, plus whatever the package's own postrm script removes. To be sure for a given package, create or list a file in your home directory, purge the package on a test server, and check whether the file is still there.

Why does apt autoremove want to remove a package I use?

Autoremove proposes packages that are marked automatic and that no manually installed package depends on any more. A tool you use directly can carry the automatic mark if it first arrived as another package's dependency. Run apt-mark showauto to see the mark, and sudo apt-mark manual <package> to keep it. Then run apt-get -s autoremove again and check that the package is no longer on the list.

Should I use apt remove or apt purge?

Use remove when you might reinstall the package and want its configuration back. Use purge when you want its conffiles gone too. You can decide later, because purge also works on a package you already removed. In dpkg -l, the status letter c means config-files: the package is gone but its conffiles are still on disk.

Is it safe to run apt autoremove on a production server?

It is safe when you read the list first. Run apt-get -s autoremove and read every Remv line. If a package you need is on it, mark it with sudo apt-mark manual <package> and simulate again. Avoid apt-get remove --auto-remove, because it removes the unused dependencies in the same step and you never see the list on its own.