CGRateS puts real-time charging for telecom traffic in Go microservices

Charging decisions made while the call is still running

CGRateS is described as a real-time Online/Offline Charging System, or OCS, for telecom and ISP environments. That is a narrower job than a general billing system, and the distinction drives everything else about the project. A wholesale voice and data operator needs to answer a question while traffic is in flight: does this subscriber have balance, what does this minute cost, and what should the switch do next. Handling that decision before the fact is what separates a charging engine from a revenue platform that reconciles a bill at the end of the month.

The users are therefore infrastructure teams and network engineers, not finance staff. The feature list names the concrete jobs: account balances management with bundle support, session or event charging with reservation, a rating engine, CDR logging with support for Interim Records, QoS LCR and LCR over Bundles, fraud detection with automatic mitigation, and call statistics with pattern monitoring.

Two claims in that list deserve plain reading. Performance is stated as 5000+ req/sec on a single machine, which is a documented figure rather than an independent measurement, and commercial support is offered alongside the open source code, which is common in operator-facing projects where someone has to answer the phone during a billing window.

A repository of services, not one program

The top level layout explains the design better than any diagram would. Directories such as accounts, cdrs, chargers, sessions, rates, stats, thresholds, ees, ers, ips, resources, rankings, trends, analyzers, migrator, loaders and actions each stand for a slice of behaviour, and the README calls the system modular with a cloud-ready design built on independent micro-services exposing a rich set of RPC APIs.

That shape has practical consequences. Each service owns its data and its own lifecycle, so a deployment can be assembled from the pieces an operator actually needs rather than shipping everything at once. The plug-able and non-intrusive claim in the feature list follows from the same structure: the intent is to sit next to an existing switch and signalling stack rather than to replace it.

The tree also shows the operational scaffolding around the services. There is a config directory, a console and an rpcconsole, a servmanager for process supervision and packages directories, and a debian directory that explains the presence of the Debian apt-get repository referenced in the README. Migration lives in migrator, which is a hint that schema and stored data are expected to change over the life of an installation.

The RPC surface is where CGRateS meets the rest of the network

The dependency list in go.mod is where the integration story becomes concrete, and it is unusually varied. Communication can run over birpc, with rpcclient and kamevapi as the client-side pieces, or over fsock for a file socket style interface. Carrier signalling is covered by go-diameter for Diameter and by radigo for RADIUS, while SIP work is backed by sipingo and emiago/sipgo, with voiceblender-go for media handling.

Message transport comes from nats-server and nats.go, and there is a NATS dependency in the tree even though the README does not describe which services publish or subscribe to it. Storage is a mix too: bleve for search, redis client libraries, and an elastic transport module. The module requires Go 1.27.2, and the replace directives for radigo and rpcclient show that those two can be swapped for local checkouts during development.

The practical reading is that CGRateS is meant to be attached to a signalling path that already exists. If your network does not emit Diameter, RADIUS, SIP or the file socket events the interfaces expect, you would be writing the glue yourself.

Getting it onto a Debian box and finding the rest of the documentation

The README does not give a copy and paste install command, it points to the documentation instead. There is a Debian apt-get repository described on the installation page, browsable HTML docs hosted on readthedocs, and a PDF, Epub and Manpage download set. For developers and testers, the project links an asciinema recording titled Installing CGRateS from sources on minimal debian, which is the closest thing to a written walkthrough. The API reference lives on godoc under the apis package of the main module.

The module definition itself is short enough to show in full, and it is the file to check first when you are sizing a build environment:

module github.com/cgrates/cgrates
go 1.27.2

Read that as a requirement rather than an invitation. A Go 1.27.2 toolchain is needed to build from source, and the module graph pulls in a long dependency list, so a locked down build host with no outbound network access will need a vendoring or module proxy strategy decided in advance. The repository also carries shell entry points named build.sh, generate.sh, test.sh, calls_test.sh, integration_test.sh and flaky_test.sh, plus run_devel_docker.sh for a development container, and the README shows continuous integration workflows for build and integration tests.

Two ways to charge, and how they differ in practice

CGRateS offers both session or event charging with reservation, and both online and offline operation. The distinction is the core architectural choice an operator has to make, and the documentation summary is brief enough that it deserves to be read as a menu rather than a spec.

Session charging with reservation means the system commits and releases balance around a session, holding funds while the service runs. Event charging treats each rated event on its own. Online operation interleaves charging decisions with live traffic through the RPC interfaces. Offline operation leaves the switch to record usage and the platform to process it afterwards, using the CDR pipeline with Interim Records for partial updates during a long session.

Both paths exist in the same binary family, which is the point of a modular design: the same accounts, rates and cdrs services back either approach. The choice affects how much latency sits in the signalling path and how much you rely on the CDR reconciliation, and the README does not quantify either cost, so plan to validate the pattern that matches your switch behaviour. The QoS LCR and LCR over Bundles entries add a second dimension: least cost routing applied to quality of service classes, including bundle-aware routing.

AGPL-3.0, support contracts and the upgrade path

The licence is AGPL-3.0, and for a network operator that is the first due diligence item, ahead of any feature comparison. The AGPL family extends source disclosure obligations to software offered to users over a network. For a telecom platform that is usually deployed on your own infrastructure and operated by your own staff, the exposure is limited, but the moment you wrap a modified version in a service offered to customers, the obligations become a legal question rather than an engineering one. Read LICENSE.txt in the repository and take your own advice on the specifics; this is a signpost, not legal guidance.

Two mitigating factors sit alongside it. The README lists commercial support as available, and the project also publishes a CONTRIBUTING.md, which signals a maintained community process rather than a code drop.

On versions, the release history shows v0.10.4 from 2024-09-24, then v0.10.5 on 2026-07-24 and v0.11.0 on 2026-09-30. The gap between the 0.10.4 and 0.10.5 tags is close to two years, so an upgrade can mean a jump across a lot of change, and the 0.11.0 tag shows the project has moved into a new minor series. The last push was on 2026-10-19, which is recent enough that development is still landing between releases. Because the services share a schema, plan an upgrade as a data migration exercise with the migrator component in scope, not as a binary swap.

Editorial conclusion

Choose CGRateS when you run a telecom or ISP network, need online or offline charging with session reservations, and want to keep the existing mediation and signalling stack in place rather than replace it. Do not choose it for a small VoIP setup that only needs a rate table, and think twice before modifying it if the AGPL-3.0 terms conflict with how your organisation distributes hosted services. Verify three things first: that the go.mod requirements (Go 1.27.2 and the listed cgrates modules) match your build environment, which interface you will use for charging (the dependency list shows several candidates), and whether the release you pick lines up with the documentation version you read.

Frequently asked questions

Official sources

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