Free during the beta · Hosted in Europe
Your client clicks the element that bothers them and writes a note. It becomes an issue with the CSS selector, the React component and the source file. Back on the page, the pin is still there, coloured by the state of its issue.
A reviewer clicks any element of the page. Nothing to describe: the selector, the component and the file come with it.
One field. The note becomes an issue in Linear, in GitHub Issues, or in the workspace itself.
The pin stays on the page, coloured by the state of its issue, with the team's replies under the note.
On a site that embeds nothing, the browser extension puts the same widget on the page, for you only.
Same widget, same extension, same trackers. The only question is who runs the server.
We run it. You sign in and paste the address of your site.
Free during the beta
Create a workspaceYou run one container. Everything stays on your server.
Free open source, MIT and AGPL
Read the install guide| Cloud | Self-hosted | |
|---|---|---|
| Who runs the server | Sakuga, in Europe | You |
| Where notes land | Your workspace | Linear, GitHub Issues or SQLite |
| Accounts | Sign in by e-mail link | Pairing codes, minted by you |
| Updates | Automatic | docker compose pull |
| Price | Free during the beta | Free |
Yes. It talks to the worker you name: the Cloud's, or your own.
You choose per site: the members of your workspace only, or everyone who visits it.
Accounts, workspaces, the addresses of your sites, and the notes. Every field is listed.
Feedback on the page, issues in your tracker.
A client opens their staging site, clicks the element that bothers them, and types a note. It lands as an issue carrying the CSS selector, the React component and the source file behind that element. Coming back to the page, they see their pins again, coloured by that issue’s status.
Two ways to run it. Fruitback Cloud runs the server for you, in Europe, and keeps the notes in your workspace. Self-hosted, you run one container, and the notes land in the tracker your team already uses (Linear, GitHub Issues) or in a SQLite file on a volume you own.
| The three modes | Public, private and team: what the site ships in each, and who may read the pins. Start here. |
| Installing Fruitback | Two lines on a site with no build step, and what each option does. |
| Running the worker yourself | One container behind a reverse proxy: every environment variable, and what a wrong value breaks. |
| Reviewing a site with the extension | The reviewer’s side: the browser extension, a rule per site, and pairing. |
| Translating the widget | The words a host can replace, and the catalogs the bundle carries. |
| What the widget collects | Every field a note carries, where it goes, how long it stays, and how to delete it. |
| Architecture | What the parts are, and the designs that were dropped. |
The source is on GitHub, under the MIT licence for the three published packages and AGPL-3.0-only for the worker and the browser extension. The decisions folder holds the per-ticket histories: the measurements, the first versions that failed, and the reviews that caught them.