Redacted Support Reports

Do Not Post These Publicly

• Secrets, tokens, API keys, session IDs, cookies, and private keys.
• Public or private IP addresses, hostnames, usernames, and customer names.
• Raw logs that include request paths, query strings, authentication details, or payloads.
• Private file paths, internal service names, deployment paths, and database names.
• Exploit payloads, malware samples, runnable attack instructions, or sensitive incident details.

Usually Safe To Share

If a maintainer asks for context, start with boring operational facts. They often reveal enough to debug install and service problems without exposing a real host.

• Distro family and version.
• Package manager and install method.
• Vexyl Guard version and release channel.
• Service status: running, stopped, failed, or not installed.
• High-level error category without raw sensitive lines.

Vexyl Guard Support Report

The preview includes a support-report command designed for safer public feedback. Review the output anyway before posting it.

sudo vexyl-guard support-report

If the report shows something unique to your host or environment, replace it with a clear placeholder before sharing.

Use Clear Placeholders

Use placeholders that preserve meaning without exposing real data.

hostname: [redacted-hostname]
public_ip: [redacted-public-ip]
username: [redacted-user]
path: /home/[redacted-user]/app
token: [redacted-token]

When To Report Privately

Move the conversation out of public comments when the issue includes sensitive host details, a possible vulnerability, customer impact, active compromise, or private logs you cannot safely summarize.