# Getting support

> Where to ask about Nasnet Linux, what to put in a bug report, and how to share logs without leaking your secrets.

Source: https://joinnasnet.com/en/guides/nasnet-linux/support/
Last updated: 2026-08-17

---

## Overview

Nasnet Linux is maintained in the open by the people who use it. Questions go to
the Telegram group, reproducible bugs go to the issue tracker, and anything with
a security impact goes through a private channel. Whichever you pick, the panel
logs are what turn a guess into an answer.

## Before you ask

1. Read [Troubleshooting](/en/guides/nasnet-linux/troubleshooting/), where
   logins that will not stick, certificates that will not issue and empty
   subscription links are all covered with their causes.
2. Read the logs, because the panel names the failing step in almost every case.

   ```bash
   docker compose logs -f app        # Compose install
   journalctl -u nasnet-panel -f     # systemd install
   ```

3. Confirm the panel restarted after your last `.env` change. Editing the file
   is not enough.
4. Check your server against
   [System requirements](/en/guides/nasnet-linux/system-requirements/).

## Where to go

| Channel | Use it for | Where |
| ------- | ---------- | ----- |
| Telegram | Questions, setup help, sanity checks | [t.me/joinnasnet](https://t.me/joinnasnet) |
| GitHub issues | Reproducible bugs and feature requests | [nasnet-panel-linux/issues](https://github.com/nasnet-community/nasnet-panel-linux/issues) |
| Security reports | Anything with a security impact, never a public issue | [Report privately](https://github.com/nasnet-community/nasnet-panel-linux/security/advisories/new) |

## Redact before you paste

The panel's logs and `.env` are full of things that should not go into a public
issue. Strip these every time:

- `JWT_SECRET_KEY` and `ADMIN_PASSWORD_HASH`
- `DB_PASSWORD` and any full database URL
- `TELEGRAM_BOT_TOKEN` and `WEBHOOK_URL`
- Subscription link keys, because a `/sub/{key}` URL *is* the credential
- Your server's public IP and domain, if you would rather not publish them

Replace each with a placeholder rather than deleting the line; knowing a value
was set is often the point.

## Reporting a bug

Include:

- **What you did, what happened, what you expected.**
- **The version**, given as a release tag or commit SHA.
- **How it is deployed**, whether Docker Compose, systemd, a binary, or the
  offline bundle.
- **Which database** you chose, PostgreSQL or SQLite.
- **The relevant log lines**, redacted as above, with enough context around
  them to see what came before the failure.

## Reporting a security problem

Do not open a public issue. Use GitHub's private vulnerability reporting on the
repository. Include reproduction steps, the version you tested against, and how
the panel was deployed. Coordinated disclosure is preferred, so you will be
asked to agree a publication date before an advisory goes out.

## Related

- [Troubleshooting](/en/guides/nasnet-linux/troubleshooting/)
- [Audit log](/en/guides/nasnet-linux/audit-log/)
- [Changelog](/en/guides/nasnet-linux/changelog/)