Self-Hosted
Quackback is open source under AGPL. Run the same software we run on Cloud, on infrastructure you control — with the responsibilities that come with it.
Why self-host
Self-hosting is a deliberate trade. You take on the operational work; in return, you get full ownership and zero vendor surface.
Customer feedback never touches a third party. Useful when legal, procurement, or a customer contract rules out external SaaS.
No per-seat fees, no usage tiers from us. You pay for the server, Postgres, and Redis you would have run anyway.
AGPL gives you the codebase. Add internal integrations, change the UI, or fork it for a regulated environment.
AWS, GCP, Azure, Hetzner, on-prem, or a single VPS. Same image, same migrations, same behaviour as Cloud.
What you take on
When Quackback runs on your servers, security, uptime, and compliance are yours to define. Cloud is the right call for teams that want us to carry that weight. If you want to carry it, read on with eyes open.
TLS termination, firewall rules, SSH access, container isolation, secret storage. Quackback ships sensible defaults; production hardening is on you.
New Quackback releases ship to GHCR. Pulling them, testing against your config, and rolling them out is your call.
Schedule Postgres dumps (or PITR), store them somewhere durable, and test restores. We do not see your data and cannot help if it is gone.
Health checks, error tracking, latency alerts, and an on-call rotation if your team relies on it. There is no Quackback SLA on self-hosted.
SOC 2, HIPAA, ISO 27001, GDPR DPAs, regional data residency — all properties of your environment, not of the Quackback binary. You design the controls, you carry the evidence.
If something breaks at 2am, you triage. We help by keeping the project open-source, documented, and reproducible — but the pager is yours.
Quackback is provided under AGPL-3.0 — without warranty, as the licence spells out. No security or compliance assertions transfer from the project to your deployment.
Requirements
Quackback runs on modest infrastructure. A single VPS plus a managed Postgres covers most teams; scaling up is a matter of bigger instances and replicas.
Deployment
Every release publishes a Docker image to GHCR. Pull it directly, or use one of the wrappers around it.
Production
Pull ghcr.io/quackbackio/quackback and point it at your own Postgres and Redis. Upgrades are pull, restart.
Local / single VPS
docker compose up brings the full stack — Postgres, Dragonfly, MinIO — onto one box.
Managed
Railway, Render, or Fly.io run the image with managed databases behind it.
Custom
Bun, Postgres with pgvector, and Redis directly. For constrained or platform-specific environments.
# Pull the published image from GHCR
$ docker pull ghcr.io/quackbackio/quackback:latest
# Point it at your Postgres + Redis
$ docker run -d -p 3000:3000 \
-e DATABASE_URL=$DATABASE_URL \
-e REDIS_URL=$REDIS_URL \
-e SECRET_KEY=$SECRET_KEY \
-e BASE_URL=https://feedback.acme.com \
ghcr.io/quackbackio/quackback:latest
✓ Migrations applied
→ Listening on :3000Migration
Moving off a SaaS tool does not mean starting over. Quackback preserves posts, votes, comments, statuses, and user data.
Dedicated importer that connects to your Canny account and migrates posts, votes, comments, statuses, and users. Vote counts and board structure are preserved. No CSV export step.
CLI importer (bun run import:uservoice) takes a UserVoice export and brings suggestions, votes, comments, and categories across. Status mappings are configurable.
Generic CSV import for everything else — Productboard, Aha!, Trello, spreadsheets, internal tools. Map your columns to Quackback fields and run a single import command.
Compare
Both run the same code. The difference is who carries the ops. For most teams, Managed Cloud is the right call — self-host when you have a specific reason to.
Best when ease, uptime, and getting back to building the product matter more than running the box yourself.
Best when data must stay on your infrastructure, you have strict compliance requirements you control, or you want to fork and customise the source.
FAQ
You run the same software we run on Cloud, on infrastructure you control. Your feedback data lives on your servers, sign-in flows through your identity provider, and you decide when to upgrade. In exchange, you own the ops: patches, backups, uptime, monitoring, and compliance.
Quackback is free under AGPL — there are no licence fees, per-seat charges, or usage limits from us. Your costs are the boxes you run it on. A small VPS plus a managed Postgres covers most teams for $10–30 a month; production setups with backups, monitoring, and a CDN cost more.
You are. When you self-host, every security control — TLS certificates, firewall rules, patch cadence, secrets management, audit logging, backup encryption — is yours to configure and maintain. Same for compliance: if you need SOC 2, HIPAA, ISO 27001, GDPR DPAs, or anything similar, that's on your environment, not on Quackback. We ship the software; you ship it safely.
Yes. There is a dedicated Canny importer that connects to your Canny account and migrates posts, votes, comments, statuses, and users with no CSV wrangling. A UserVoice CLI importer and a generic CSV importer cover other sources.
Use Quackback Cloud. Same codebase, same features, but we run the servers, certificates, backups, patching, and incident response. You can move between Cloud and self-hosted later — your export is portable in both directions.
Yes, for normal operation. Quackback needs to reach your SMTP or transactional email provider for notifications, OAuth providers if you use them for sign-in, and any integrations you enable (Slack, GitHub, Linear, etc.). A fully air-gapped deployment is possible if you disable email, integrations, and OAuth, but most teams allow egress through their normal proxy.
Free, open source, and yours to operate.