# docker_open5gs: a containerised 4G and 5G mobile core testbed > docker_open5gs assembles open5gs, Kamailio, the Osmocom HLR and MSC, srsRAN, UERANSIM and a supporting cast into a Docker Compose lab where you can run a 4G or 5G core network with VoLTE, VoNR and VoWiFi, either over real radios or entirely simulated over ZMQ. **herlesupreeth/docker_open5gs** — Docker files to run open5gs + IMS + eNB + gNB + NR-UE in a docker - Repository: https://github.com/herlesupreeth/docker_open5gs - Stars: 583 · Forks: 318 - Language: Shell - License: BSD-2-Clause - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/herlesupreeth-docker-open5gs ## A whole mobile network in a directory of Compose files Contrary to the name, the repository contains Docker files to deploy an over-the-air or RF simulated 4G and 5G network, and the component list reads like a mobile network engineer wrote it. The core network for both 4G and 5G is open5gs. IMS for VoLTE and VoNR comes from Kamailio, with OpenSIPS as an alternative IMS. The IMS HSS is pyhss, and there is the Osmocom HLR and the Osmocom MSC alongside it. On the radio side, srsRAN_4G provides the 4G eNB, 4G UE and 5G UE, srsRAN_Project provides the 5G gNB, and UERANSIM provides a gNB and UE pair. The 5G UPF is eUPF. The Sigscale OCS handles charging, and there is an Osmo ePDG with a Strongswan ePDG for the WiFi calling path, plus SWu-IKEv2 for the SWu interface. The topology is the interesting part. The 5G core is split into the standard network function containers, with amf/, ausf/, bsf/, nrf/, nssf/, pcf/, pcrf/, scp/, smf/ and udm/ style directories visible in the tree, and the 4G side has mme/, hss/, pcf/, pcrf/ and smsc/. The IMS side has separate directories per role, opensips_ims_icscf/, opensips_ims_pcscf/ and opensips_ims_scscf/, plus a separate rtpengine/ for the media. And sgwu/ and sgwc/ are there for the 5G system gateway, which is what a VoNR call needs. There is also a monitoring stack, with grafana/ and metrics/ directories, and a dns/ directory, which is the piece that makes the multi-host setups work since each service needs to resolve the others. The sim/ directory holds the SIM provisioning, and custom_deployments/ is where the variations live. The Compose files at the root are the entry points, and their names describe the scenarios. There is a sa-deploy.yaml for 5G standalone, sa-vonr-deploy.yaml for 5G voice, sa-vonr-ibcf-deploy.yaml for the same with an interworking gateway, and 4g-volte-deploy.yaml, 4g-volte-ocs-deploy.yaml, 4g-volte-opensips-ims-deploy.yaml and 4g-volte-vowifi-deploy.yaml for the 4G variants, plus oaienb.yaml and oaignb.yaml for the RAN side, nr-gnb.yaml and nr-ue.yaml, srsenb.yaml and srsenb_zmq.yaml, and a deploy-all.yaml. ## Prebuilt images, and the one thing you have to know about the tags You can either pull prebuilt images or build everything from source, and the prebuilt path is the fast one. The mandatory requirements are docker-ce at version 22.0.5 or above and docker compose at version 2.14 or above. The base images come from the GitHub Container Registry, and the pattern is the same for every component: pull from ghcr.io and then tag the image to the short local name the Compose files expect. ```bash docker pull ghcr.io/herlesupreeth/docker_open5gs:master docker tag ghcr.io/herlesupreeth/docker_open5gs:master docker_open5gs docker pull ghcr.io/herlesupreeth/docker_grafana:master docker tag ghcr.io/herlesupreeth/docker_grafana:master docker_grafana docker pull ghcr.io/herlesupreeth/docker_metrics:master docker tag ghcr.io/herlesupreeth/docker_metrics:master docker_metrics ``` The same pull and tag pair exists for the IMS components with docker_osmohlr, docker_osmomsc, docker_pyhss, docker_kamailio, docker_mysql and docker_opensips, for the srsRAN components with docker_srslte and docker_srsran, and for the UERANSIM, EUPF, Sigscale OCS, Osmo ePDG and SWu-IKEv2 components. The tagging is not cosmetic. The Compose files refer to the images by the short names such as docker_open5gs, and the pull is from a registry path that carries the master branch in it. So the image you run is a moving target tied to the master branch of the source tree, not a pinned release. That is fine for a testbed where you want the current state, and it is a real hazard for anything you intend to keep running, because a rebuild at an inconvenient moment can change what is underneath you. There are no GitHub releases in the repository, so there is no version to pin to, and the last push was on 2026-09-05. ## Building from source, one image per upstream project The alternative is to build the images yourself, and the structure of the build is one Dockerfile per upstream project, each in its own directory under base/. ```bash git clone https://github.com/herlesupreeth/docker_open5gs cd docker_open5gs/base docker build --no-cache --force-rm -t docker_open5gs . # Build docker image for kamailio IMS components cd ../ims_base docker build --no-cache --force-rm -t docker_kamailio . # Build docker image for srsRAN_4G eNB + srsUE (4G+5G) cd ../srslte docker build --no-cache --force-rm -t docker_srslte . # Build docker image for srsRAN_Project gNB cd ../srsran docker build --no-cache --force-rm -t docker_srsran . # Build docker image for UERANSIM (gNB + UE) cd ../ueransim docker build --no-cache --force-rm -t docker_ueransim . ``` The directories the build walks through are named after the upstream project they package: base for the open5gs EPC and 5GC components, ims_base for the Kamailio IMS components, srslte for srsRAN_4G, srsran for srsRAN_Project, ueransim for UERANSIM, eupf for the 5G UPF, and opensips_ims_base for the OpenSIPS IMS. The flags are worth noting. --no-cache forces a fresh layer every time rather than reusing the cached ones, and --force-rm removes the intermediate containers afterwards, which matters when you are building a dozen images in a row on a single host. There is an open5gs specific detail in the tree that the build reflects. The base directory is the open5gs EPC and 5GC one, and the rest sit alongside it under the repository root, which means the open5gs build is the one the others assume is present. ## Over the air with real radios, or simulated over ZMQ The tested setup section is where the hardware requirements are, and there are two distinct worlds. For over-the-air setups, the host machine needs Ubuntu 22.04 or above, and the radio combinations that have been tested are specific. The srsRAN_Project gNB works with an Ettus USRP B210, and also with LibreSDR, described as a USRP B210 clone. The srsRAN_4G eNB works with a LimeSDR Mini v1.3, with a LimeSDR-USB, and with LibreSDR. For the RF simulated setups there is no radio at all. srsRAN_4G provides the eNB and UE simulation over ZMQ, srsRAN_Project with srsRAN_4G provides the 5G gNB and 5G UE simulation over ZMQ, and UERANSIM provides a gNB and UE simulator. That distinction is the single most important decision you make when you start. The ZMQ path runs entirely in containers over a virtual link, so it needs no radio hardware and no spectrum, and it is the way to work on the core network behaviour. The over-the-air path needs SDR hardware, and a USRP or a clone, which is where most of the cost and most of the setup complexity lives. The over-the-air path is also what makes the project more than a simulator. Real radio gives you the timing behaviour and the measurement side of a 5G network, and the fact that the tested list is specific rather than open ended suggests the configuration combinations are narrow and worth checking before you commit to a hardware purchase. ## SIM provisioning across three different HSS implementations The part of the deployment that catches people out is that the subscriber data has to be provisioned in more than one place, and the README documents each of them separately. For provisioning SIM information in the open5gs HSS there is a dedicated section, and separately there is provisioning of IMSI and MSISDN with OsmoHLR, and provisioning of SIM information in pyHSS. And then, separately again, there is provisioning of Diameter peer and subscriber information in the Sigscale OCS, with a note to skip it if the OCS is not deployed. That is three HSS implementations in the same repository, each with its own data format, and the reason is that the deployment scenarios differ. A 4G VoLTE deployment with Kamailio IMS uses one set of subscriber data, a 5G deployment with Sigscale charging needs another, and the VoWiFi path through the ePDG needs its own because the device authenticates over the untrusted WiFi network using a different procedure. The topology also has a Single Host setup and a Multihost setup, with the multihost section split into 4G deployment and 5G SA deployment. The distinction is about where the components run, and the dns/ directory exists to make the cross-host addressing work. The VoWiFi section is the most involved, because it is the only one that involves a device you do not control. It covers the pre-requisites, deploying the required components, provisioning the SIM and IMS subscriber information, and then a step you do not get in a container, which is manually configuring DNS settings on your phone for the WiFi connection so that the ePDG can be resolved, followed by the UE configuration. That manual DNS step on the phone is the clearest sign of where this project sits. Everything else is automated, and the one thing that is not is the part that touches a commercial handset, because a phone will only reach an ePDG it has been told to trust, and that cannot be pushed from a container. ## Conclusion docker_open5gs suits a telecom developer who needs a working 4G or 5G core network to test against without hardware, since the RF simulated setup over ZMQ and the UERANSIM simulator both remove the need for a USRP, and the prebuilt images mean you can have a core running before you build anything. It does not suit you as a production deployment, because the components are development versions of open source projects, and it does not suit you if you need a specific commercial core, since the whole point is the open source stack. Before you start, check the tested setup section for the radio combinations and the software version floors, and note that a full deployment means pulling a dozen separate images and provisioning SIM, IMSI and MSISDN data in each of the three different HSS implementations the project supports. ## FAQ ### What does docker_open5gs deploy? A 4G and 5G mobile network testbed: open5gs as the core network, Kamailio and OpenSIPS for IMS, pyHSS plus the Osmocom HLR and MSC for subscriber data, srsRAN_4G and srsRAN_Project for the radio, UERANSIM as a gNB and UE simulator, eUPF for the 5G user plane, the Sigscale OCS for charging, and an Osmo ePDG with Strongswan for VoWiFi. ### Do I need an SDR to use docker_open5gs? Not for the RF simulated setups, which run srsRAN and UERANSIM entirely over ZMQ in containers. The over-the-air setups need specific hardware: an Ettus USRP B210 or a LibreSDR for the 5G gNB, and a LimeSDR Mini v1.3, a LimeSDR-USB or a LibreSDR for the 4G eNB, on an Ubuntu 22.04 or above host. ### How do I get the Docker images for docker_open5gs? Either pull the prebuilt images from GitHub Container Registry and tag them to the short local names the Compose files expect, such as pulling ghcr.io/herlesupreeth/docker_open5gs:master and tagging it docker_open5gs, or build them yourself with docker build in each of the base, ims_base, srslte, srsran and ueransim directories. ### Why does the VoWiFi test with a real phone need manual DNS configuration? The documentation lists a step to manually configure DNS settings on your phone for the WiFi connection, because a handset will only reach an ePDG it has been told to trust, and that cannot be pushed from a container. Everything else in the deployment is automated. ## Sources - [herlesupreeth/docker_open5gs on GitHub](https://github.com/herlesupreeth/docker_open5gs) - [Issues](https://github.com/herlesupreeth/docker_open5gs/issues) - [License: BSD-2-Clause](https://github.com/herlesupreeth/docker_open5gs/blob/master/LICENSE) - [README](https://github.com/herlesupreeth/docker_open5gs/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/herlesupreeth-docker-open5gs