> ## Documentation Index
> Fetch the complete documentation index at: https://link.datarelay.run/llms.txt
> Use this file to discover all available pages before exploring further.

# Feedback

> Report bugs and request improvements for Data Relay Link.

# Feedback

Help improve Data Relay Link by reporting reproducible problems and describing real workflows that would benefit from an improvement.

<CardGroup cols={2}>
  <Card title="Report a Bug" icon="bug" href="https://github.com/datarelay-labs/data-relay-link/issues/new?title=%5BBug%5D%20&body=%23%23%20Data%20Relay%20Link%20version%0A%0A%23%23%20Environment%0A%0A%23%23%20Steps%20to%20reproduce%0A%0A%23%23%20Expected%20behavior%0A%0A%23%23%20Actual%20behavior%0A%0A%23%23%20Diagnostics%20or%20logs%0A%0A%3C!--%20Remove%20passwords%2C%20private%20keys%2C%20tokens%2C%20API%20keys%2C%20customer%20data%2C%20and%20other%20secrets%20before%20submitting.%20--%3E">
    Report a reproducible product problem with version, environment, steps, expected behavior, and redacted diagnostics.
  </Card>

  <Card title="Request a Feature" icon="lightbulb" href="https://github.com/datarelay-labs/data-relay-link/issues/new?title=%5BFeature%5D%20&body=%23%23%20Problem%20or%20workflow%0A%0A%23%23%20Requested%20behavior%0A%0A%23%23%20Current%20workaround%0A%0A%23%23%20Affected%20platforms%20or%20components%0A%0A%23%23%20Why%20this%20matters%0A">
    Describe the problem or workflow first, then the behavior you would like Data Relay Link to provide.
  </Card>
</CardGroup>

## Before you submit

1. Search [existing GitHub issues](https://github.com/datarelay-labs/data-relay-link/issues) for the same problem or request.
2. Use the installed Data Relay Link version, not an assumed latest version.
3. For bugs, provide the smallest reliable reproduction sequence you can.
4. Include only the logs or diagnostics needed to understand the problem.
5. Remove secrets and customer data before submitting anything publicly.

<Warning>
  **Never post passwords, private keys, enrollment tokens, API keys, customer data, or other secrets in a public issue.** If the report may describe a security vulnerability, do not use the public bug form; contact the maintainers privately first.
</Warning>

## What makes a useful bug report?

A useful report normally includes:

* Data Relay Link version
* affected area or component
* server OS and client OS when relevant
* deployment mode or NAT/firewall context when relevant
* affected CLIENT ID or service **without exposing secrets**
* expected behavior
* actual behavior
* exact reproduction steps
* relevant, redacted `drlink` diagnostics, service status, or logs

If the issue is intermittent, mention frequency and whether reconnect, reboot, upgrade, restore, or another lifecycle event is involved.

## What makes a useful feature request?

Start with the **problem**, not only the desired implementation.

For example, instead of only saying "add protocol X", explain the workflow that cannot be completed today, the current workaround, affected platforms, security constraints, and how important the request is to a real deployment.

Data Relay Link intentionally targets small environments — from a few systems to a few dozen clients — so requests that preserve a lightweight, understandable operating model are easier to evaluate than large-fleet orchestration or full SASE/SWG scope expansion.

## Feedback areas

Feature requests can cover areas such as:

* Secure Remote Access
* Controlled Egress
* enrollment and bootstrap UX
* service publishing and public-port management
* `drlink` CLI and operator UX
* lifecycle, upgrade, backup, restore, and diagnostics
* Linux, macOS, and Windows compatibility
* AI / MCP integration
* documentation

<Tip>
  If you are unsure whether something is a bug or a feature request, describe the current behavior and the behavior you expected. Choose the form that best matches the primary problem.
</Tip>