Frequently Asked Questions

What can QQueue send?

Three kinds of email through one delivery pipeline: campaigns (a template to a list or segment, scheduled or recurring), transactional email (a public API plus the qqueue-sdk), and manual one-off sends from Email Studio — all on your own SMTP, sharing the same contacts, tracking, suppressions, and webhooks.

Is QQueue open source?

Yes. QQueue Core — the self-hosted platform — is open source under AGPL-3.0-only. If you run a modified version as a network service, the AGPL requires you to make the corresponding source available to that service's users. See Licensing.

Which license does it use?

• Core: AGPL-3.0-only (root LICENSE).
• apps/cloud/: proprietary commercial license (managed-cloud scaffold).
• SDK (qqueue-sdk): MIT.
• Docs: CC-BY-4.0 where a documentation-specific notice says so.

The QQueue name, logo, and marks are trademarks — see Trademark.

Can I self-host it?

Yes — self-hosting is the primary path. Run it locally with Docker for Postgres and Redis (see the Quickstart), or in production with docker-compose.prod.yml (Caddy + API + worker + Postgres + Redis) behind your own domain (see Deploy).

How much does it cost?

QQueue Core is free and open source (AGPL-3.0). You pay only for the server you run it on and your own SMTP provider — there are no per-contact or per-send fees. A managed QQueue Cloud is planned but not yet available.

Who owns my data?

You do. QQueue runs on infrastructure you control; contacts, content, events, and API keys live in your database and are never sold, rented, or shared.

Can I use it with Mailcow?

Yes. QQueue sends through Mailcow's standard SMTP submission — no Mailcow-specific provider is required. See the Mailcow setup guide.

Which email providers are supported?

Any standard SMTP server (Mailcow, Amazon SES, Postmark, Resend, Brevo, and others via their SMTP interface). QQueue uses one generic Nodemailer SMTP provider. Provider-native API integrations are not implemented — connect via SMTP. See the SMTP provider guide.

Does it support transactional email?

Yes — a public transactional send endpoint with API keys, inline or template-based content, scheduled sends, machine-readable error codes, and rate limiting. See Transactional API and Send your first email.

Does it support campaigns?

Yes — send-now, one-shot scheduled, and recurring campaigns (cron expression

• timezone), with pause/resume, duplication, and per-campaign analytics. See Send your first campaign.

Does it track opens and clicks?

Yes — built-in open tracking (1×1 pixel) and click tracking (link rewriting), secured with HMAC-signed tokens. APP_URL must be publicly reachable over HTTPS. Opens undercount because many clients block images — expected.

Does it support webhooks?

Yes — outbound signed webhooks (HMAC QQueue-Signature, 5 retries with backoff, delivery history, manual retry) for email events, plus a normalized inbound endpoint for ESP bounce/complaint events.

Is there an SDK? What does it do today?

Yes — qqueue-sdk (MIT, on npm). It currently exposes a single method, QQueueClient.sendEmail, wrapping the transactional send endpoint. Clients for templates, contacts, campaigns, webhooks, and API keys are not yet available.

Is there a cloud version?

QQueue Cloud is planned, not yet available. The repo contains a fenced proprietary apps/cloud/ scaffold, but managed hosting, billing, quotas, hosted onboarding, deliverability tooling, and cloud admin dashboards are not built yet. See the Cloud boundary.

What are the known limitations?

Not yet implemented: organization invitations, member-management UI, a usage metrics dashboard, provider-specific inbound webhook adapters, and SDK methods beyond sendEmail. There is no email verification or MFA yet. All managed-cloud/commercial features are unstarted. See Status for the full audit.

Is it production-ready?

QQueue is a feature-complete, self-hosted beta for early technical users. The full verification suite — lint, typecheck, build, test (a comprehensive automated suite), a Docker-backed end-to-end smoke test, license audit, and cloud-boundary check — passes. It's beta software: expect rough edges, review the security and operational notes, and pin a known-good commit for production. Work through the Beta launch checklist before going live.