OpenSIPS APT and YUM Repositories Are Moving to GitHub Actions

We are pleased to announce a major refresh of the official OpenSIPS package repository infrastructure.

The repositories available at:

• apt.opensips.org
• yum.opensips.org
• download.opensips.org

are now served by a completely new repository and package-building system.

Although the public addresses remain unchanged, the infrastructure behind them has been replaced. Existing configurations that reference these standard OpenSIPS domains will therefore use the new repositories.

What happened to the previous repositories?

The former repository infrastructure has been moved to dedicated legacy addresses:

• legacy.apt.opensips.org
• legacy.yum.opensips.org
• legacy.download.opensips.org

These repositories will remain operational until the end of October 2026, providing a temporary fallback during the transition.

However, they should not be used for new installations or as the default source for package updates. Their purpose is strictly to provide a safety net in case an issue is discovered in the new infrastructure.

Unless you are troubleshooting a specific migration problem, please continue using the standard apt.opensips.org, yum.opensips.org and download.opensips.org addresses.

Updated distribution support

The migration also refreshes the list of Linux distributions for which OpenSIPS packages are built.

On the APT side, support has been added for Debian 13 (Trixie) and Ubuntu 26.04 (Resolute Raccoon). At the same time, the obsolete Debian 10 (Buster) and Ubuntu 18.04 (Bionic Beaver) builds have been removed.

On the YUM side, the repository now includes packages for Enterprise Linux 10 and CentOS Stream 10. Support for the end-of-life Enterprise Linux 7 platforms—including RHEL 7, CentOS 7 and Oracle Linux 7—and for CentOS Stream 8 has been removed.

Fedora packages are no longer generated by the new repository infrastructure. There appeared to be relatively little demand for them compared with the maintenance effort required by Fedora’s short release cycle. Should sufficient interest arise, Fedora support can certainly be added again, either by the OpenSIPS project or through a community contribution.

The APT and YUM repository websites have also been adapted to the new layout and now provide the authoritative list of supported distributions, OpenSIPS versions and available repository components.

This change allows us to focus the build and testing infrastructure on platforms that are still relevant and maintainable, rather than continuing to generate packages for operating systems that have already reached the end of their supported lifecycle.

Users who must temporarily maintain an installation on one of the removed platforms may still retrieve the previously generated packages from the corresponding legacy repository until the end of October.

The cli-nightly component has been removed

The standalone cli-nightly repository component no longer exists.

Previously, installing development builds of both OpenSIPS and OpenSIPS CLI could require enabling two separate repository components. This duplicated repository configuration without providing a meaningful benefit.

With the new layout, the opensips-cli package is published directly inside each OpenSIPS repository. Whether you are using a stable release repository or a nightly OpenSIPS repository, the corresponding repository also provides OpenSIPS CLI.

This means there is no longer any need to configure a separate repository solely for opensips-cli.

Users who currently have a cli-nightly entry in their APT configuration should remove it and obtain opensips-cli from the same OpenSIPS repository they already use for the server packages.

Package builds are now managed through GitHub

The new repository infrastructure is maintained in the public OpenSIPS/opensips-repo GitHub repository.

Package generation is automated using GitHub Actions. The repository contains the definitions and workflows used for building and publishing the OpenSIPS packages.

Moving this process to GitHub provides a much more transparent way of managing the official repositories:

• packaging changes are tracked through Git history;
• build definitions can be reviewed by the community;
• changes can be proposed and discussed through pull requests;
• automated build executions and their results are visible;
• the complete packaging process is easier to reproduce, audit and maintain.

This brings the package repositories closer to the development model already used by the rest of the OpenSIPS project and makes their maintenance less dependent on undocumented, privately managed infrastructure.

Reporting migration problems

The new repositories have been tested before the migration, but the number of supported distributions, OpenSIPS branches, modules and external dependencies makes it possible that some edge cases were not identified beforehand.

Should you encounter missing packages, dependency issues, repository metadata errors, signature problems or any other unexpected behaviour, please report the problem on the OpenSIPS development mailing list as soon as possible:

devel@lists.opensips.org

Please include the following information in your report:

• the Linux distribution and version;
• the configured OpenSIPS repository and component;
• the OpenSIPS version or branch;
• the package being installed or upgraded;
• the complete command output and relevant error messages.

The legacy repositories are available as a temporary fallback, but switching to them without reporting the original problem prevents us from identifying and correcting issues in the new infrastructure. Please report the issue first, even when the legacy repository provides an immediate workaround.

Acknowledgements

The new repository infrastructure was fully implemented by Nick Altmann. Many thanks to Nick for building a more modern, transparent and maintainable packaging system for OpenSIPS.

We encourage all OpenSIPS users to begin using and testing the new repositories immediately and to report any problems they encounter.