Open5GS: a C 5G Core and EPC you build from source

What Open5GS replaces, and who ends up running it

Open5GS is a C implementation of the core network behind LTE and NR radio access. That core is the part that authenticates subscribers, tracks where they are, anchors their user plane traffic and hands them an IP address. In a commercial deployment this is a licensed product from a network vendor. Open5GS replaces it with source you can read, build and modify, targeting Release-19 in the v2.8.0 release.

The audience follows from that. It is not aimed at someone who wants a 5G network in an afternoon. It is aimed at research groups, private network integrators, test labs and vendors who need a core they can instrument. The repository carries a webui/ directory for subscriber administration, configs/ for the network function configuration, docker/ for container packaging and tests/ for the test suite. Those directories tell you what the project expects you to do: configure, run, and inspect.

The scope is deliberately both generations. The same project implements the 5G Core and the EPC, so an operator moving from LTE to NR does not have to run two unrelated codebases. That is a real advantage when you are testing interworking, and a real complication when a config key that means one thing in EPC means something adjacent in 5GC.

How the network functions fit together in the repository

Open5GS is not a single daemon. It is a set of network functions built from one tree, each with its own configuration, which is why configs/ is a directory rather than a file. A 5G Core deployment runs separate processes for the control plane functions and for the user plane function, and the EPC side runs its own set. They communicate over the service-based interfaces defined by 3GPP, which is what lets you scale or restart one function without taking down the others.

The build system is Meson, visible as meson.build and meson_options.txt at the top level, with subprojects/ for vendored dependencies. That matters for how you compile it: there is no autotools configure script to hunt for, and optional features are toggled through Meson options rather than environment variables. The lib/ directory holds shared code used across the network functions, and src/ holds the functions themselves.

Configuration is YAML, one file per function, read at startup. This is the part that determines whether your deployment works. Each function needs to know its own identity, the addresses of its peers, and which subscriber database to consult. There is no discovery layer that guesses these for you, so a mismatch between two config files produces a function that starts cleanly and then fails to attach a subscriber.

Installing Open5GS and getting a first function running

The README does not carry install steps. It points at the documentation hosted at open5gs.org and says to follow it there, so treat the project site as the authoritative source for platform-specific instructions. What the repository does show is the build path: Meson plus a C toolchain, with the Debian packaging under debian/ and container definitions under docker/.

The build system is Meson, declared by meson.build and meson_options.txt at the top level. The documentation at open5gs.org is where the exact configure and build invocations are given, and it is also where the option names from meson_options.txt are explained. Nothing in the README substitutes for that page.

After installation, each network function reads a YAML file from the configuration directory. The repository keeps the reference copies in configs/, and the documentation describes how they are installed and how a function is started with its config file. The thing to watch on a first run is not the process starting. It is the log line that tells you the function bound its interfaces and reached its peers. A core network function that cannot reach its subscriber database or its user plane peer will still run.

For a container-based first look, the docker/ directory holds the definitions used to package the functions. That path avoids the toolchain question entirely, at the cost of hiding which config file is actually in use.

Where Open5GS will cost you time

The honest limitation is operational, not functional. Open5GS gives you the network functions and a reference configuration. It does not give you a deployment. There is no orchestration layer in the repository, no automatic certificate rotation, and no upgrade path that migrates your running configuration. You build the release, you install it, and you reconcile your YAML against whatever changed.

That last point is the sharp edge. Because configuration is per-function YAML with no schema enforcement described in the README, a release upgrade can change what a key expects without failing at startup. The release notes are where you would look for that, and the README itself is silent on rollback. If you are running this in front of real users, you need your own procedure for reverting a function, because the project does not ship one.

AGPL-3.0 is the second constraint, and it is a design decision rather than an accident. If you modify Open5GS and let users interact with it over a network, the licence's network clause applies to your modified version. The README notes that commercial licences are available from NewPlane, which is the route organisations take when they cannot accept that obligation. This is not legal advice; it is the reason some teams pick a different core.

Finally, C means C. A malformed message that reaches a network function is a memory safety question, not an exception. That is a normal trade-off for this class of software, but it is worth stating plainly rather than discovering during a fuzzing run.

Open5GS compared with Free5GC and the RAN-side projects

The comparison people actually search for is Open5GS versus Free5GC, and the difference is language and packaging rather than protocol coverage. Free5GC is a Go implementation of the 5G Core. Go gives you a garbage-collected runtime and a single static binary per function, which simplifies container images and removes a class of memory bugs. Open5GS is C, which means you manage the toolchain and the memory model yourself, and in exchange you get a codebase that compiles to something small and links directly against C libraries you may already be using.

A second comparison is with the RAN projects: srsRAN and OpenAirInterface. That comparison is a category error, and it is worth saying so because the search data suggests people make it. Those projects implement the radio access network, the base station side. Open5GS implements the core. You do not choose between them; you connect them. The gNB or eNB speaks to the core over the 3GPP interfaces, and both sides have to agree on the release and the interface version.

Against Magma, the difference is architectural. Magma is built around a federated gateway model with an orchestrator, which suits distributed deployments across many small sites. Open5GS is a set of core network functions you place yourself. If your problem is managing hundreds of sites, the orchestration model is the point. If your problem is a lab or a single private network, that orchestration is overhead.

Maintenance, releases and what an upgrade actually involves

The repository is not archived and the last push was on 2026-09-23. The release cadence visible in the tags is roughly one minor release every few months: v2.7.6 in July 2025, v2.7.7 in March 2026, and v2.8.0 in June 2026. That is a project that ships, and the version numbering suggests patch releases land between the feature releases.

The upgrade cost is what the numbers do not tell you. Because configuration lives in YAML files that you have edited, an upgrade is a three-part job: build the new release, diff your configs against the reference copies in configs/, and restart the affected network functions in an order that does not break the interfaces between them. Nothing in the repository automates that. A team running a single lab core can do it by hand. A team running a production private network needs a config repository and a rollback plan of its own making.

The licence cost is a separate line. AGPL-3.0 covers the open source files, and the README states that commercial licences are available from NewPlane. Whether you need one depends on whether you distribute or network-expose a modified version. That determination is for your legal team, and it should be made before the code is in production rather than after.

Editorial conclusion

Adopt Open5GS if you need a core network you can read, patch and rebuild, and you have someone who can own a Meson build and a set of YAML configs. Do not adopt it if you need a vendor on the other end of a support contract, or if you cannot accept AGPL-3.0 obligations on a modified network service. Before committing, verify two things: that your target release, v2.8.0 for Release-19, covers the network functions you actually plan to run, and that the configs/ entries for those functions match the interfaces on your radios and your subscriber database.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. open5gs/open5gs on GitHub
3. Project website
4. README
5. Releases