A feedback tool needs a server for the handful of things that write: accepting a submission, counting a vote, sending a notification. Everything else, the pages themselves, is a read, and a read needs no process running anywhere. The real question is not static against server. It is which of a feedback tool's jobs are which.
What does a feedback tool actually have to do?
Strip a feature request board down to its jobs and there are about six of them. Most people reach for a server because that is what the well-known open-source options are built as, not because every job requires one.
| Job | Does it need a running server? |
|---|---|
| Rendering the pages a visitor reads | No, this is a read |
| Accepting a new submission | Yes, something has to receive it |
| Storing posts and comments | No, a database or files in a repository both work |
| Sending a notification email | No, an API call to a mail provider does it |
| Counting a vote | Yes, this one needs write state |
| Search | No, a prebuilt index can serve it |
| Moderation | Depends, see below |
Four of the seven are reads or answered by a prebuilt file. The two unambiguous "yes" rows, accepting a submission and counting a vote, are small, well-defined pieces of work: take an input, validate it, write one row somewhere. Neither needs a whole application server sitting around it.
Why is vote counting the interesting one?
Rendering, storage and search all tolerate staleness. A visitor reading a roadmap page a few minutes out of date has lost nothing. A vote count does not have that luxury: two people can click the same button in the same second, and something has to make sure both clicks land rather than one silently overwriting the other.
That is genuinely a server's job, in the narrow sense that some process has to hold a lock, or use a database that handles the increment atomically, at the moment two writes collide. It does not follow that the thing holding that lock has to be a long-running application watching a database around the clock. It can be a single small function that wakes, does one atomic increment, and goes back to sleep. The write needs somewhere to land safely. It does not need company.
What do you give up by doing it this way?
Two things, honestly. First, a vote count on a page built at deploy time cannot update itself in front of a visitor without a rebuild or a small client-side call to a separate endpoint that reports the current tally. Second, there is a gap between making a change and it appearing on the page, because a build step sits in between. If your pipeline takes two minutes, that is the delay between "we replied to this" and a visitor seeing the reply. For a support and roadmap page, both are trades most teams can live with. For anything genuinely real-time, they are not.
Is this what Docket does?
Yes, and it is worth naming so the trade above is not abstract. Docket runs as static files plus two small endpoints, no Postgres, no Docker, no SMTP server running anywhere. Every post, the roadmap and the changelog are built ahead of time from files in a repository. The two endpoints exist for exactly the two writes in the table above: taking a new submission and recording a vote. Notification email goes out through a call to a mail provider's API rather than a mail server the site has to run and patch itself; check the current terms of whichever provider you choose rather than trust a free-tier number written down elsewhere.
That is one valid answer, not the only one. It suits a team that wants the fewest possible things running and can live with a short delay between an edit and the published page. It is a poor fit for a team that wants votes updating live without extra plumbing, or that already runs a database and an operations team who would rather add one more service than coordinate a build pipeline and two endpoints.
Why do most self-hosted options run as full applications instead?
They are not wrong to. Fider, LogChimp, ClearFlask and Quackback are all conventional server applications, each with a database underneath, and there are real reasons a team picks that shape on purpose. A single running process is one thing to reason about, not a build pipeline plus a couple of small services coordinating around it. Fider's own documentation is direct about the requirements: Docker, PostgreSQL 12 or later, and your own SMTP provider or Amazon SES for mail.
A persistent server also makes some jobs simpler: live-updating counts, admin sessions, role-based permissions and a moderation queue someone is actively working through all sit more naturally on a database you can update in place than on a build that only runs when told to. If your team wants any of that, a server is the right tool for it.
One payment, no subscription, unlimited products.
When does a full server actually earn its place?
Roughly whenever the "no" answers above start turning into "yes". A board needing live collaboration between staff working a queue at once, permissioning across several teams, or an integration needing a persistent session rather than a one-off call, is describing a server's job. So is a submission volume large enough that a couple of small endpoints stop being small.
The honest split is this. Reads scale by being cheap to serve and cheap to cache, which a static build does for free. Writes scale by needing somewhere consistent to land, whether that sits behind a full application or two endpoints that do nothing else. Work out which jobs on your own list are reads and which are writes before picking a shape, rather than picking the shape first and fitting the jobs to it.
Fider, LogChimp, ClearFlask and Quackback are compared tool by tool, licence, activity and what each gates behind a paid tier, in the open source options compared. The mail side of self-hosting, SPF, DKIM and DMARC on your own domain, has its own page: SMTP for self-hosted tools. For the running cost of the database-backed route in hours and pounds, see self-hosting a feature request board.
Frequently asked questions
Does a feature request board need a database at all?
It needs somewhere for the two writes, a submission and a vote, to land safely. That can be a full database behind an application server, or a much smaller data store behind two purpose-built endpoints. What it does not need is a database for the parts that are only ever read, since those can be built into plain files ahead of time.
Why can rendering and storage both be static but voting cannot?
Rendering and storage tolerate staleness, a page or a stored post that is a few minutes old has lost nothing. A vote is a write that can collide with another write in the same instant, and something has to resolve that collision correctly. That is a narrow job for a small endpoint with an atomic increment, not a reason the whole site needs a server.
What is the actual downside of the static-plus-endpoints approach?
Two things. A vote count cannot update live on the page without a rebuild or a separate client-side call, and there is a delay between making a change and it appearing on the site, equal to your build time. Both are real costs, not a rounding error.
Do Fider, LogChimp and Quackback need a server for a bad reason?
No. A persistent server genuinely makes live counts, admin roles and an active moderation queue easier to build, and Fider's own documentation lists Docker and PostgreSQL as requirements for that reason. It is the right architecture for a team that wants those features, and a heavier answer than a public roadmap and a feedback form strictly require.
How do notification emails work without running a mail server?
Through an outbound call to a third-party mail provider's API rather than software you host and patch yourself. Providers vary in what they offer for free and on what terms, and it is worth checking a provider's current pricing and terms directly rather than relying on a number written down elsewhere.