# Fider: a self-hosted feedback portal for feature requests

> Fider is a Go application that collects customer suggestions, lets people vote on them, and ranks the list. It installs as a single binary with PostgreSQL, and the AGPL-3.0 licence applies to anyone who modifies and hosts it.

**getfider/fider** — Open platform to collect and prioritize feedback

- Repository: https://github.com/getfider/fider
- Website: https://fider.io
- Stars: 4,555 · Forks: 863
- Language: Go
- License: AGPL-3.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/getfider-fider

## What Fider collects and who ends up reading it

Fider is a feedback portal. Customers post feature requests and suggestions, other users vote on them, and the resulting ordering is what a product team looks at when deciding what to build next. The README frames the purpose directly: "Give your customers a voice and let them tell you what they need." That is a narrower job than a general issue tracker. There are no sprints, no assignees, no code links. The unit of work is a post with a vote count, and the value comes from the fact that the ranking is produced by the people asking for the feature rather than by the team guessing.

The intended user is a product or support team at a company that already has customers asking for things in scattered places: support tickets, chat, email, a spreadsheet. Fider gives those requests one address. Because it is self-hosted, the team also owns the data and the login flow, which matters if customer email addresses should not sit in a third-party SaaS database.

The topics listed on the repository (customer, feature-request, feedback, ideas, suggestions) match that scope. Nothing in the README suggests Fider handles bug triage, internal roadmaps or SLA tracking. Teams that need those should look elsewhere rather than stretch this.

## How the Go server, PostgreSQL and the React UI fit together

The repository is a Go module, github.com/getfider/fider, on Go 1.25.0, with a React and TypeScript frontend built by esbuild and webpack. The server side uses httprouter for routing, lib/pq for PostgreSQL, golang-jwt for tokens, oauth2 for third-party sign-in, and lingua-go for language detection. Stripe and AWS SDK dependencies are present, which tells you billing and S3-compatible object storage are part of the codebase, though the README does not document how to configure either.

The Dockerfile shows the runtime shape clearly. It is a three-stage build: a golang:1.25-bookworm stage compiles the server, a node:22-bookworm stage runs make build-ssr and make build-ui, and the final debian:bookworm-slim image copies the binary plus migrations, views, locale, static and dist directories. The container exposes port 3000 and its command is `./fider migrate && ./fider`, so schema migrations run at every start. That is convenient, and it also means a bad migration is applied on boot rather than in a separate step you can inspect first.

A healthcheck is defined as `./fider ping`, which gives orchestrators a cheap liveness probe. The migrations directory sits next to the binary, so the migration files must travel with the image; they do.

## Installing Fider with Docker and a first request

The README points self-hosters to the documentation at docs.fider.io/self-hosted/ rather than repeating install steps. The repository itself ships a Dockerfile and a docker-compose.yml, and the compose file is written for development: it starts mailhog on ports 8025 and 1025 for catching outbound mail, a PostgreSQL 17 container named fider_pgdev on host port 5555 with user fider and password fider_pw, a second PostgreSQL for tests on port 5566, and a MinIO container on ports 9000 and 9001 with access key s3user and secret s3user-s3cr3t.

Bringing those dependencies up is the first command:

```bash
docker compose up -d
```

After that, the development database listens on localhost:5555 and mailhog's web interface is at localhost:8025. The repository also carries .example.env, which is the template for configuration; copy it to .env and adjust the values before starting the server. The Go toolchain reads .env through godotenv, and the configuration keys are decoded with envdecode.

The application image itself builds the server and the UI and then runs migrations on start:

```bash
docker build -t fider .
docker run --rm -p 3000:3000 --env-file .env fider
```

The container's own command is `./fider migrate && ./fider`, so you should see migration output followed by the HTTP server binding on port 3000. Open http://localhost:3000 and you land on the portal. The first account you create becomes the administrator, and from there the admin area is where you set the site name, the sign-in providers and the tenant settings.

If you would rather not build anything, the README offers a hosted option: Fider Cloud, described as "a fully managed services by the creators of Fider". The demo instance at demo.fider.io is the fastest way to see the voting interface before you commit to running the stack.

## Where Fider stops being the right tool

The README is short, and that shows. It documents two paths, Cloud and Self-Hosted, and links the self-hosted instructions off-site. It does not describe backup, restore, upgrade order, or what happens if a migration fails halfway. Given that migrations run automatically on container start, an operator who has not read the migration files is trusting the release to be forward-compatible. The release cadence visible in the repository is roughly monthly (v0.35.0 on 2026-05-06, v0.36.0 on 2026-06-24, v0.36.1 on 2026-07-03), so an upgrade is a recurring task, not a one-off.

Fider is also not a support desk. There is no ticket lifecycle, no private thread between an agent and a customer, no SLA. If your incoming volume is mostly bug reports with reproduction steps, an issue tracker handles that better, and Fider's vote ranking will actively work against you by burying the boring but urgent bug under a popular cosmetic request.

The third limit is operational. You need PostgreSQL, a place to run a container, and outbound email that actually delivers, since account confirmation and notifications depend on it. The compose file's mailhog is a development convenience, not a production mail server. Teams without anyone willing to own a database and a container should take Fider Cloud or a SaaS product instead.

## Fider against a plain issue tracker

The obvious alternative is running the same job inside GitHub Issues, GitLab Issues or Jira and asking customers to file there. The difference in approach is who owns the ranking. An issue tracker sorts by whatever the team sets: milestone, label, assignee, priority. Fider sorts by votes from the people making the requests. That single change is the whole product. It also changes the audience: an issue tracker is built for the people doing the work, and Fider is built for the people asking for it.

The cost of that choice is real. Votes are a blunt signal. A loud minority can push a request up the list, and there is no built-in weighting for revenue, contract size or strategic fit. Fider gives you the ranked list; the judgement about which items to act on still belongs to the team.

A second alternative is a hosted feedback SaaS, which removes the PostgreSQL and container work entirely. Fider's counter-argument is control: the data, the domain and the login flow stay on your infrastructure, and the AGPL-3.0 licence means you can read and modify the code. The trade is that you also inherit the upgrades.

## Licence, releases and the cost of staying current

Fider is licensed AGPL-3.0. That is a copyleft licence with a network clause: if you modify Fider and let users interact with it over a network, the licence's terms reach the modified source you are running. This matters for companies that want to fork the portal, rebrand it and offer it as part of their own service. It does not restrict using an unmodified Fider internally to collect feedback. The repository also carries SECURITY.md and CODE_OF_CONDUCT.md, and the README asks self-hosters to report where they are using it in issue 899, which is a courtesy request rather than a licence condition. None of this is legal advice; read LICENSE and talk to counsel if you plan to redistribute.

On maintenance: the repository is not archived, and the last push was on 2026-09-19, so the project is being worked on. Releases arrive on a monthly-ish rhythm. For an operator, the recurring cost is the upgrade path: pull the new image, let `./fider migrate` run, and verify the portal afterwards. There is no documented rollback procedure in the README, so the practical safeguard is a database backup taken before each upgrade. Budget for that if you self-host.

## Conclusion

Adopt Fider if you want customer suggestions, voting and prioritisation on infrastructure you control, and if AGPL-3.0 fits how you ship the modified code. Skip it if you need a managed service with a support contract, or if you cannot run PostgreSQL and a container. Before committing, open the demo at demo.fider.io, read the self-hosted page at docs.fider.io, and confirm which authentication providers and storage backend you need, because the README does not list them.

## FAQ

### Is Fider free to use?

The self-hosted version is described in the README as "totally free", with the caveat that you are responsible for everything: the server, the database and the upgrades. Fider Cloud is a separate paid managed offering from the same creators.

### Can I self-host Fider?

Yes. The README lists Self-Hosted as one of two getting-started paths and links to docs.fider.io/self-hosted/ for the instructions. The repository ships a Dockerfile and a docker-compose.yml with PostgreSQL 17, mailhog and MinIO for local development.

### How do I install Fider?

The README does not inline the steps; it points to the self-hosted documentation. In the repository, the container image builds the Go server and the React UI and runs `./fider migrate && ./fider` on start, exposing port 3000, and the compose file brings up the development database and mail catcher.

### What is a Fider alternative if I do not want to self-host?

The README itself offers Fider Cloud, described as a fully managed service by the creators of Fider, which removes the server and database work. Beyond that, no other feedback products are named or compared.

## Sources

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

---

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