Security & privacy
BugTrack is self-hosted — your bug data lives on the server you install it on and goes nowhere else. This page explains exactly what the app does and doesn't do with your data, and what security controls are built in.
Data ownership
When you install BugTrack, your bug reports, comments, attachments, and user accounts are stored in a SQLite database file on your own server. No BugTrack server is in the path between your team members and your data.
There are no BugTrack accounts to create, no cloud sync, and no central server that your install reports home to. The app runs entirely within your own infrastructure.
What BugTrack does and doesn't send externally
| Action | Goes where | Condition |
|---|---|---|
| Version check (update available?) | releases.bugtrack.tech | Always, from the Updates page — sends your current version and, if APP_URL is set, your install's URL |
| Downloading an update | releases.bugtrack.tech | When admin clicks "Apply update" |
| Password reset email | releases.bugtrack.tech mail relay | When a user requests a password reset — the email address is relayed to send the reset link via Resend |
| Slack notifications | Your Slack webhook URL | Only if a project has a Slack webhook configured |
| Bug assignment / comment emails | Your SMTP server | Only if SMTP is configured in Settings |
| Crash reports | BugTrack's Sentry project or your own | Off by default. Admin must explicitly enable in Settings |
| Analytics / tracking | None | No analytics code runs in the app itself |
Authentication
- JWT-based sessions. Tokens are signed with a secret generated per install and stored in the database. No token ever leaves your server boundary.
- Login rate limiting. 20 attempts per IP and 8 per email address in a 15-minute window. No brute-force on known accounts.
- Secure secret generation. If no
JWT_SECRETis set (or if the environment value matches a known published default), BugTrack generates a private secret on first start and keeps it in the database — so an install that never configured a secret is not running on a key everyone knows.
File uploads
- Uploaded images are checked on both MIME type and file extension — not just the client-declared type.
- Files are stored under a randomized name with an extension derived from the verified MIME type, never from the client's filename.
- The
/uploadspath is served withX-Content-Type-Options: nosniffand a restrictive Content Security Policy. Anything that is not a known-safe raster image (JPEG, PNG, GIF, WebP) is forced to download rather than render, neutralising any HTML, SVG, or script content that may have slipped through on older installs.
CORS
CORS is same-origin by default — only the same domain can call the API. Set
CLIENT_ORIGIN only if the UI is hosted separately from the API,
which is not the typical setup.
Error responses
Server error responses do not echo internal exception messages. Filesystem paths, SQLite schema details, and stack traces are not returned to the client.
Crash reporting
BugTrack can send crash reports when something goes wrong. This is off by default and must be explicitly enabled by an admin in Settings. When enabled, a report contains:
- The error and where in the code it happened
- The BugTrack version
- The HTTP path of the request that failed (query strings stripped)
- The account's numeric ID (not name or email)
Bug content, comments, attachments, passwords, SMTP credentials, and email addresses
are stripped before any report is sent. If you'd rather send crash reports to your
own Sentry project, set SENTRY_DSN and BugTrack will use that instead.
Password reset
Password reset emails are relayed through BugTrack's own mail relay (hosted at releases.bugtrack.tech) using Resend. This is the only path that routes through BugTrack infrastructure — it exists because someone locked out of the app can't reach Settings to configure SMTP. The relay receives only the user's email address and the reset link, sends the email, and does not retain either.
All other email notifications (assignments, comments, status changes) use your own SMTP settings and never pass through BugTrack infrastructure.
Security disclosures
To report a security issue, contact us via the contact form. Please include steps to reproduce and the version of BugTrack you're running.