Manage privacy and data handling

What data Quackback stores, how secrets and passwords are protected, what is sent to your AI provider, telemetry on self-hosted instances, and how to export or delete a user's data.

This article explains what data Quackback stores, how it protects secrets and passwords, what is sent to an AI provider, and how to export or delete a user's data. It applies to Quackback Cloud and to self-hosted instances. Where they differ, the difference is called out.

Who holds your data

Quackback Cloud: your workspace data is hosted by Quackback.
Self-hosted: your data stays on your own infrastructure, in your own PostgreSQL database and file storage. Data only leaves your servers through features you configure, such as AI features, integrations, and email delivery, plus an anonymous daily usage snapshot that is on by default and easy to turn off (see Telemetry below).

What Quackback stores

Category	Data stored
Users	Email address, display name, avatar
Posts	Title, content, board, status, tags
Votes	Who voted on which post, and when
Comments	Author, content, parent post
Conversations and tickets	Messages, attachments, and internal notes, when the support inbox is in use
Sessions	Session token, user, expiry
Integrations	OAuth tokens, webhook URLs, channel mappings

Encryption and passwords

Tokens and secrets

Integration tokens (for example Slack, Discord, GitHub, and Linear) and other stored secrets are encrypted with AES-256-GCM, using keys derived from the instance's secret key.

Warning: Self-hosted only: set a strong, unique SECRET_KEY (at least 32 characters) before you connect any integrations. Changing it later invalidates all stored tokens and sessions. See Environment variables.

Passwords

Passwords are stored only as salted hashes. Plain-text passwords are never stored.

Sessions

Session tokens are random. Sessions last 7 days and are refreshed every 24 hours while someone is active. Signing out ends the session immediately.

AI data handling

When AI features are turned on, Quackback sends the data each feature needs to an AI provider.

Self-hosted: data goes only to the endpoint you configure with OPENAI_BASE_URL and OPENAI_API_KEY. That can be OpenAI, an OpenAI-compatible gateway, or a model server you run yourself. See Configure AI features.
Quackback Cloud: AI features are run for you, so there's nothing to configure.

What is sent

Each feature sends only the content it works on. For example:

Feature	Data sent
Post summaries	Post title and content
Comment summaries	Comment text for the post being summarized
Semantic search	Post content, to create search embeddings
Duplicate detection	Pairs of candidate posts, to confirm whether they match
Quinn (AI agent and copilot)	The conversation, plus content from the knowledge sources you enabled

Quinn's knowledge sources

Quinn only uses the knowledge sources an admin explicitly turns on for it, such as help center articles, public posts, past conversations, internal notes, tickets, and changelog entries. A source that isn't enabled is never searched, so it's never sent to the AI provider. See Knowledge sources.

Turn AI off

Self-hosted: AI features stay off unless you configure them. To turn everything off, remove OPENAI_API_KEY and restart Quackback. To turn off a single feature, set its model override to off, for example AI_SUMMARY_MODEL=off.
Quackback Cloud: see Turn AI features off.

Turning AI off removes the features that depend on it, such as summaries, semantic search, and duplicate detection. Existing search embeddings stay in the database but are no longer used.

Telemetry (self-hosted)

A self-hosted instance sends one anonymous snapshot a day: a random instance ID, the version and platform, which modules and integrations are switched on, and usage counts reported only in ranges (such as 11-50). It never contains names, emails, URLs, hostnames, or content, and the server's IP address is not stored. See Telemetry for the full field list.

To turn it off, set:

DISABLE_TELEMETRY=true

Delete a user's data

To remove a portal user and their personal data:

Go to Admin > Users and open the user.
Click Remove from portal and confirm.

What happens:

Data	Result
User record and account	Deleted
Posts, comments, and conversations they wrote	Kept, but shown as written by "Deleted user"
Votes and subscriptions	Removed, and vote counts updated
Sessions	Ended

Note: Posts and comments are kept but anonymized, so discussions stay readable and vote history stays accurate.

Data retention

Posts and comments are kept until you delete them.
A deleted post can be restored for 30 days.
Sessions expire after 7 days without activity.

Export data

One board: export its posts as CSV from the board's Data tab in Admin > Settings > Boards.
The whole workspace: go to Admin > Settings > Imports & exports.

See Import and export data.

Tip: For a data access request, export the relevant data and filter it by the person's email address.

Your compliance responsibilities (self-hosted)

When you self-host, you run the software and control the data, so you are the data controller. Typical responsibilities include keeping a record of processing activities, answering data subject requests, reporting breaches to the authorities on time, and having a lawful basis for processing feedback. Use the user deletion steps above for erasure requests and the export options above for access and portability requests.

Security best practices (self-hosted)

Use TLS: run Quackback behind a reverse proxy with HTTPS. See Set up a reverse proxy.
Protect your secret key: keep SECRET_KEY out of version control, and remember that changing it signs everyone out and invalidates stored tokens.
Back up regularly: schedule automated database backups.
Limit access: give dashboard access only to people who need it, with the narrowest role that works.
Stay up to date: upgrade to new releases for security fixes.

See Configure team security for sign-in settings.