Open5GS Helm Charts Collection
https://github.com/open5gs/open5gs
Introduction
Open5GS is an open source implementation of both the LTE EPC and the 5G core. In practice, that makes it useful as a research, lab, and private-network core because it covers the main control-plane and user-plane functions needed to stand up an end-to-end mobile network without depending on proprietary vendor software.
Compared with commercial cores, Open5GS is usually valued for accessibility and interoperability rather than for turnkey carrier operations. It is a strong fit when the goal is to learn 4G/5G core behavior, validate RAN integration, build a reproducible testbed, or run a modest private deployment with full control over the stack.
Deployment complexity
Deployment complexity is moderate.
At the low end, Open5GS can be brought up quickly on a single host by using distro packages, source builds, containers, or Helm charts. That makes it approachable for local testing with tools such as UERANSIM or small RAN setups.
At the high end, production-like deployment is more involved because the operator still needs to solve the surrounding system design:
- per-function configuration and address planning
- subscriber data management in MongoDB
- PFCP, GTP-U, DNS, routing, and NAT details
- separation of control plane and user plane across hosts
- certificates, service discovery, and upgrade strategy when service-based interfaces are distributed
Helm charts and container packaging reduce packaging effort, but they do not remove the telecom-specific integration work. Most of the real complexity comes from networking, subscriber provisioning, and interoperation across multiple functions rather than from the Open5GS binaries themselves.
Kubernetes deployment
Open5GS can be deployed on Kubernetes, and Kubernetes is a reasonable choice when the goal is repeatable packaging, easier lifecycle management, and integration with existing cloud-native tooling.
Kubernetes helps with:
- container scheduling and restart behavior
- declarative deployment through manifests or Helm charts
- secret and configuration distribution
- integration with Prometheus, Grafana, and GitOps workflows
The main caveat is that Kubernetes solves orchestration more than telecom networking. A working deployment still depends on careful handling of:
- MongoDB persistence and backup
- UPF placement and data-plane traffic paths
- PFCP, GTP-U, SCTP, and service exposure details
- node networking, MTU, and routing behavior
- external connectivity to the RAN and UE traffic breakout
For that reason, Kubernetes is often an excellent fit for labs, CI-style validation, and private-network platforms, but it should not be treated as making Open5GS automatically production-ready. The operational model still has to be designed around state, observability, and failure handling.
Operations and orchestration
Open5GS is operationally straightforward on a small footprint. The functions are individually configured, logs are readable, and the software works well in systemd-based, containerized, and Kubernetes-oriented environments.
Its orchestration model is relatively lightweight. Open5GS gives you network functions, interfaces, and configuration files, but it does not try to be a full operator platform. In practice, that means the deployment owner is still responsible for:
- lifecycle management and rolling upgrades
- high availability design
- secret management and certificate handling
- observability pipelines and alerting
- GitOps, backup, and failure-recovery procedures
This is an advantage in research environments because the system stays transparent. It is a disadvantage if the target is a highly automated carrier-style platform with strong built-in workflows for resilience and fleet management.
RAN integration
Open5GS integrates well with the lab and open-RAN ecosystem. It is commonly paired with UERANSIM for core validation and with projects such as srsRAN or OpenAirInterface (OAI) for end-to-end 5G SA experimentation. That makes it a practical anchor for teaching, prototyping, and testbed work.
RAN integration should still be treated as an interoperability exercise rather than a plug-and-play promise. Even when interfaces are standards-based, success depends on matching software versions, supported bands, UE behavior, handover expectations, and vendor-specific interpretations of procedures. Open5GS is therefore strongest when the operator is comfortable validating NGAP, GTP-U, PFCP, and subscriber-policy details during bring-up.
Feature emphasis
Open5GS emphasizes broad, usable core-network coverage over polished operator tooling. The project focuses on implementing the essential EPC and 5GC building blocks needed for realistic end-to-end deployments, including the main 4G/5G control functions, user-plane support, and service-based core interactions.
Its practical emphasis is:
- open and inspectable implementation of EPC and 5GC behavior
- compatibility with lab RAN stacks and reproducible test environments
- support for private-network and research workflows
- standards-oriented evolution, including ongoing 5GC feature work
It is less centered on carrier productization concerns such as deeply integrated orchestration, large-scale commercial assurance workflows, or a fully turnkey multivendor deployment experience. In other words, Open5GS is strongest as an open mobile-core foundation, not as a finished operator platform.
Reference List
- Open5GS GitHub repository: https://github.com/open5gs/open5gs
- Open5GS documentation portal: https://open5gs.org/open5gs/docs/
- Open5GS Introduction: https://open5gs.org/open5gs/docs/guide/01-quickstart/
- Open5GS metrics tutorial: https://open5gs.org/open5gs/docs/tutorial/04-metrics-prometheus/
- Open5GS release note describing the project as a Release-17 5GC/EPC implementation: https://open5gs.org/open5gs/release/2021/01/09/release-v2.1.3.html
- Barrachina-Muñoz, S., Payaró, M., & Mangues-Bafalluy, J. (2022, July). Cloud-native 5G experimental platform with over-the-air transmissions and end-to-end monitoring. In 2022 13th International Symposium on Communication Systems, Networks and Digital Signal Processing (CSNDSP) (pp. 692-697). IEEE.