# Self-hosting a QR generator

> Self-hosting a QR generator buys two things no hosted service can promise: a provable privacy boundary and permanence on your own terms. UseQR is MIT-licensed — clone github.com/rajkaria/useqr, pnpm install, pnpm verify, and deploy the Next.js app anywhere Node runs; the whole surface, API and MCP server included, comes with it.

Source: https://useqr.app/docs/developers/self-hosting-a-qr-generator · Last reviewed 2026-08-21 · UseQR is free forever, MIT licensed, no signup.

---

## What self-hosting actually buys

Two guarantees, and only self-hosting provides either in provable form:

**Privacy you can audit.** A hosted generator asks you to trust a privacy policy. Your
own instance replaces trust with a network tab: when the code runs on your
infrastructure — or fully [client-side](/docs/security/client-side-vs-server-side-qr-generation),
as UseQR's static generation does — WiFi passwords, payment details and vCards
demonstrably never cross a boundary you do not control. For regulated environments,
that is the difference between a compliance conversation and a compliance document.

**Permanence on your terms.** Free web services die; paid ones get acquired and
sunset. Static QR codes survive their generator, but the *tooling* — your templates,
your bulk workflows, your API integrations — does not, unless you hold the code.
[What happens when a QR service shuts down](/vs/what-happens-when-a-qr-service-shuts-down)
is the full argument; self-hosting is its strongest answer, and it is why an MIT
licence is a feature, not a footnote.

What it does **not** buy: dynamic QR codes. Editable destinations and scan analytics
need a persistent redirect service with uptime obligations — a different, heavier
project. If you need those, weigh a
[paid platform](/vs/when-a-paid-qr-platform-is-worth-it) honestly.

## Self-hosting UseQR

Everything at useqr.app — generator UI with all 32 payload types, the
[keyless API](/docs/developers/free-qr-code-api-no-key), decode and verify endpoints,
batch, the [MCP server](/docs/developers/qr-code-mcp-server), the
[scanner](/scan) and [validator](/validate) — is one MIT-licensed monorepo. There is
no cloud half, no feature flag between the public instance and yours.

```bash
git clone https://github.com/rajkaria/useqr
cd useqr
pnpm install
pnpm verify                      # lint + typecheck + test + build
pnpm --filter @useqr/web dev     # local instance
```

`pnpm verify` is worth running before you deploy: the test suite includes the
render → decode round trips, so a green build means your instance provably produces
codes that scan. The repo is two packages — `@useqr/core` (matrix, styled SVG
renderer, typed payload builders, the decode-verify loop) and the Next.js web app.
The canonical origin is configuration rather than code — set the environment
variables described in the repo's deploy documentation and every generated URL,
sitemap entry and API self-reference follows your domain.

Deployment is standard Next.js: the reference instance runs on Vercel, and anywhere
that runs a Node server (or an equivalent platform adapter) works. The API routes
that rasterise PNGs use a native renderer, so match your build platform to your
runtime platform — the usual
[serverless native-binary caveat](/docs/developers/qr-codes-in-serverless-functions).

## Lighter-weight alternatives

Self-hosting a full toolkit is not always the right size. Honest options down the
ladder:

- **A library, in-process.** If one service needs codes, `npm i` a
  [generator library](/docs/developers/qr-code-libraries-compared) and skip the HTTP
  hop entirely.
- **QuickChart**, open source, if you want a small single-purpose image service and
  no UI.
- **`qrencode` on a box** for shell-driven internal tooling.

And the zero-effort rung: static generation on the public UseQR instance already runs
client-side in your browser, which covers the privacy requirement for individual use
without hosting anything.

## Operating notes

Set long-lived immutable caching on generated images
([the strategy](/docs/developers/caching-and-cdn-strategy-for-qr-images)) and a CDN
in front if the instance is public — deterministic output makes your origin traffic
approach one render per unique code. Track the upstream repo for decoder and payload
spec updates; payment formats like [PIX](/docs/payments/pix-qr-code-format) and
[UPI](/docs/payments/upi-qr-code-format) evolve, and a stale payload builder fails at
the bank, not in your logs.

## FAQ

### Why self-host a QR code generator?
Two reasons stand up: a provable privacy boundary for sensitive payloads, and permanence — your tooling cannot be sunset, paywalled or acquired out from under you. If neither applies, a keyless hosted API is less work.

### Is UseQR really fully open source?
Yes — MIT, at github.com/rajkaria/useqr. The public instance and a self-hosted clone run the same code: generator UI, REST API, decode and verify endpoints, batch, MCP server and scanner. There is no proprietary tier.

### What do I need to run UseQR myself?
Node and pnpm to build (pnpm install, pnpm verify), then any host that runs a Next.js app. Configure the canonical origin via environment variables so generated URLs point at your domain, and match build and runtime platforms for the native PNG rasteriser.

### Does self-hosting give me dynamic QR codes?
No. UseQR generates static codes, self-hosted or not. Editable destinations and scan analytics require a persistent redirect service — either build that as its own project or use a dynamic QR platform and accept the dependency.

## Try it

- https://useqr.app/url
- https://useqr.app/wifi
- https://useqr.app/validate