Storage backends

	postgres	github	external
Attachments	✅	❌	✅ if you implement it
Edit a comment	✅	✅	✅ if you implement it
Delete a comment	✅	✅	✅ if you implement it
Guest authors (no account)	✅	❌ attributed to the app	✅ if you implement it
Low-latency reads	✅	❌ rate limited	❌ your latency
Hard-delete a thread	✅	❌ close only	✅ if you implement it
Body content on Gutternote servers	yes	no	no

Anchors — page, element, coordinates, status — are stored by Gutternote in all three cases.

postgres

No configuration. The default for new projects.

github

{
  "owner": "acme",
  "repo": "website",
  "installationId": 12345678,
  "label": "gutternote"
}

Install the Gutternote GitHub App on the repo. Every thread opens one issue; replies become issue comments. The label is applied to every issue Gutternote opens so you can filter them out of normal triage.

Gutternote embeds an HTML comment in each body carrying the thread ID, the real author and the anchor:

<!-- gutternote:v1 {"thread":"...","author":{...},"anchor":{...}} -->
**Dana Reed** commented via [Gutternote](https://gutternote.com):

The CTA is 4px off.

It’s invisible in GitHub’s rendered view and round-trips through the API unchanged. It is also the weak point of this backend: anyone with write access can corrupt it by editing the comment. Gutternote degrades to showing the raw text rather than dropping the comment, and a reply typed directly in GitHub — which has no marker at all — still appears in the thread, attributed to its GitHub author.

external

{
  "endpoint": "https://comments.acme.internal/gutternote",
  "signingKeyId": "key_1"
}

See the external store contract.