Ergo

Self-hosted IRC infrastructure, honestly reviewed. What you actually get when you run your own IRC network in 2025.

TL;DR

• What it is: A modern IRC server (ircd) written in Go that combines the daemon, services framework (NickServ, ChanServ), and a built-in bouncer into a single binary [README].
• Who it’s for: Developers, open-source projects, and privacy-conscious communities that have already decided they want IRC — not people still deciding between IRC and something else.
• Cost: Free software (MIT license). Runs on a $5–10/mo VPS. No commercial tiers, no upsell, no cloud offering from the vendor [README][profile].
• Key strength: The all-in-one design eliminates the traditional three-piece stack (ircd + Atheme + ZNC) that made running an IRC network annoying. You get history, accounts, and multi-device support without separate daemons [README].
• Key weakness: This is IRC. Ergo is an excellent IRC server, but IRC’s UX ceiling is IRC’s UX ceiling. Third-party review data was not available in the sources provided for this article — the assessment below is based primarily on the official README and project profile.

---

What is Ergo

Ergo (formerly Oragono) is an IRC daemon written in Go. The pitch in the GitHub README is concise: “A modern IRC server (daemon/ircd) written in Go.” [README] The four design principles are equally plain: simple to set up, all-in-one (ircd + services + bouncer), bleeding-edge IRCv3 support, and high customizability via a reloadable YAML config [README].

What makes the “all-in-one” framing meaningful is that traditional IRC networks require three separate pieces of software running together: the ircd itself, a services framework like Atheme (which provides NickServ for account registration and ChanServ for channel management), and a bouncer like ZNC for users who want persistent connections and history replay. Ergo ships all three as a single process. NickServ, ChanServ, and HostServ are integrated. History storage and replay are built in. Multiple clients sharing a single nickname is a first-class feature, not a separate daemon you configure to proxy the connection [README].

The project sits at 3,142 GitHub stars with an MIT license [profile]. It was formerly called Oragono before a rename and is a fork of the older Ergonomadic IRC daemon [README]. A live test instance runs at testnet.ergo.chat for anyone who wants to kick the tires before deploying [README].

The IRCv3 support is worth noting separately: Ergo is listed as a reference implementation for IRCv3, the working group extending the IRC protocol with modern capabilities like message IDs, labeled responses, and chathistory [README]. If you’re running any IRC client that takes IRCv3 seriously, Ergo is as capable as the protocol itself allows.

---

Why people choose it

No third-party review sources specific to Ergo were available in the materials for this article, so this section is based on the project’s own documentation and observable design decisions — not synthesized from external opinions.

The practical argument for Ergo over competing ircds comes down to operational simplicity. The traditional self-hosted IRC stack involves deploying and maintaining at minimum two daemons — ircd plus services — and often a third (bouncer) if you want persistent connections for users. These daemons communicate over internal IRC connections, require their own configs and databases, and fail in non-obvious ways when they desync. Ergo collapses this into one process with one config file and one database [README].

The second argument is the IRCv3 feature set. Features that require either no standard client support or painful server-side workarounds in older ircds — message history, client certificates for SASL, proper UTF-8 nicks — are first-class in Ergo [README]. If your community uses modern IRC clients (Irssi with plugins, WeeChat, Hexchat, or any web client that speaks IRCv3), Ergo’s behavior is more predictable.

The third argument is the Go implementation. Ergo vendors all dependencies, so the build is a single static binary with no runtime dependency chain to manage. On Linux, you extract the release, edit one YAML file, run ./ergo mkcerts, and the server is up [README]. That’s a lower operational bar than services like InspIRCd with Anope, which require separate installations, separate configs, and proper linking between them.

---

Features

Based on the README:

Core IRC server:

• Standard IRC daemon with full channel and nick management [README]
• Rehashable (live-reload) YAML config — no restart required to update settings or rotate TLS certs [README]
• Native TLS/SSL including client certificate authentication [README]
• SASL authentication [README]
• LDAP support via the ergo-ldap plugin [README]
• UTF-8 nick and channel names using RFC 8265/PRECIS (optional, off by default) [README]
• Ident lookups for usernames [README]
• Automated client connection limits [README]

Integrated services (no separate daemon required):

• NickServ — user account registration and authentication [README]
• ChanServ — channel registration and access lists [README]
• HostServ — vanity hostname (vhost) management [README]

Built-in bouncer features:

• Message history storage and replay [README]
• Multiple clients sharing the same nickname simultaneously [README]

Security and privacy:

• Passwords stored with bcrypt [README]
• IP cloaking [README]
• Support for running as a Tor hidden service [README]
• Ability to require SASL for all connections [README]
• UBAN unified ban system covering IPs, networks, masks, and accounts; KLINE and DLINE also supported [README]

Operator and administration:

• Extensible IRC operator privilege system [README]
• Specifications-first development philosophy — documented on ergo.chat/specs [README]

Deployment:

• Docker and docker-compose support [profile][README]
• Binary releases with GPG signatures [website]
• Packages for Arch Linux (AUR) and Gentoo [README]
• Source builds with all dependencies vendored — no remote fetches required [README]
• Multi-language UI support via Crowdin [README]

What’s not here: no web UI, no REST API for administration, no LDAP directory bundled (LDAP is a plugin you attach separately), no media or file transfer infrastructure. Ergo is an IRC server. If you need a web-based admin panel, you’re building it yourself or using whatever IRC client you’re already running.

---

Pricing: SaaS vs self-hosted math

Ergo doesn’t have a SaaS product. There’s no managed hosting from the project, no commercial tier, no enterprise plan. The software is MIT-licensed and you run it yourself [profile][README].

Cost breakdown:

• Ergo software: $0 [profile]
• VPS to run it: $5–10/mo (Hetzner, Contabo, DigitalOcean — 1 vCPU, 1GB RAM is enough for small-to-medium networks)
• Domain name if desired: $10–15/yr
• TLS certificate: $0 via Let’s Certbot/Certbot or ./ergo mkcerts for self-signed

For comparison, if your community is currently paying for a hosted chat platform:

• Discord: free for most use cases, but you own nothing and the platform controls your community
• Slack: $7.25/user/mo on the Pro plan — 10 people = $870/yr
• Mattermost Cloud: starts around $10/user/mo

A 20-person community on Slack Pro pays around $1,740/yr. Running Ergo on a $6/mo Hetzner VPS costs $72/yr. The comparison only makes sense if IRC’s limitations are acceptable to your community — but if they are, the math is obvious.

There’s no per-message pricing, no seat limits, no storage quotas beyond your disk, and no vendor who can deprecate your community’s infrastructure.

---

Deployment reality check

The README’s quick-start is three commands after downloading the binary [README]:

cp default.yaml ircd.yaml
vim ircd.yaml
./ergo mkcerts
./ergo run

That’s genuinely accurate for a dev/test setup. A production setup is slightly more involved.

What you actually need:

• A Linux VPS (1GB RAM is sufficient for small networks; 2GB+ if you anticipate history replay under load)
• A domain name for TLS — the ./ergo mkcerts path generates self-signed certs, which most clients will warn about
• Reverse DNS set up if you care about ident lookups
• Systemd unit or similar for process management (the manual has a productionizing guide for this [README])
• An understanding that your config file is the only admin interface — there’s no web UI

What can go sideways:

• The config file is large and not forgiving on first setup. The defaults in default.yaml are reasonable, but you need to read through it to understand what you’re enabling. Ergo’s manual is thorough, but it’s a manual, not a wizard.
• TLS certificate rotation via Let’s Encrypt requires either a hook script to REHASH the server or manual intervention when certs renew. The rehash mechanism works, but setting it up correctly takes a few minutes.
• LDAP support requires the separate ergo-ldap plugin, which is an additional binary and config layer [README]. Not hard, but not zero effort.
• IRC clients vary wildly in IRCv3 support. Ergo’s history replay and multi-client features work beautifully in clients that implement the relevant IRCv3 capabilities; in older clients, some features silently don’t work or behave unexpectedly.
• The Docker path exists and is supported, but the docker-compose example in distrib/docker/ is the right starting point — don’t try to construct a compose file from scratch without reading it [README].

Realistic time estimate for someone comfortable with Linux: 30–60 minutes to a working TLS-enabled instance. For someone following a guide with no prior server admin experience: 2–4 hours including domain setup and TLS. The process is simpler than running InspIRCd + Anope, noticeably simpler than running anything in the Matrix ecosystem.

---

Pros and cons

Pros

• Single binary deployment. No separate services daemon, no separate bouncer, no inter-process linking to debug. One process, one config, one database [README].
• MIT license. Full freedom — self-host, fork, embed, run for commercial communities — no “fair-code” restrictions, no commercial agreement required [profile].
• Built-in bouncer features. History storage and multi-client per nick are first-class, not bolted on. Users don’t need ZNC accounts [README].
• IRCv3 reference implementation. If a feature is in the IRCv3 spec and a client supports it, Ergo almost certainly implements it correctly [README].
• Genuinely simple quick-start. Binary, config file, one command. No dependency chain to install [README].
• Rehashable config. Reload settings and rotate TLS certificates without restarting or dropping connections [README].
• Security-serious defaults. bcrypt passwords, IP cloaking, Tor support, SASL-required mode, client certificate auth — privacy controls that older ircds bolt on as afterthoughts are present out of the box [README].
• LDAP support for organizations already running a directory [README].
• Go implementation with vendored dependencies means no runtime surprises and straightforward binary distribution [README].

Cons

• No web administration interface. All configuration is YAML. Operators manage the server via IRC commands and config file edits. Fine for technical operators, a real barrier for non-technical community managers.
• IRC is still IRC. No threads, no reactions, no rich embeds, no voice/video, no mobile push notifications in the IRC protocol sense. Ergo is the best IRC server available; it cannot make IRC something it isn’t.
• Limited third-party ecosystem. No marketplace of integrations, no first-party bots, no API that external tools can call to manage the server. Bots connect as regular IRC clients.
• No hosted/managed option from the project. You’re fully responsible for your infrastructure, backups, and uptime.
• Small community relative to alternatives. 3,142 GitHub stars [profile] is respectable for an ircd but tiny compared to the IRC ecosystem’s history. The project is well-maintained, but the bus factor is worth considering for long-term deployments.
• LDAP is a separate plugin rather than built-in, adding a setup step for organizations that need it [README].
• No native push notification layer. Mobile IRC clients exist, but push notification support depends on the client, not the server.

---

Who should use this / who shouldn’t

Use Ergo if:

• Your community has already decided it wants IRC — you’re running an open-source project with an established IRC channel, you’re a developer who prefers IRC, or you’re migrating from an older ircd.
• You’re replacing a three-piece InspIRCd/Anope/ZNC stack and want something you can actually maintain in a few hours a month.
• You want an MIT-licensed chat server with no vendor risk — no company can raise your bill, deprecate your community, or shut your instance down.
• You need LDAP integration with an existing directory.
• You value protocol correctness and bleeding-edge IRCv3 support for clients that implement it.

Don’t use Ergo if:

• You’re evaluating chat platforms and IRC is one option among many. For most non-technical communities in 2025, Discord or a Matrix homeserver (Synapse/Conduit) will have better mobile client support, richer media handling, and lower onboarding friction for new members.
• You need a web admin UI to manage the server — there isn’t one.
• You need threads, reactions, or video calls. These aren’t IRC features.
• Your non-technical community managers will need to touch server configuration — YAML config and IRC operator commands have a real learning curve.

Use a different ircd if:

• You need extensive modularity and a plugin system — InspIRCd’s module system is more granular than Ergo’s.
• You’re running a large public network with specialized routing needs — some multi-server configurations have edge cases in Ergo’s implementation worth testing.

---

Alternatives worth considering

• InspIRCd — the most widely deployed modern ircd. Modular architecture, extensive plugin ecosystem, mature multi-server support. Requires Atheme or Anope for services. More complex to set up than Ergo; more flexible at scale.
• UnrealIRCd — long-established, full-featured, large user base on public networks. Windows support. Requires separate services.
• Charybdis / ircd-seven — the ircd running Libera.Chat and historically Freenode. Production-proven at scale. Not a beginner-friendly deployment.
• ngIRCd — minimal, easy to configure, suitable for small private networks. No integrated services.
• Matrix (Synapse or Conduit) — if the goal is “self-hosted team chat that isn’t IRC,” Matrix is the more realistic choice for non-technical communities. Richer protocol, bridging to Discord/Slack/IRC, mobile-first clients like Element. Higher resource requirements than Ergo.
• Mattermost — self-hosted Slack alternative with a real web/mobile UI. Heavier infrastructure requirements (PostgreSQL, significant RAM), but the UX ceiling is much higher than IRC.
• Zulip — open-source, threaded chat, good for async technical teams. More complex to deploy than Ergo but dramatically better for communities that work across time zones.

For someone who has specifically chosen IRC, the realistic comparison is Ergo vs InspIRCd + Anope. Ergo wins on operational simplicity; InspIRCd wins on configurability and module ecosystem. For someone still deciding on a chat platform, IRC probably isn’t the answer in 2025 unless the community already lives there.

---

Bottom line

Ergo is the right answer to a specific question: “I want to run an IRC network, what ircd should I use?” The all-in-one design is a genuine quality-of-life improvement over the traditional ircd + services + bouncer stack. The MIT license, Go binary, and rehashable config make it as operationally lightweight as an IRC server can reasonably be. The IRCv3 support is serious enough that the project serves as a reference implementation.

What Ergo can’t do is make IRC competitive with Discord for general community use. That’s not a criticism of Ergo — it’s the best IRC server available — it’s a statement about the protocol and the expectations of users in 2025. If IRC fits your community’s needs, Ergo is where you should start. If you’re still evaluating platforms, look at Matrix or Mattermost before committing to IRC infrastructure.

If you want Ergo running on a VPS without spending an afternoon on configuration, that’s exactly the kind of one-time deployment work upready.dev handles for clients.

---

Sources

Note: the third-party articles provided for this review were about unrelated “Ergo”-named products (ergonomic peripherals, a somatic therapy institute, and an unrelated Go actor framework). No independent reviews of the Ergo IRC server were available in the provided sources. All claims in this article are sourced from primary project materials.

1. ergochat/ergo — GitHub README — full feature documentation, quick-start guide, platform packages, and build instructions. https://github.com/ergochat/ergo
2. Ergo IRC Server — Official Website — project overview and links to release, admin manual, and user guide. https://ergo.chat
3. Ergo — About page — design principles and access to documentation. https://ergo.chat/about
4. ergochat/ergo — GitHub Container Registry — Docker distribution at ghcr.io/ergochat/ergo, referenced in distrib/docker README. https://github.com/ergochat/ergo/tree/master/distrib/docker
5. Ergo MANUAL.md — Productionizing with systemd — operator manual covering production deployment, TLS, and configuration. https://github.com/ergochat/ergo/blob/stable/docs/MANUAL.md