Navigating Software Deployment: Installing .deb Packages on Your Server

When you’re actively seeking a robust hosting solution for your web applications, internal tools, or specialized services, you quickly realize that simply provisioning a server is only half the battle. The real work often begins with deploying your chosen software. For those operating within the Debian or Ubuntu ecosystem – common choices for server operating systems due to their stability and extensive package repositories – understanding how to handle `.deb` packages becomes an indispensable skill. This isn’t just about running a command; it’s about gaining fine-grained control over your server environment, ensuring compatibility, and sometimes deploying software that isn’t readily available through standard channels.

Many businesses, from burgeoning startups to established enterprises, encounter situations where they need to install custom applications, specific versions of development tools, or proprietary monitoring agents that come bundled as a `.deb` file. Relying solely on official distribution repositories, while often preferred for stability and security, can sometimes limit your options when a critical piece of software isn’t included or a very specific, unreleased version is required. This article will guide you through the practicalities of installing `.deb` packages on your server, exploring not just the “how,” but also the “when” and “why,” ultimately empowering you to make informed decisions about your hosting infrastructure and software deployment strategy.

The Strategic Imperative of .deb Packages in Server Environments

`.deb` packages are the standard binary packages used by Debian and its derivatives, most notably Ubuntu. They encapsulate compiled software, configuration files, and metadata, making them a convenient way to distribute and install applications. While many users are familiar with `apt` for installing software from official repositories, there are compelling reasons why you might find yourself directly managing `.deb` files on your server.

Consider a scenario where your development team has built a custom backend service for an e-commerce platform. This service might leverage unique libraries or require a specific runtime environment not present in standard repositories. Packaging this service as a `.deb` allows for consistent, repeatable deployment across multiple server instances. Or perhaps you’re integrating a third-party analytics agent or a specialized security scanner that the vendor provides only as a `.deb` file, bypassing traditional package managers to ensure a specific version and configuration.

For hosting clients, particularly those utilizing VPS (Virtual Private Server) or dedicated server environments, the ability to install `.deb` packages directly translates into greater flexibility and control. It means you aren’t limited to the software versions or selection offered by your operating system’s default repositories. This is crucial for maintaining a specific development stack, meeting compliance requirements, or deploying niche applications critical to your business operations. However, this power also comes with responsibilities, notably managing dependencies and ensuring the integrity of your installed software.

Understanding Your Server Environment: Prerequisites for .deb Installation

Before you embark on installing `.deb` packages, a clear understanding of your server environment and some foundational knowledge are essential. The success of your deployment hinges on these prerequisites.

First and foremost, you need SSH access to your server. This secure shell protocol is the primary method for interacting with Linux-based servers remotely, allowing you to execute commands. Along with SSH access, you’ll require root privileges or the ability to use `sudo` (superuser do) to execute commands with administrative permissions. Installing system-wide software typically requires these elevated privileges.

The operating system running on your server is paramount. Since `.deb` packages are designed for Debian-based systems, your server should ideally be running Debian, Ubuntu, or a derivative thereof. Attempting to install `.deb` packages on Red Hat-based systems (like CentOS or Fedora) or other distributions will not work directly and can lead to system instability.

Familiarity with basic Linux command-line operations is also crucial. Knowing how to navigate directories (`cd`), list files (`ls`), download files (`wget` or `curl`), and check process status (`systemctl` or `ps`) will make the installation process smoother and aid in troubleshooting.

When choosing your hosting environment, the flexibility to manage `.deb` packages points towards specific types of solutions. A VPS provides you with a virtualized operating system and full root access, giving you complete control over software installations, including custom `.deb` files. Similarly, a dedicated server offers the ultimate level of control and resources, making it an ideal environment for complex deployments that involve numerous custom packages. Cloud instances, often built on virtualized infrastructure, also typically provide the necessary root access and flexibility for these tasks. Shared hosting, conversely, rarely offers the administrative control required for manual `.deb` package installations.

The Core Methods: How to Install a .deb Package

Installing a `.deb` package primarily involves two command-line tools: `dpkg` and `apt`. While both serve the purpose, they handle dependencies differently, which is a critical distinction for server administrators.

Method 1: The `dpkg` Command – Direct Package Management

`dpkg` is the foundational package management system for Debian-based distributions. It directly handles `.deb` package files. This method is straightforward for single packages but has a notable limitation: it does not automatically resolve dependencies. If your `.deb` package relies on other software components that are not already installed on your system, `dpkg` will alert you to missing dependencies and fail to install.

To install a `.deb` package using `dpkg`, first, ensure you have the `.deb` file on your server. You can upload it via SFTP or download it using `wget` or `curl`. Let’s assume your package is named `my-custom-app_1.0.0_amd64.deb` and is located in your current directory.

To install it:

sudo dpkg -i my-custom-app_1.0.0_amd64.deb

If the installation fails due to missing dependencies, `dpkg` will output an error message listing them. You would then manually need to install these missing dependencies, often using `apt`.

To remove a package installed with `dpkg`:

sudo dpkg -r my-custom-app

This command only removes the package itself, leaving configuration files behind. If you want to remove configuration files as well, use `dpkg -P`.

Method 2: The `apt` Command – Resolving Dependencies Automatically

The `apt` (Advanced Package Tool) command is a higher-level tool that interacts with `dpkg` but adds crucial functionality, most notably automatic dependency resolution. When installing a local `.deb` file, `apt` will not only install your package but also attempt to download and install any missing dependencies from the configured repositories. This significantly simplifies the process for packages with complex dependency trees.

To install a local `.deb` package using `apt`:

sudo apt install ./my-custom-app_1.0.0_amd64.deb

Notice the `./` before the package name. This explicitly tells `apt` to look for a local file in the current directory, rather than searching repositories.

If you encounter dependency issues after a failed `dpkg` installation, or if your system somehow ends up with broken dependencies, `apt` can often fix these problems:

sudo apt --fix-broken install

This command attempts to correct a system where packages have unmet dependencies, often by installing missing ones or removing conflicting ones. It’s an invaluable tool for recovering from botched installations.

Verifying Installation and Service Management

After installation, it’s crucial to verify that the software is correctly installed and, if it’s a service, that it’s running as expected.

To list installed packages and check if your package is present:

dpkg -l | grep my-custom-app

If your package is a daemon or service (like a web server, database, or custom agent), you’ll likely manage it using `systemctl` on modern Debian/Ubuntu systems.

To check the status of a service:

sudo systemctl status my-custom-app-service

To start, stop, or restart a service:

sudo systemctl start my-custom-app-service
sudo systemctl stop my-custom-app-service
sudo systemctl restart my-custom-app-service

Ensuring these steps are followed will confirm the integrity of your installation and allow you to manage the lifecycle of your newly deployed software.

Real-World Implementation Example: Deploying a Custom Analytics Agent

Let’s consider a practical scenario for “InsightMetrics,” a burgeoning SaaS startup specializing in real-time user behavior analytics. InsightMetrics provides its clients with a proprietary analytics agent that needs to run directly on the clients’ backend servers or VPS instances to collect low-level system metrics and application-specific data. This agent is delivered as a `.deb` package because it’s not open-source, requires specific system dependencies (some standard, some custom to InsightMetrics’ stack), and needs to integrate deeply with the client’s operating system for optimal performance.

Business Challenge

InsightMetrics faces the challenge of ensuring a secure, consistent, and reliable deployment of their custom agent across a diverse range of client server environments, typically Ubuntu 20.04 or 22.04 LTS. This agent isn’t available in public repositories, so clients must manually install it. The key is to provide a process that minimizes potential conflicts, handles dependencies gracefully, and allows for straightforward updates.

Step-by-Step Walkthrough of Installation

1. Receive the Package: InsightMetrics provides the client with a secure download link for `insight-metrics-agent_1.2.0_amd64.deb` and its corresponding GPG signature file (`.asc`) for verification.

2. Log in via SSH: The client connects to their dedicated server or netherlands vps using SSH with a user account that has `sudo` privileges.

ssh user@your-server-ip

3. Download the .deb Package and Signature: The client uses `wget` to download the package and its signature file to a temporary directory, for example, `/tmp/`:

cd /tmp/

wget https://cdn.insightmetrics.com/insight-metrics-agent_1.2.0_amd64.deb

wget https://cdn.insightmetrics.com/insight-metrics-agent_1.2.0_amd64.deb.asc

4. Verify Package Integrity and Authenticity: This is a critical security step. The client imports InsightMetrics’ public GPG key (if not already present) and verifies the package signature. This ensures the package hasn’t been tampered with and truly originates from InsightMetrics.

gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys A1B2C3D4E5F6G7H8 (Example key ID)

gpg --verify insight-metrics-agent_1.2.0_amd64.deb.asc insight-metrics-agent_1.2.0_amd64.deb

A “Good signature” message confirms authenticity.

5. Install the .deb Package with `apt`: The client uses `apt` to handle the installation and resolve any standard dependencies automatically.

sudo apt update (Ensures local package lists are up-to-date)

sudo apt install ./insight-metrics-agent_1.2.0_amd64.deb

`apt` will prompt to install necessary dependencies like `libpq-dev` or `python3-requests` if they are not already on the system.

6. Initial Configuration: The agent, once installed, might require an API key or specific configuration details unique to the client. This typically involves editing a configuration file, for example, `/etc/insight-metrics/agent.conf`.

sudo nano /etc/insight-metrics/agent.conf

Here, the client would paste their unique API key and specify any custom data collection parameters.

7. Start and Enable the Service: After configuration, the agent service needs to be started and enabled to run on boot.

sudo systemctl start insight-metrics-agent

sudo systemctl enable insight-metrics-agent

8. Verify Service Status: The client checks if the agent is running correctly.

sudo systemctl status insight-metrics-agent

Output should show “active (running)”.

Operational Considerations

* Log Files: InsightMetrics instructs clients to monitor `/var/log/insight-metrics/agent.log` for any operational issues or data transmission errors.
* Updates: When InsightMetrics releases a new agent version, they provide a new `.deb` package. Clients can upgrade by simply running `sudo apt install ./new-insight-metrics-agent_1.3.0_amd64.deb`. `apt` is intelligent enough to handle the upgrade, preserving configuration files unless specifically told otherwise.
* Rollback: In case of issues with a new version, `sudo apt install ./old-insight-metrics-agent_1.2.0_amd64.deb` can downgrade, or `sudo apt remove insight-metrics-agent` followed by installing the desired version can serve as a more aggressive rollback. This highlights the importance of keeping older, verified `.deb` packages accessible.

This scenario demonstrates how direct `.deb` installation, when managed carefully, provides the necessary flexibility for deploying specialized, off-repository software critical to a business’s operations, leveraging the control offered by a robust hosting solution.

Debian Package Installation vs. Other Deployment Strategies

Choosing how to deploy software on your server is a strategic decision that impacts performance, security, scalability, and ease of management. While direct `.deb` installation offers specific advantages, it’s crucial to compare it against other common deployment strategies to understand when it’s the right fit.

Direct .deb Installation

This method involves manually downloading and installing `.deb` files using `dpkg` or `apt`.

* Performance: Generally excellent, as the software is installed natively on the host system, leveraging direct access to hardware and kernel resources with minimal overhead.
* Security: Highly dependent on the source of the `.deb` package. If from a trusted vendor and verified, it can be secure. Untrusted sources pose significant risks due to direct system integration.
* Cost: Primarily involves the time and expertise of the administrator. No additional software licenses or significant resource overhead are typically incurred for the deployment mechanism itself.
* Scalability: Low for large, dynamic fleets. Manual installation is labor-intensive per server. Automation tools (Ansible, Puppet) can mitigate this but add complexity.
* Ease of Management: Medium. Simple for single packages, but dependency hell can complicate things. Updates require manual intervention or specific repository configurations.
* Recommended Use Cases: Deploying proprietary software not in official repositories, niche internal tools, specific versions of software required for compatibility, small-to-medium deployments on a VPS or dedicated server where fine-grained control is desired.

Using Official Repository Packages (`apt install` from repositories)

This is the standard way to install software on Debian/Ubuntu, fetching packages from configured repositories.

* Performance: Excellent, native installation with high stability and optimization from distribution maintainers.
* Security: Very high. Packages are rigorously vetted, signed, and regularly updated for security vulnerabilities by the distribution maintainers.
* Cost: Free and highly integrated into the system. Minimal operational cost due to automated updates.
* Scalability: High. Simple commands update entire systems, making it easy to maintain consistent software versions across many servers.
* Ease of Management: High. Automatic dependency resolution, simple update process (`apt upgrade`), and well-documented packages.
* Recommended Use Cases: The vast majority of standard server software (web servers, databases, programming languages, system utilities), ensuring stability, security, and ease of maintenance for most applications.

Containerization (e.g., Docker)

Deploying applications within isolated containers using tools like Docker.

* Performance: Good, but with a slight overhead compared to native installations due to containerization layers. Offers consistent performance across environments.
* Security: High due to isolation. Applications run in sandboxed environments, limiting potential impact of breaches. However, the security of the base image is critical.
* Cost: Can involve slightly higher resource consumption (CPU/RAM) due to the container runtime. Management complexity can add to operational costs if not properly tooled.
* Scalability: Excellent. Containers are lightweight, portable, and designed for rapid scaling and deployment across cloud environments or Kubernetes clusters.
* Ease of Management: High for deployment and scaling, but initial setup and orchestration can be complex. Provides excellent dev/prod parity.
* Recommended Use Cases: Microservices architectures, applications with complex or conflicting dependencies, ensuring consistent environments across development, testing, and production, high-availability setups, and rapid deployment needs.

Compiling from Source

Downloading source code and building the application directly on the server.

* Performance: Potentially the highest, as software can be optimized for the specific server hardware and operating system.
* Security: Full control over the source code allows for auditing, but also places the burden of vetting and patching entirely on the administrator.
* Cost: Very high in terms of administrator time and expertise. Requires significant effort to manage dependencies, build tools, and maintain.
* Scalability: Very low. Highly manual, error-prone, and difficult to reproduce across multiple servers without extensive automation.
* Ease of Management: Low. No integrated package manager for updates or dependency resolution; everything is manual.
* Recommended Use Cases: Extremely niche software, bleeding-edge versions not yet packaged, specific performance optimizations for highly resource-intensive applications, or when security auditing requires full source code control for a premium hosting setup.

In summary, direct `.deb` installation occupies a valuable niche between the ease of repository installations and the complexity of source compilation, offering more control than the former and less overhead than the latter. Containerization, while more complex initially, offers superior scalability for modern, distributed applications.

Common Deployment Mistakes and How to Avoid Them

While installing `.deb` packages provides flexibility, several common pitfalls can turn a straightforward task into a troubleshooting nightmare. Awareness and preventive measures are key to smooth server operations.

Ignoring Dependencies

This is perhaps the most frequent mistake. A `.deb` package rarely stands alone; it relies on other libraries and packages to function. Using `dpkg -i` without considering dependencies almost guarantees failure for anything beyond the simplest applications.

* How to Avoid: Always prefer `sudo apt install ./package-name.deb` for local `.deb` files. `apt` will automatically try to resolve and install missing dependencies from your configured repositories. If `apt` itself reports unresolvable conflicts, investigate the specific versions required or seek alternative package versions.

Untrusted Sources

Downloading and installing a `.deb` package from an unknown or unverified website is a significant security risk. Malicious packages can contain malware, backdoors, or compromise your server’s integrity.

* How to Avoid: Only download `.deb` packages from official vendor websites, trusted repositories, or sources with clear GPG signatures. Always verify the package’s GPG signature if one is provided (as demonstrated in the InsightMetrics example). If no signature is available, perform checksum verification (MD5, SHA256) and exercise extreme caution. For crucial business applications, consider hosting solutions that prioritize security, potentially even opting for offshore hosting with stringent compliance.

Permissions Issues

Attempting to install system-wide software without `sudo` privileges, or facing issues where the installed application cannot write to its log files or access resources due to incorrect file permissions, is a common operational hurdle.

* How to Avoid: Always prepend `sudo` to commands that modify system files or install software (`dpkg -i`, `apt install`). After installation, if a service fails to start, check its log files (often in `/var/log/`) and ensure the user it runs as has appropriate read/write permissions for its configuration and data directories. Use `chmod` and `chown` carefully when necessary.

Lack of Staging Environment

Deploying a new `.deb` package directly onto a production server without prior testing can lead to unexpected outages, conflicts with existing software, or performance degradation.

* How to Avoid: Always test new software installations, especially custom `.deb` packages, in a non-production or staging environment that closely mirrors your production setup. A dedicated development VPS or a cloud instance can serve this purpose effectively. This allows you to identify and resolve issues without impacting live services.

Neglecting Updates and Rollbacks

Failing to have a plan for updating custom `.deb` packages or a strategy to revert to a previous working version in case of issues can leave your system vulnerable or difficult to recover.

* How to Avoid: Keep track of the versions of custom `.deb` packages installed. Subscribe to vendor announcements for updates and security patches. For critical software, maintain a repository of known good `.deb` versions for easy rollback. Understand how `apt remove` and `dpkg -r` work, and how they interact with configuration files, to ensure a clean removal or downgrade if needed.

When Manual .deb Installation Isn’t the Optimal Approach

While direct `.deb` package installation offers significant control, it’s not always the best solution. Understanding its limitations helps in selecting the most appropriate deployment strategy for your specific needs.

Manual `.deb` installation is generally *not* the optimal approach in these scenarios:

* When the Software is in Official Repositories: If the application you need is readily available through your operating system’s official `apt` repositories, always prioritize that method. It offers superior security, automatic dependency handling, easier updates, and better system integration. Opting for a `.deb` package when a repository version exists often introduces unnecessary management overhead and potential security risks.
* For Highly Dynamic, Auto-Scaling Environments: In modern cloud architectures where applications need to scale up and down rapidly, or when managing hundreds or thousands of instances, manual `.deb` installation on each server is impractical and error-prone. Containerization technologies like Docker and orchestration platforms like Kubernetes are designed for these scenarios, providing immutable infrastructure and consistent deployments.
* When Lacking Server Administration Expertise: If you or your team do not possess strong Linux server administration skills, manual `.deb` installation can quickly become overwhelming, especially when troubleshooting dependency issues or service configurations. In such cases, managed hosting services, platform-as-a-service (PaaS) solutions, or simpler deployment methods are preferred, as they offload much of the server management burden.
* For Very Small, Static Websites: If your hosting needs are limited to a simple static website or a basic blog, shared hosting or specialized wordpress hosting is usually sufficient. These environments abstract away server-level package management, as you typically interact only with content management systems or static files. Manual `.deb` installation is entirely irrelevant here.
* When Cross-Platform Compatibility is a Major Concern: If your application needs to run consistently across various Linux distributions (Debian, CentOS, Alpine, etc.) or even different operating systems, relying on `.deb` packages will limit you to Debian-based systems. Containerization or language-specific package managers (like Python’s `pip` or Node.js’s `npm`) offer more portable solutions.

In essence, while direct `.deb` installation provides a powerful lever for server customization, it requires a conscious trade-off between control and convenience. For most standard applications, or environments demanding high scalability and automation, more integrated or abstracted solutions are often superior.

Operational Considerations: Maintaining .deb-Installed Software

Deploying a `.deb` package is just the beginning. The ongoing operational maintenance of that software is crucial for its long-term stability, security, and performance within your hosting environment.

Updates and Security Patches

Unlike software installed from official repositories that receive automated security updates, manually installed `.deb` packages often fall outside this automated cycle. This means you must proactively track vendor releases, security advisories, and bug fixes for your custom software. Failing to do so can leave your system vulnerable to exploits or running on outdated, inefficient versions. Establish a clear process for monitoring updates, downloading new `.deb` files, and performing upgrades in a controlled manner, ideally after testing in a staging environment.

Monitoring and Logging

Any application, especially a critical custom service installed via a `.deb` package, needs robust monitoring. Ensure the service is correctly configured to log its activities and errors to a standard location (e.g., `/var/log/my-custom-app/`). Integrate these logs into your server’s centralized logging system (like rsyslog or journald) and your broader monitoring solution (Prometheus, Nagios, ELK stack). This allows you to track application health, resource usage, and swiftly identify any operational anomalies. On a Netherlands VPS, having strong logging allows for quick identification of issues affecting latency or data processing, which is crucial for European-centric services.

Backup and Recovery

Your backup strategy must account for custom `.deb` installed software. This includes backing up the `.deb` package itself (if it’s not easily re-downloadable), its configuration files (typically in `/etc/`), and any associated data directories (e.g., databases, user-uploaded files). A comprehensive backup solution for your dedicated server or VPS should cover the entire operating system image or at least critical application directories, allowing for a swift recovery in the event of data loss or system failure.

Performance Impact

Custom applications, particularly those installed outside of typical repository optimizations, can have a significant impact on your server’s performance. Monitor CPU, memory, disk I/O, and network usage closely after deploying new `.deb` packages. Ensure that your hosting resources (CPU cores, RAM, SSD storage) are sufficient to handle the demands of your custom software alongside other services. An under-resourced server can lead to slow application response times, system instability, and a poor user experience. Performance considerations are especially vital for high-traffic applications hosted on a Premium Hosting solution.

Practical Recommendations for Technical Decision-Makers

Navigating software deployment requires a balanced approach, especially when custom `.deb` packages enter the equation. Here are practical recommendations for technical leaders and server administrators:

1. Prioritize Official Repositories First: Before considering a custom `.deb` package, always verify if the desired software or a suitable version exists in your operating system’s official repositories. This path offers unparalleled stability, security, and ease of maintenance.
2. Use `.deb` for Specific, Verified Custom Needs: Reserve direct `.deb` installation for legitimate scenarios where standard repositories don’t meet your requirements – such as proprietary software, very specific version dependencies, or internally developed tools. Always ensure the package source is reputable and ideally cryptographically signed.
3. Invest in Automation for Multiple Deployments: If you manage multiple servers requiring the same custom `.deb` package, manual installation is a bottleneck. Implement configuration management tools like Ansible, Puppet, or Chef to automate the deployment, configuration, and update processes. This ensures consistency and reduces human error.
4. Always Test in Non-Production Environments: Establish a robust staging or development environment that mirrors your production setup. This is non-negotiable for testing new `.deb` installations, configurations, and updates before they impact live services.
5. Understand Your Hosting Environment’s Flexibility: Ensure your chosen hosting solution, such as a VPS or a dedicated server, provides full root access and the necessary control for manual package management. Shared hosting environments are generally unsuitable for this level of customization.
6. Consider the Total Cost of Ownership: Beyond the initial installation, factor in the ongoing costs of maintaining custom software, including security monitoring, manual updates, troubleshooting, and potential custom dependency management. Sometimes, adopting a slightly different, repository-available tool can save significant long-term operational expense.
7. Embrace a Security-First Mindset: Every `.deb` package you install from outside official repositories introduces a potential security vector. Implement strict controls over who can install software, where packages are sourced from, and how their integrity is verified. This diligent approach is especially important for sensitive applications running on Premium Hosting.

Frequently Asked Questions about .deb Package Installation

What is the primary difference between `dpkg -i` and `apt install ./` for a local .deb file?

The core difference is dependency handling. `dpkg -i` will attempt to install the package but will fail if any of its dependencies are not already met on your system, requiring you to manually resolve them. `apt install ./` (note the `./` for local files) will automatically attempt to locate and install any missing dependencies from your configured APT repositories, making the process much smoother for packages with complex requirements.

Can I install a .deb package on a CentOS or Fedora server?

No, `.deb` packages are specifically designed for Debian-based systems like Debian and Ubuntu. CentOS and Fedora use `.rpm` packages and a different package management system (DNF/YUM). Attempting to install a `.deb` package directly on these systems will not work and can lead to system instability.

How do I verify the integrity of a .deb package before installing it?

Always try to verify the package against a GPG signature provided by the vendor. Download both the `.deb` file and its `.asc` signature file, import the vendor’s public key, and then use `gpg –verify package.deb.asc package.deb`. Additionally, you can check checksums (MD5, SHA256) if provided, comparing them to the downloaded file’s checksum using tools like `md5sum` or `sha256sum`.

What if a .deb package installation fails due to a “broken package” or “unmet dependencies” error?

If you used `dpkg -i` and encountered dependency issues, the best next step is to try `sudo apt –fix-broken install`. This command attempts to resolve any broken dependencies on your system, often by installing missing packages or removing conflicting ones. After fixing, you can retry `sudo apt install ./your-package.deb`.

How can I uninstall a .deb package I’ve installed?

You can remove a package using `sudo apt remove package-name`. This command will uninstall the software but typically leave behind configuration files. If you want to completely purge the package and its configuration files, use `sudo apt purge package-name`.

Is it possible to downgrade a .deb package if a new version causes issues?

Yes, if you have access to the older `.deb` file, you can install it using `sudo apt install ./old-version.deb`. APT will recognize that you’re installing an older version and will typically prompt you to confirm the downgrade. It’s good practice to keep older, verified `.deb` packages available for such scenarios.

Navigating Software Deployment: Installing .deb Packages on Your Server