If you are setting up a new Linux server, Debian and Ubuntu are usually the two options that come up first. Both are mature, well-supported, and used across everything from small VPS deployments to large production environments. They also share the same package format and package manager, so the day-to-day administration feels familiar on both.

The decision usually comes down to tradeoffs: Debian gives you a leaner and more conservative base, while Ubuntu gives you newer defaults, a broader support ecosystem, and easier onboarding. This guide shows where those differences matter in practice.

Shared Foundation #

Ubuntu is built on top of Debian. Canonical (the company behind Ubuntu) takes a snapshot of Debian’s unstable branch every six months, applies its own patches and defaults, and publishes a new Ubuntu release.

Because of this shared lineage, the two distributions have a lot in common:

• Both use apt and dpkg for package management.
• Both use systemd as the init system.
• Both use .deb packages, and many third-party vendors ship a single .deb that works on either distribution.
• Configuration file locations, service management commands, and filesystem layout follow the same conventions.

If you already know one, you can work comfortably on the other with very little adjustment.

Release Cycle and Support #

The biggest practical difference between Debian and Ubuntu is how often they release and how long each release is supported.

Debian does not follow a fixed release schedule. A new stable version ships roughly every two years, but only when the release team considers it ready. Each stable release receives approximately three years of full security support from the Debian Security Team, followed by about two more years of extended support through the Debian LTS project. Debian 13 (Trixie), released in August 2025, is the current stable version as of this writing. Debian 12 (Bookworm), released in June 2023, is now oldstable.

Ubuntu follows a predictable time-based schedule. A new version ships every six months (April and October), and every two years the April release is designated a Long-Term Support (LTS) version. LTS releases receive five years of free security updates, extendable to ten years through Ubuntu Pro (free for up to five machines for personal use). Ubuntu 24.04 LTS (Noble Numbat) is the current LTS release.

If you want a release calendar you can plan around years in advance, Ubuntu is easier to work with. If you prefer a slower release model that puts stability first, Debian is usually the better choice.

Package Freshness vs Stability #

Debian Stable freezes all package versions at release time. Once Bookworm shipped, its packages only receive security patches and critical bug fixes, never feature updates. This means you will not encounter unexpected behavior changes after a routine apt upgrade, but it also means you may be running older versions of languages, databases, or runtimes for the life of the release.

Ubuntu LTS takes a similar approach to stability, but because it pulls from a more recent Debian snapshot and applies its own patches, LTS packages tend to be slightly newer at release time. Ubuntu also offers PPAs (Personal Package Archives) as an official mechanism for installing newer software outside the main repository, though mixing PPAs with production servers carries its own risks.

Both distributions offer backports repositories for users who need specific newer packages without upgrading the entire system.

For server workloads where you install most software through containers or version managers (for example, nvm for Node.js or pyenv for Python), base package age matters less. The distribution becomes a stable foundation, and you manage application-level versions separately.

Default Installation and Setup #

Ubuntu Server ships with a guided installer (Subiquity) that walks you through disk layout, networking, user creation, and optional snap-based packages like Docker. It installs a small but functional set of tools by default and can import your SSH keys from GitHub or Launchpad during setup.

Debian’s installer is more traditional. It offers the same configuration options, but the interface is text-based and expects you to make more decisions yourself. The resulting system is leaner; Debian installs very little beyond the base system unless you explicitly select additional task groups during installation.

If you provision servers with tools like Ansible, Terraform, or cloud-init, the installer matters less because you will not spend much time in it after the first boot. It matters more for quick manual deployments and local VMs, where Ubuntu usually gets you to a usable system faster.

Commercial Support and Cloud Ecosystem #

Canonical offers paid support contracts, compliance certifications (FIPS, CIS benchmarks), and a managed services tier for Ubuntu. Ubuntu Pro extends security patching beyond the main repository and adds kernel livepatch for rebootless security updates. That matters most for teams with uptime targets, compliance requirements, or formal support needs.

Debian is entirely community-driven. There is no single company behind it, and there is no commercial support offering from the project itself. Third-party consultancies provide Debian support, but the ecosystem around it is smaller.

In the cloud, Ubuntu has a strong lead in first-party image availability. Every major provider (AWS, Google Cloud, Azure, DigitalOcean, Hetzner) offers official Ubuntu images, and many default to Ubuntu when launching a new instance. Debian images are also available on all major platforms, but Ubuntu tends to receive new platform features and optimized images first.

For container base images, both are widely used. Debian slim images are a popular choice for minimal Docker containers, while Ubuntu images are common when teams want closer parity between their server OS and their container environment.

Security #

Both distributions have strong security track records. The Debian Security Team and the Ubuntu Security Team publish advisories and patches regularly, and both maintain clear processes for reporting and fixing vulnerabilities.

The key difference is scope. Ubuntu LTS includes five years of standard security maintenance for packages in the Main repository. Ubuntu Pro extends coverage to Main and Universe, effectively the full Ubuntu archive. Debian’s security team focuses on the main repository, and Debian’s LTS team covers only a subset of packages during the extended support period.

For kernel security, Ubuntu offers kernel livepatch through Ubuntu Pro, which applies critical kernel fixes without a reboot. Debian does not have an equivalent service built into the project, though third-party solutions exist.

In practice, both distributions are secure when properly maintained. The difference is in how much of the maintenance is handled for you and for how long.

When to Choose Debian #

Choose Debian when you want:

• Maximum stability with few surprises after upgrades. Debian Stable is one of the most conservative general-purpose distributions available.
• A minimal base system that you build up yourself. Debian installs very little by default, which keeps the system lean and gives you tighter control over what runs on the server.
• No vendor dependency. Debian is maintained by a community of volunteers and governed by a social contract. There is no single company setting the direction of the project.
• A lightweight container base. Debian slim images are a common choice when image size matters.

Debian is often the better fit for long-running infrastructure, self-managed servers, and setups where predictability matters more than convenience.

When to Choose Ubuntu #

Choose Ubuntu when you want:

• Faster time to a working server. The installer and default configuration get you to a usable system quickly, especially on cloud platforms where Ubuntu images are often the default.
• Longer official support. Five years of free LTS support (ten with Ubuntu Pro) gives you a wider upgrade window than Debian’s default support period.
• Commercial backing. If your organization requires vendor support contracts, compliance certifications, or managed services, Canonical provides them.
• Broader documentation and community. Ubuntu’s larger user base means you will usually find more tutorials, examples, and third-party guides written for it.
• Cloud-heavy workflows. First-party cloud images and strong cloud-init support make Ubuntu an easy default for many hosted deployments.

Ubuntu is often the easier choice for cloud deployments, teams that need commercial support, and environments where onboarding speed matters.

Side-by-Side Summary #

FAQ #

Can I migrate a server from Ubuntu to Debian or vice versa?
It is technically possible but not straightforward. The distributions share the same package format, but they differ in package versions, configuration defaults, and init scripts. A clean reinstall with configuration management (Ansible, Puppet, or similar) is the safer path. Plan the migration as a new deployment rather than an in-place conversion.

Do Debian and Ubuntu run the same software?
For the most part, yes. Most common server software is available on both Debian and Ubuntu, whether through the official repositories, vendor-provided .deb packages, containers, or upstream binaries. That said, package versions, repository availability, and vendor support can differ between the two distributions and between releases.

Which is better for Docker and containers?
Both work well as Docker hosts. Installing Docker follows nearly the same steps on either distribution. For base images inside containers, Debian slim images are slightly smaller, while Ubuntu images offer closer parity with Ubuntu-based host systems. The difference is marginal for most workloads.

Which is more secure?
Neither is inherently more secure than the other. Both have dedicated security teams and fast patch turnaround. Ubuntu Pro extends patching to a wider package set and adds kernel livepatch, which can matter in environments with strict uptime or compliance requirements. On a properly maintained server, both are equally secure.

Conclusion #

Debian and Ubuntu are close enough that you can run the same kinds of workloads on either one. If you want the more conservative and self-managed option, pick Debian. If you want faster onboarding, broader vendor support, and a smoother cloud path, pick Ubuntu.

Debian 13, codenamed “Trixie”, was released on August 9, 2025. It ships with Linux kernel 6.12 LTS, GNOME 48, KDE Plasma 6, GCC 14.2, Python 3.13, and over 14,100 new packages. Debian 13 will receive full support until August 2028, with Long Term Support (LTS) extending to June 2030.

This guide walks you through upgrading Debian 12 “Bookworm” to Debian 13 “Trixie” via the command line.

Prerequisites #

You need to be logged in as root or a user with sudo privileges to perform the upgrade. You can only upgrade to Debian 13 from Debian 12. If you are running an older Debian version, upgrade to Debian 12 first.

Back Up Your Data #

Before starting a major version upgrade, make sure you have a complete backup of your data. If you are running Debian on a virtual machine, take a full system snapshot so you can restore quickly if anything goes wrong.

Update Currently Installed Packages #

Before changing the source repositories, bring your existing Debian 12 system fully up to date.

Check whether any packages are marked as held back, which could interfere with the upgrade:

sudo apt-mark showhold

If there are held packages, either unhold them with sudo apt-mark unhold package_name or make sure they will not cause issues during the upgrade.

Refresh the package index and upgrade all installed packages:

sudo apt update
sudo apt upgrade

Perform a major version upgrade of the installed packages:

sudo apt full-upgrade

Remove automatically installed dependencies that are no longer needed:

sudo apt autoremove

Update the Sources List #

The upgrade works by pointing your APT repositories from bookworm to trixie.

Open /etc/apt/sources.list with your text editor and replace every instance of bookworm with trixie. You can also do this with a single sed command:

sudo sed -i 's/bookworm/trixie/g' /etc/apt/sources.list

If you have third-party repository files under /etc/apt/sources.list.d/, disable them before the upgrade. They may not be compatible with Debian 13 and can cause errors.

After editing, your /etc/apt/sources.list should look similar to this:

deb https://deb.debian.org/debian/ trixie main contrib non-free non-free-firmware
# deb-src https://deb.debian.org/debian/ trixie main contrib non-free non-free-firmware

deb https://deb.debian.org/debian/ trixie-updates main contrib non-free non-free-firmware
# deb-src https://deb.debian.org/debian/ trixie-updates main contrib non-free non-free-firmware

deb https://security.debian.org/debian-security/ trixie-security main contrib non-free non-free-firmware
# deb-src https://security.debian.org/debian-security/ trixie-security main contrib non-free non-free-firmware

You can find a full list of Debian mirror addresses on the official mirrors page .

Upgrade to Debian 13 Trixie #

Set the terminal output to English to make it easier to follow any prompts:

export LC_ALL=C

Update the package index with the new Trixie repositories:

sudo apt update

If you see errors related to third-party repositories, fix or disable them before continuing.

Run the initial upgrade. This upgrades packages that do not require installing or removing other packages:

sudo apt upgrade --without-new-pkgs

During the upgrade, you may be asked whether services should be automatically restarted:

Restart services during package upgrades without asking?

You may also see prompts about configuration files. If you have not made custom changes to a file, it is safe to accept the package maintainer’s version. If you have made changes, keep the current version to avoid losing your customizations.

Once the initial upgrade finishes, run the full upgrade. This installs new packages, removes obsolete ones, and resolves any remaining dependency changes between Debian 12 and 13:

sudo apt full-upgrade

The upgrade may take some time depending on the number of packages, your hardware, and your internet speed.

When it completes, clean up packages that are no longer needed:

sudo apt autoremove

Reboot your system to load the new kernel:

sudo systemctl reboot

Verify the Upgrade #

After the system boots, log in and check the Debian version :

lsb_release -a

No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 13 (trixie)
Release: 13
Codename: trixie

You can also verify the kernel version:

uname -r

The output should show a 6.12.x kernel.

Troubleshooting #

Third-party repository errors during apt update
Disable any third-party sources under /etc/apt/sources.list.d/ before the upgrade. Re-enable them one by one after the upgrade completes, checking that each repository supports Debian 13.

“Packages have been kept back” during upgrade
This is normal during the initial apt upgrade --without-new-pkgs step. The subsequent apt full-upgrade resolves these held-back packages by installing new dependencies or removing conflicting ones.

Services fail to start after reboot
Check the service logs with journalctl -xe and the service status with systemctl status service_name. Configuration file format changes between major versions are a common cause. Compare your config with the package maintainer’s version in /etc/*.dpkg-dist files.

Conclusion #

Your system is now running Debian 13 Trixie. Re-enable any third-party repositories you disabled, verify that your critical services are running, and consider adding trixie-backports to your sources if you need newer package versions. For a full list of known issues and detailed upgrade notes, see the official Debian 13 release notes .

Both apt and apt-get manage packages on Debian-based systems. They talk to the same package database, resolve the same dependencies, and pull from the same repositories. Yet they exist as separate tools, and choosing the wrong one in the wrong context can cause minor headaches.

This guide explains how apt and apt-get differ, when to use each one, and how their commands map to each other.

Why Two Tools Exist #

apt-get has been the standard Debian package manager since 1998. It is reliable and well-documented, but its interface was designed for an era when terminal usability was an afterthought. Related tasks like searching and showing package details live in a separate tool called apt-cache, so users constantly switch between the two.

The apt command was introduced in Debian 8 and Ubuntu 14.04 (APT version 1.0, released in 2014) as a user-friendly front end. It combines the most common apt-get and apt-cache operations into a single command, adds a progress bar, and uses colored output by default.

Both tools are part of the same apt package and share the same underlying libraries. Installing one always installs the other.

User-Facing Differences #

When you run apt install in a terminal, you will notice a few things that apt-get does not do:

• A progress bar at the bottom of the screen shows overall download and install progress.
• Newly installed packages are highlighted in the output.
• The number of upgradable packages is shown after apt update finishes.
• Output is formatted with color when connected to a terminal.

These features make apt more pleasant for interactive use. They also make its output less predictable for scripts, since the formatting can change between APT versions without warning. The apt man page states this explicitly: the command line interface of apt “may change between versions” and “should not be used in scripts.”

apt-get, on the other hand, guarantees a stable output format. Its behavior and exit codes are consistent across versions, which is why automation tools like Ansible, Docker, and CI pipelines use apt-get rather than apt.

Command Comparison #

The table below maps the most common apt commands to their apt-get or apt-cache equivalents:

As you can see, apt merges apt-get and apt-cache into one tool and adds a few convenience commands like apt list and apt edit-sources that have no direct apt-get equivalent.

When to Use apt #

Use apt for everyday interactive work in the terminal. If you are installing a package, checking for updates, or searching the repository by hand, apt is the better choice. The progress bar and cleaner output make it easier to follow what is happening.

For example, to update your package index and upgrade all packages:

sudo apt update && sudo apt upgrade

To search for a package and then install it:

apt search nginx

sudo apt install nginx

When to Use apt-get #

Use apt-get in shell scripts, Dockerfiles, CI pipelines, and any automated workflow. The stable output format means your scripts will not break when the system upgrades to a newer APT version.

A typical Dockerfile uses apt-get with the -y flag to skip confirmation prompts:

RUN apt-get update && apt-get install -y \
 curl \
 git \
 && rm -rf /var/lib/apt/lists/*

The same applies to Bash scripts and configuration management tools. If the command runs without a human watching the output, use apt-get.

Advanced Operations #

The commands below work with both apt and apt-get, but they are better documented and more established under apt-get. In scripts and Dockerfiles, prefer the apt-get form for consistency and stability.

• apt-get install --no-install-recommends pkg — Install a package without pulling in recommended (but not required) dependencies. This is widely used in Docker images to keep the image size small.
• apt-get install --allow-downgrades pkg — Allow installing an older version of a package.
• apt-get build-dep pkg — Install all build dependencies needed to compile a package from source.
• apt-get source pkg — Download the source package.
• apt-get download pkg — Download the .deb file without installing it.
• apt-get changelog pkg — Display the package changelog.
• apt-get clean / apt-get autoclean — Clear the local package cache.

FAQ #

Is apt-get deprecated? No. apt-get is actively maintained and receives updates alongside apt. The APT developers have stated that apt-get will not be removed. It remains the recommended tool for scripts and automation.

Can I replace all apt-get commands with apt? For interactive terminal use, yes. For scripts, no. The apt output format is not guaranteed to remain stable, and its interface may change between versions. Stick with apt-get in any automated workflow.

Is there a performance difference between apt and apt-get? No. Both tools use the same libraries and resolve dependencies the same way. The only difference is the user interface. Install and download speeds are identical.

What about apt-cache? Is it still needed? For interactive use, apt search and apt show replace the most common apt-cache operations. For scripts or when you need advanced query options like apt-cache policy or apt-cache depends, you should still use apt-cache directly.

Conclusion #

Use apt when you are typing commands at a terminal, and apt-get when you are writing scripts or Dockerfiles. For a complete reference of apt subcommands, see the apt Command in Linux guide and the APT cheatsheet .

Git is the world’s most popular distributed version control system used by many open-source and commercial projects. It allows you to collaborate on projects with fellow developers, keep track of your code changes, revert to previous stages, create branches , and more.

This guide covers installing and configuring Git on Debian 13 (Trixie) using apt or by compiling from source.

Quick Reference #

For a printable quick reference, see the Git cheatsheet .

Installing Git with Apt #

This is the quickest way to install Git on Debian.

Check if Git is already installed:

git --version

If Git is not installed, you will see a “command not found” message. Otherwise, it shows the installed version.

Use the apt package manager to install Git:

sudo apt update
sudo apt install git

Verify the installation:

git --version

Debian 13 stable currently provides Git 2.47.3:

git version 2.47.3

You can now start configuring Git.

When a new version of Git is released, you can update using sudo apt update && sudo apt upgrade.

Installing Git from Source #

The main benefit of installing Git from source is that you can compile any version you want. However, you cannot maintain your installation through the apt package manager.

Install the build dependencies:

sudo apt update
sudo apt install libcurl4-gnutls-dev libexpat1-dev cmake gettext libz-dev libssl-dev gcc wget

Visit the Git download page to find the latest version.

At the time of writing, the latest stable Git version is 2.53.0.

If you need a different version, visit the Git archive to find available releases.

Download and extract the source to /usr/src:

wget -c https://mirrors.edge.kernel.org/pub/software/scm/git/git-2.53.0.tar.gz -O - | sudo tar -xz -C /usr/src

Navigate to the source directory and compile:

cd /usr/src/git-*
sudo make prefix=/usr/local all
sudo make prefix=/usr/local install

The compilation may take some time depending on your system.

If your shell still resolves /usr/bin/git after installation, open a new terminal or verify your PATH and binary location with:

which git
echo $PATH

Verify the installation:

git --version

git version 2.53.0

To upgrade to a newer version later, repeat the same process with the new version number.

Configuring Git #

After installing Git, configure your username and email address. Git associates your identity with every commit you make.

Set your global commit name and email:

git config --global user.name "Your Name"
git config --global user.email "youremail@yourdomain.com"

Verify the configuration:

git config --list

user.name=Your Name
user.email=youremail@yourdomain.com

The configuration is stored in ~/.gitconfig:

[user]
name = Your Name
email = youremail@yourdomain.com

You can edit the configuration using the git config command or by editing ~/.gitconfig directly.

For a deeper walkthrough, see How to Configure Git Username and Email .

Troubleshooting #

E: Unable to locate package git
Run sudo apt update first and verify you are on Debian 13 repositories. If sources were recently changed, refresh package metadata again.

git --version still shows an older version after source install
Your shell may still resolve /usr/bin/git before /usr/local/bin/git. Check with which git and adjust PATH order if needed.

Build fails with missing headers or libraries
One or more dependencies are missing. Re-run the dependency install command and then compile again.

make succeeds but git command is not found
Confirm install step ran successfully: sudo make prefix=/usr/local install. Then check /usr/local/bin/git exists.

FAQ #

Should you use apt or source on Debian 13?
For most systems, use apt because updates are integrated with Debian security and package management. Build from source only when you need a newer Git release than the repository version.

Does compiling from source replace the apt package automatically?
No. Source builds under /usr/local and can coexist with the apt package in /usr/bin. Your PATH order determines which binary runs by default.

How can you remove a source-installed Git version?
If you built from the source tree, run sudo make prefix=/usr/local uninstall from that same source directory.

Conclusion #

We covered two ways to install Git on Debian 13: using apt, which provides Git 2.47.3, or compiling from source for the latest version. The default repository version is sufficient for most use cases.

For more information, see the Pro Git book .

A time zone is a geographic region that has the same standard time. Using the correct time zone is essential for many system tasks and processes. For example, the cron daemon uses the system’s time zone for executing cron jobs, and the timestamps in log files are based on the same time zone.

On Debian 13 (Trixie), the system’s time zone is set during the installation, but it can be easily changed at a later time.

This article explains how to set or change the time zone on Debian 13.

Quick Reference #

Checking the Current Time Zone #

timedatectl is a command-line utility that allows you to view and change the system’s time and date. It is available on all modern systemd-based Linux systems, including Debian 13.

To view the current time zone, run the timedatectl command without any options:

timedatectl

The output below shows that the system’s time zone is set to UTC:

 Local time: Sat 2026-02-07 14:30:44 UTC
Universal time: Sat 2026-02-07 14:30:44 UTC
RTC time: Sat 2026-02-07 14:30:44
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
systemd-timesyncd.service active: yes
RTC in local TZ: no

The system time zone is configured by symlinking the /etc/localtime file to a binary time zone identifier in the /usr/share/zoneinfo directory. You can also check the time zone by viewing the path the symlink points to using the ls command:

ls -l /etc/localtime

lrwxrwxrwx 1 root root 27 Feb 7 14:30 /etc/localtime -> /usr/share/zoneinfo/Etc/UTC

Changing the Time Zone on Debian 13 #

Before changing the time zone, you need to find the long name of the time zone you want to use. Time zones use a “Region/City” format.

To list all available time zones, use the timedatectl command with the list-timezones option:

timedatectl list-timezones

...
America/Montserrat
America/Nassau
America/New_York
America/Nipigon
America/Nome
...

To filter the list for a specific region or city, pipe the output through grep:

timedatectl list-timezones | grep -i "europe"

Once you identify the correct time zone for your location, run the following command as root or user with sudo privileges :

sudo timedatectl set-timezone <your_time_zone>

For example, to change the system’s time zone to Europe/London, you would run:

sudo timedatectl set-timezone Europe/London

Verify the change by invoking the timedatectl command again:

timedatectl

 Local time: Sat 2026-02-07 14:35:09 GMT
Universal time: Sat 2026-02-07 14:35:09 UTC
RTC time: Sat 2026-02-07 14:35:09
Time zone: Europe/London (GMT, +0000)
System clock synchronized: yes
systemd-timesyncd.service active: yes
RTC in local TZ: no

The time zone has been successfully changed.

Using dpkg-reconfigure #

On Debian systems, you can also change the time zone using the tzdata package. This method provides an interactive text-based interface:

sudo dpkg-reconfigure tzdata

The command opens a menu where you can select the geographic area and then the city or region. After making your selection, the system time zone is updated automatically.

Troubleshooting #

Changes do not persist after reboot
Ensure /etc/localtime is a symlink to a valid file in /usr/share/zoneinfo and re-run sudo timedatectl set-timezone Region/City.

Clock is still wrong after changing the time zone
Check that NTP sync is active with timedatectl status. If it is disabled, enable time synchronization: sudo timedatectl set-ntp true.

FAQ #

How do I check the current time zone on Debian 13?
Run the timedatectl command without any arguments. The “Time zone” line in the output shows the currently configured time zone.

Can I change the time zone without restarting?
Yes. The timedatectl set-timezone command takes effect immediately. There is no need to restart the system or any services.

What is the difference between timedatectl and dpkg-reconfigure tzdata?
Both methods achieve the same result. timedatectl is a single command that works on any systemd-based distribution. dpkg-reconfigure tzdata provides an interactive menu and is specific to Debian and Ubuntu systems.

Where are the time zone files stored?
Time zone data files are stored in the /usr/share/zoneinfo directory. The /etc/localtime file is a symlink that points to the active time zone file in that directory.

Conclusion #

To change the time zone on Debian 13, use the sudo timedatectl set-timezone command followed by the long name of the time zone you want to set.

If you have any questions, feel free to leave a comment below.