Ergo IRC Server: An IRCd With Services and Bouncer Built In

What Ergo Replaces On A Small IRC Network

A conventional IRC deployment is three or four programs pretending to be one service. You run an ircd, then a services package for nickname and channel registration, then a bouncer so a user can stay connected from a phone and a laptop at once, then something to store scrollback. Each has its own config, its own database, and its own upgrade cadence, and the seams between them are where things break. Ergo's stated design principle is to combine all of that in a single Go binary: the README lists integrated NickServ, ChanServ and HostServ, bouncer-like history storage and multi-client support, and SASL authentication as core features rather than add-ons.

The audience is the operator of a small or mid-sized network, or someone who wants a private server for a team or a community and does not want to assemble a stack. It is also useful as a reference implementation if you are writing IRC client code, since the project tracks IRCv3 specifications closely and runs a public testnet at testnet.ergo.chat on port 6697 with TLS and port 6667 in plaintext.

The trade-off embedded in that design is real. When services are part of the daemon, you cannot swap in a different services package, and the account model is not optional in the way a bolt-on services package is. Ergo leans on user accounts to enable features like multiple clients per nickname, so a network that wants to stay account-free is fighting the grain of the software.

How The Daemon Is Put Together

Ergo is a single Go binary. The repository root holds ergo.go as the entry point, with the protocol and server logic under the irc/ directory, translations under languages/, and distribution files under distrib/. Dependencies are vendored, so the README states you will not need to fetch anything remotely when building from source.

Configuration is a rehashable YAML file, meaning the server can reload it at runtime without a restart. That file also stores where the log, database, certificate and other files are opened. By default those are relative paths, and the README notes you can make them absolute, such as /var/log/ircd.log, when running Ergo as a service. Rehashing also covers TLS certificates, which matters if you use ACME or another short-lived certificate source and do not want a restart every renewal.

Persistence is pluggable. The go.mod file shows BuntDB as the default embedded store, with drivers for MySQL, PostgreSQL and SQLite present in the dependency list, and the Makefile defines a build tag set of i18n, mysql, postgresql and sqlite for what it calls the maximalist build. Passwords are stored with bcrypt, and the manual documents an oper privilege system, IP cloaking, connection limits, and UBAN as a unified ban mechanism covering IPs, networks, masks and registered accounts alongside KLINE and DLINE.

Installing Ergo And Connecting A First Client

The README's quick start assumes a release archive. Download the latest release, extract it into a folder, then copy the shipped default config and edit it. The default.yaml file is written as a guided document, so most of the first pass is reading comments and changing values rather than inventing keys.

cp default.yaml ircd.yaml
vim ircd.yaml  # modify the config file to your liking
./ergo mkcerts
./ergo run     # server should be ready to go!

The mkcerts subcommand generates the TLS material the server expects, and run starts the daemon. If you want the config somewhere else, the README documents a --conf parameter, for example ergo run --conf /path/to/ircd.yaml. Logs go to stderr by default, so on a first run you should watch that stream for startup errors rather than hunting for a log file.

For a container deployment, the repository ships a Dockerfile and an example docker-compose recipe in distrib/docker, and images are published to ghcr.io/ergochat/ergo. The image exposes 6667/tcp and 6697/tcp and keeps state in a volume mounted at /ircd. Note that the Dockerfile itself edits default.yaml during the build to bind port 6667 on all interfaces and to drop the IPv6 loopback listener, so the config inside the container is not byte-identical to the one in the repository.

Once you are connected, account registration is the step that unlocks the rest. The README gives the in-client command as /msg NickServ register <password>, and then recommends enabling SASL in your client so you are logged in automatically on each connection. Channel registration follows the same pattern: join with /join #channel, then register with /CS REGISTER #channel. After that the channel remembers its owner, its topic and its modes. Oper passwords are handled separately: run ergo genpasswd, which prints an encrypted blob you paste into the config.

Where Ergo Is The Wrong Tool

The first limitation is scale and federation. Ergo is a standalone server. Nothing in the README describes linking multiple Ergo instances into a single network, and the feature list is framed around running one server with integrated services. If your plan is a federated network of linked ircds, this is not the project for it, and the manual's productionizing section is about running a production network on systemd, not about inter-server links.

The second is migration cost. Ergo is a fork of Ergonomadic, and its config is its own YAML dialect. Anyone moving from InspIRCd or UnrealIRCd will find that the config file, the logging format and the ban model do not carry over. The README notes the logging configuration is inspired by InspIRCd's, which is a nod to familiarity, not compatibility.

The third is the account dependency. Because multiple clients per nickname and history replay are tied to accounts, a network that has historically allowed unregistered users to hold nicknames permanently will need to change its policy, and users will need SASL-capable clients. The README links to a manual section on the nick-equals-account problem, which is the project acknowledging this friction directly.

Finally, there is a build dimension: the Makefile defaults to the full tag set including MySQL, PostgreSQL and SQLite, but a build with no tags is available via make minimal. If you build minimal and then configure a SQL backend, the driver is not there. The build tags decide which databases exist in your binary.

Ergo Compared With A Traditional IRCd Plus Services

InspIRCd is the natural comparison, and the README itself references it twice: once for the logging config inspiration and once in the related ecosystem. The difference in approach is architectural. InspIRCd is a C++ daemon with a module system, and services such as Anope or Atheme run as separate processes that link to the ircd over a protocol. That separation gives you a module ecosystem and the ability to run services on a different host, at the cost of more moving parts and a network link between the two.

Ergo inverts that. Services are in-process, history storage is in-process, and the bouncer functionality is in-process. There is no services link to configure or monitor, and no separate services database to back up. The price is that extensibility is Go source rather than loadable modules, and that the whole stack upgrades together.

For a small network, the in-process model removes an entire class of operational failure. For a large one, or one with a long history of custom modules, the separate-services model is the more flexible arrangement. The choice is less about raw capability than about how many processes you want to own.

Licence, Maintenance And Upgrade Cost

Ergo is MIT licensed. That is permissive: you can run it commercially, modify it, and redistribute it, provided the copyright notice and permission notice are preserved. This is not legal advice, and if you are embedding Ergo in a product you should read the LICENSE file in the repository yourself rather than relying on a summary.

The project is not archived, and the last push was on 2026-09-01. Recent releases are v2.19.1 on 2026-08-05, v2.19.0 on 2026-07-21, and v2.19.0-rc1 on 2026-07-14. That cadence suggests release candidates are cut before stable tags, so operators who want the quiet path should track stable rather than master; the source build instructions explicitly say to run git checkout stable before make.

Upgrade cost is low in the binary sense and moderate in the config sense. Because the config is rehashable, TLS certificate and many setting changes do not require a restart. But the config file is also where paths, database location and listener bindings live, so a config that has drifted from default.yaml over several versions is the thing you will spend time on. The changelog is the place to check before jumping versions. Building from source is cheap because dependencies are vendored, but note that the default build is the full tag set; if you switch to make minimal you lose the SQL backends.

Editorial conclusion

Adopt Ergo if you are standing up a new IRC network or replacing a stack of separate daemons, and you are comfortable editing ircd.yaml and running it under systemd or Docker. Do not adopt it if you need a drop-in replacement for an existing InspIRCd or UnrealIRCd deployment, because the config format and the services model are different enough to force a rewrite. Before you commit, verify two things: that your client supports SASL, since Ergo leans on accounts for nickname ownership and history, and that the database backend you intend to use is actually compiled into your binary, because the build tags decide which ones exist.

Frequently asked questions

Official sources

1. ergochat/ergo on GitHub
2. License: MIT
3. Project website
4. README
5. Releases