Skip to content

Report an Issue

BetweenRows is maintained by a small team, and feedback from early users directly shapes what we build next — reports and requests are genuinely welcome. Different kinds of feedback go through different channels; pick the one that matches what you have.

Security vulnerabilities

Do not open a public GitHub issue for security problems. Filing a public issue for a vulnerability means an attacker can read it before a fix ships.

Use GitHub's private vulnerability reporting form:

👉 github.com/getbetweenrows/betweenrows/security/advisories/new

Reports submitted through the form are visible only to project maintainers. See SECURITY.md for the full disclosure policy — what to include, what to expect, scope, and credit.

Bugs and unexpected behavior

Open a public GitHub issue:

👉 github.com/getbetweenrows/betweenrows/issues/new

What helps us reproduce and fix it:

  • Proxy version — check the admin UI footer, or run curl http://localhost:5435/health
  • Component — proxy, admin UI, admin REST API, migration, CLI
  • What you did — minimum SQL, API call, or UI steps to trigger the issue
  • What you expected — the correct outcome, in your words
  • What happened instead — actual output, error message, or screenshot
  • Logs (if relevant) — proxy stdout/stderr, query audit log entry, admin audit log entry

Before filing, a quick search through existing open issues often finds a match — upvoting an existing report is more useful than a duplicate.

Feature requests and design discussions

Also GitHub Issues, same form as bugs. Tell us:

  • Your use case — what are you actually trying to accomplish?
  • Why the current behavior does not work — is a feature missing, awkward, or subtly wrong?
  • A rough shape of the ideal outcome — not a full design, just enough for us to understand what "good" looks like to you.

Non-trivial features benefit from a design conversation before any PR is written. If you have strong opinions on the shape, opening an issue to talk it through first saves rework.

Questions and how-to

Start with the documentation:

  • Search — the top nav has a search box that indexes every page.
  • Guides — the Guides section covers the common workflows end-to-end.
  • Reference — the Reference section has the exhaustive field tables and expression syntax.
  • LLM-friendly bundle — if you prefer to ask your own chat model, the full docs are available as a single text file at /llms-full.txt.

If the docs do not answer your question, that itself is a useful signal — open a GitHub issue describing what you were looking for and where you looked. We'll fill in the gap: either pointing you to something you missed, or extending the docs to cover your case. "I couldn't find how to do X" is a welcome issue type, and those reports directly shape which pages get written or expanded next.