# LibreDesk: a self-hosted support desk in one Go binary

> LibreDesk packs live chat, email, a help center and an AI assistant into a single binary backed by Postgres and Redis. It is a reasonable fit for small teams leaving Zendesk or Intercom, and a poor fit for anyone who wants a managed service or a plugin ecosystem.

**abhinavxd/libredesk** — Open-source, self-hosted customer support desk in a single binary. A lightweight alternative to Intercom, Zendesk, Chatwoot.

- Repository: https://github.com/abhinavxd/libredesk
- Website: https://libredesk.io
- Stars: 2,982 · Forks: 289
- Language: Go
- License: AGPL-3.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/abhinavxd-libredesk

## The problem LibreDesk solves, and for whom

Support teams that outgrow a shared inbox usually end up paying per seat for Zendesk or Intercom, or they self-host Chatwoot and inherit a Rails stack. LibreDesk targets the second group. The README describes it as a "Modern, open source, self-hosted omnichannel customer support desk" and positions it against Intercom, Zendesk and Chatwoot. The pitch is that live chat, email, a searchable help center and an AI assistant all land in one inbox, and that the whole thing ships as a single binary.

The audience is narrow and specific. It suits a team of a few agents who already run their own infrastructure, want their customer conversations on hardware they control, and are comfortable with a Postgres database and a Redis instance as dependencies. It does not suit a company with no operations staff, because the README's install instructions assume you can edit a TOML file and run a container. The repository is hosted under the Zerodha Tech badge, which suggests it grew out of an in-house need rather than a venture-backed product roadmap.

## One binary, two frontends, three moving parts

The architecture is visible in the repository layout. The backend is Go, and the README states the frontend is Vue.js 3 with Shadcn UI. The Makefile shows the frontend is built in two separate passes, build:main and build:widget, so the agent inbox and the embeddable chat widget are distinct bundles. Both are then packed into the Go binary with stuffbin, along with i18n, schema.sql and static assets. That is why the Docker image copies a single file, libredesk, and a config.sample.toml, and nothing else.

Go dependencies tell you what the runtime actually needs. github.com/lib/pq means Postgres, not MySQL. github.com/redis/go-redis/v9 means Redis, used alongside github.com/zerodha/fastcache for caching. Email arrives over IMAP through github.com/emersion/go-imap/v2 and goes out through github.com/knadh/smtppool. OIDC logins use github.com/coreos/go-oidc/v3, which is what backs the Google, Microsoft and generic OIDC support. The AI features use github.com/pkoukk/tiktoken-go for token counting, and github.com/abhinavxd/ssrfguard suggests the AI assistant fetches URLs with some protection against internal network access.

The request path is conventional. fasthttp and fastglue handle HTTP, sqlx talks to Postgres, and the frontend is served from the embedded filesystem. There is no separate Node process in production, which is the practical payoff of the single-binary claim.

## Installing LibreDesk with Docker Compose

The README gives Docker as the primary self-hosted path, and the compose file provisions the app, Postgres 17 and Redis 7 together. Download the compose file and the sample config into the current directory, then make an editable copy of the config.

```bash
curl -LO https://github.com/abhinavxd/libredesk/raw/main/docker-compose.yml
curl -LO https://github.com/abhinavxd/libredesk/raw/main/config.sample.toml
cp config.sample.toml config.toml
docker compose up -d
```

The compose file mounts ./config.toml into the container at /libredesk/config.toml, so the file you just created is the one the app reads. Postgres binds to 127.0.0.1:5432 rather than all interfaces, which is a deliberate default you should leave alone unless you need external database access.

The container command runs three steps in sequence: an idempotent install, an upgrade, and then the server itself. That means schema changes apply on every start, not only on a fresh deployment.

```bash
./libredesk --install --idempotent-install --yes --config /libredesk/config.toml
./libredesk --upgrade --yes --config /libredesk/config.toml
./libredesk --config /libredesk/config.toml
```

Set the system user password before you try to log in. The README shows the exec form:

```bash
docker exec -it libredesk_app ./libredesk --set-system-user-password
```

You can also pass LIBREDESK_SYSTEM_USER_PASSWORD in the environment on first start, which the compose file documents. Then open http://localhost:9000 and log in as System with the password you set. If you prefer no containers, the README offers a binary path: download the release, edit config.toml, run ./libredesk --install to set up the Postgres database, then ./libredesk --set-system-user-password, then ./libredesk. Railway is offered as a one-click deploy that provisions the app, Postgres and Redis for you.

## Where LibreDesk gets in your way

The dependency on Redis is the first constraint worth naming. A single binary is the marketing line, but the deployment is three services. If Redis is unavailable, caching and whatever else depends on it degrade, and the README does not document a mode that runs without it. Postgres is not optional either, and the schema is applied from schema.sql at install time.

The AI assistant is grounded in your knowledge base, according to the README, and hands off to a human when it cannot help. That grounding is only as good as the articles you have written. On a new install with an empty help center, the assistant has nothing to retrieve from, and the README does not describe a fallback behavior for that case. Treat the AI features as something to validate against your own content before you let them answer customers.

Upgrades are another place where the documentation is thin. The compose command runs --upgrade on every container start, which is convenient but means you should read release notes before pulling a new image. There is no documented rollback procedure and no mention of database migration reversibility, so a backup of the Postgres volume before an upgrade is the only safety net that can be confirmed.

Finally, the licence is AGPL-3.0. That is a real consideration for anyone embedding the chat widget into a commercial product or modifying the server and exposing it over a network. The repository does not offer an alternative licence.

## LibreDesk against Zammad and Chatwoot

Zammad is the closest comparison people search for, and the two projects make different bets. Zammad is a long-standing Ruby on Rails helpdesk with a broad feature surface, a large integration list and a mature ticket workflow model. It also carries the operational weight of a Rails application: more processes, more memory, and a stack your team needs to know. LibreDesk compiles to a Go binary, embeds its Vue frontend with stuffbin, and asks for Postgres and Redis. If your team writes Go and wants a small surface area to reason about, that difference is the whole argument.

Chatwoot is the other name in the README's positioning. It is also Rails-based, with a strong live chat and inbox focus and a hosted option. LibreDesk's distinguishing features in this comparison are the single binary and the AI assistant grounded in the help center, neither of which the README attributes to Chatwoot. What Chatwoot has that LibreDesk's README does not claim is a comparable third-party integration catalog.

If your requirement is a helpdesk with a deep marketplace of plugins, none of these three is a clean answer, and you are probably looking at Zendesk or Freshdesk instead. If your requirement is self-hosted chat plus email plus a knowledge base with minimal moving parts, LibreDesk is the smallest of the three.

## Maintenance, upgrades and licence obligations

The last push to the repository was on 2026-09-09, and the most recent release listed is v2.8.0 from 2026-08-22, with v2.7.0 and v2.7.1 earlier in August. The repository is not archived. Release cadence over that window looks steady, but the README does not publish a support policy, a versioning promise, or a deprecation timeline, so you should read release notes before each upgrade rather than assume compatibility.

Upgrade cost is mostly operational. The container runs --upgrade --yes on start, so pulling libredesk/libredesk:latest applies schema changes without prompting. Pin a specific image tag if you want to control when that happens. Back up the postgres-data volume first; the README does not describe a downgrade path.

On licensing, LibreDesk is AGPL-3.0. The practical consequence is that if you modify the server and let users interact with it over a network, the licence expects you to offer the corresponding source. Running an unmodified instance for your own support team is the ordinary case and does not raise that question. This is a description of the licence, not legal advice; if you plan to embed the widget in a commercial product or fork the server, talk to someone qualified.

## Conclusion

Adopt LibreDesk if you have someone who can run Postgres and Redis and you want chat, email and a knowledge base in one place under AGPL-3.0. Do not adopt it if you need a managed service, a large plugin marketplace, or if you cannot accept the copyleft terms of the licence. Before committing, verify that your config.toml matches the keys in config.sample.toml, that IMAP and SMTP work against your mail provider, and that the AI assistant behaves acceptably on your own knowledge base articles.

## FAQ

### Is there an open source version of Zendesk?

LibreDesk is one: the README describes it as an open source, self-hosted omnichannel customer support desk and positions it as a lightweight alternative to Intercom, Zendesk and Chatwoot. It is licensed AGPL-3.0 and distributed as a single Go binary with Postgres and Redis as dependencies.

### How do I install LibreDesk?

The README's Docker path downloads docker-compose.yml and config.sample.toml, copies the sample to config.toml, runs docker compose up -d, and then runs the --set-system-user-password command inside the container. A binary install is also documented, using ./libredesk --install followed by ./libredesk --set-system-user-password and ./libredesk.

### What port does LibreDesk run on?

Port 9000. The Dockerfile exposes 9000, the compose file maps 9000:9000, and the README tells you to visit http://localhost:9000 after starting the services.

### Does LibreDesk have an API?

Yes. The README lists HTTP/JSON APIs and webhooks for custom integrations and workflows among the features, and the project's documentation site covers the API.

## Sources

- [abhinavxd/libredesk on GitHub](https://github.com/abhinavxd/libredesk)
- [License: AGPL-3.0](https://github.com/abhinavxd/libredesk/blob/main/LICENSE)
- [Project website](https://libredesk.io)
- [README](https://github.com/abhinavxd/libredesk/blob/main/README.md)
- [Releases](https://github.com/abhinavxd/libredesk/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/abhinavxd-libredesk