# Quirrel queues background jobs for serverless functions

> Quirrel is an MIT licensed task queue built for serverless applications, with delayed, fanout, recurring and CRON jobs, a development UI and end-to-end encryption. The project now belongs to Netlify, its newest release tag dates from 2023, and the container image still runs Node.js 16.

**quirrel-dev/quirrel** — The Task Queueing Solution for Serverless.

- Repository: https://github.com/quirrel-dev/quirrel
- Website: https://quirrel.dev
- Stars: 929 · Forks: 69
- Language: TypeScript
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/quirrel-dev-quirrel

## A queue designed around the limits of serverless runtimes

Quirrel describes itself in one line as the task queueing solution for serverless, and its tagline in the README is the Task Queueing Solution for Serverless.

The problem it addresses is specific to that deployment model. A function that returns a response to a client cannot stay running to do work later, and a platform's own cron or queue facilities differ from one vendor to the next. So the pattern Quirrel offers is a queue service that your function talks to, with the scheduling and retry semantics living outside the function.

The README lists the job types it supports: delayed jobs, fanout jobs, recurring jobs and CRON jobs. Delayed jobs are the base case, a task that runs at a chosen future time. Fanout covers one logical job that expands into many. Recurring and CRON cover repetition, with CRON being the familiar schedule expression form.

Two entry points are published: the landing page at quirrel.dev and the documentation at docs.quirrel.dev. The documentation also hosts the API reference for the queues and a getting started guide, and there is a separate tutorial on dev.to for building a water-drinking reminder with Next.js and Quirrel, which is the fastest way to see how the pieces fit.

## Client libraries and a development UI are the developer experience story

The README states the values Quirrel holds to, and the first of them is developer experience, delivered through what it calls tailormade client libraries and the development UI.

The client libraries are the integration surface. The documentation links them per queue under api/queue, which implies the API is shaped per queue rather than as one global namespace, and that the client is generated or tailored to the queues you define instead of being a hand-written wrapper for a fixed set of endpoints. The second part of the same value is the development UI, which the documentation introduces in the Next.js getting started page under the heading meet the development UI.

That last piece matters more than it sounds. A queue that schedules work an hour from now is hard to develop against if you have to wait an hour to see the result. A development UI means the state of delayed, recurring and failed jobs is visible while you build, which is the difference between a two minute feedback loop and a manual wait.

The repository layout backs this up. There is a development-ui/ directory at the top level with its own build script, and a docs/ directory, plus an examples/ folder containing integrations for blitz, express, netlify, next, nuxt, redwood, remix and sveltekit. Eight frameworks in one repository is a strong signal about the intended audience.

## End-to-end encryption is the stated privacy position

The second value the README lists is privacy, delivered through end-to-end encryption.

That is a meaningful claim for a hosted queue. A job payload often contains what a user typed, what they bought or which link they clicked, and a queue that stores it in plaintext on someone else's infrastructure is a different proposition from one where the server cannot read it. The client libraries and the encryption scheme together are what make the hosted offering at quirrel.dev usable for sensitive payloads, and the tailormade client libraries are probably where the key handling lives.

What the README does not do is describe the scheme. It does not say which algorithm is used, how keys are distributed or rotated, or whether encryption is available for every job type. Those details are in the documentation rather than in the repository, which is a reasonable place for them but a real gap for anyone doing an internal security review from the README alone.

The third stated value is free software, and the README notes the project is MIT licensed. The fourth is easy setup, through the hosted offering and what it calls easy on-prem.

## Self-hosting: the container, the port and the Node version

The Dockerfile in the repository root is short and shows the shape of a self-hosted deployment.

```dockerfile
FROM node:16

WORKDIR /usr/src/app

COPY package*.json ./
RUN npm ci

COPY . .

RUN npm run build

ENV RUNNING_IN_DOCKER true

EXPOSE 9181
CMD node dist/cjs/src/api/main.js
```

The image builds from node:16, installs dependencies with npm ci, runs the build and then starts the API entry point, dist/cjs/src/api/main.js, exposing port 9181. There is also a Procfile and a fly.toml at the repository root, which are the usual markers for deployment on a Platform as a Service and on Fly.io respectively.

The RUNNING_IN_DOCKER environment variable is set inside the image, so the application can detect a containerised run.

Two things to weigh here. The node:16 base image is old, and the manifest's engines field lists node 14, 15, 16, 17, 18, 19 and 20, so the whole supported range predates current Node.js releases. If you run this yourself you are choosing to build and patch a container on an older runtime line, and that is a maintenance decision you have to own. The other point is that the Dockerfile copies package*.json and runs npm ci, which requires a lockfile in the build context; the repository uses package-lock.json, so that is satisfied.

## A dual CJS and ESM build driven by schema generation

The build scripts in the manifest show how the package is assembled, and they are more interesting than a typical TypeScript compile.

```json
"build:schemas": "json2ts -i src/api/scheduler/schemas/ -o src/api/scheduler/types/",
"build:tsc:esm": "tsc --module es2015 --outDir dist/esm",
"build:tsc:cjs": "tsc",
"build:proxies": "./generate-proxies.sh",
"prepack": "run-s build"
```

The build script chains the schema step, the TypeScript compiles and the proxy generation. The first stage generates TypeScript types from JSON Schema files in src/api/scheduler/schemas/ using json2ts, so the scheduler's types are derived from a schema rather than written by hand. Then TypeScript compiles twice, once to CommonJS and once to ES modules, which is why the manifest carries both a main entry at dist/cjs/src/index.js and a module entry at dist/esm/src/index.js. The proxies stage runs a shell script, generate-proxies.sh, and the development UI has its own separate build.

The published files list confirms the output shape: dist plus the declaration, CommonJS and ESM JavaScript files, with jest.config.js explicitly excluded and README.md included.

Tests run under jest with the telemetry disabled in the test script, DISABLE_TELEMETRY=true, and the configuration file jest.config.js is at the root. That telemetry flag is a small signal worth noticing in a project whose stated value is privacy.

## Quirrel joined Netlify, which changes who maintains the roadmap

The most consequential line in the README is at the top, above the badges: Quirrel joins Netlify, with a link to an article about the acquisition and the author joining Netlify.

That is an acquisition, and it changes the question from whether the project is maintained to who maintains it. The repository is not archived and the last push was on 2026-10-05, so commits are still landing. But the release history tells a different story: the newest tags are v1.14.1 from 2023-06-26, v1.14.0 from 2023-06-20 and v1.13.4 from 2023-04-03, with the manifest version at 1.14.1. So the published package version has not moved since June 2023 even though the repository has received commits since.

That gap is the thing to understand before you build on it. Commits after the last tag are untagged work that npm cannot give you, and a project whose owner now sits inside a larger platform company may prioritise the hosted offering over the open source release.

For the record on licensing, the licence field on the repository says MIT, which is permissive. The repository also carries the usual governance files, CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md and CHANGELOG.md, and renovate.json suggests dependency updates are automated. The .kodiak.toml file at the root is a pull request automation configuration, which is consistent with a project under corporate stewardship.

## Conclusion

Quirrel suits teams running scheduled or deferred background work on serverless platforms who want one queue API across many frameworks and would rather not assemble a broker and a scheduler themselves. It does not suit a team that needs a current Node.js baseline, since the manifest lists engines from Node 14 to 20 and the container image is built on node:16, and it does not suit anyone who needs a guaranteed release cadence from the open source repository. Before adopting it, check whether the Netlify-hosted offering or your own deployment fits your data residency needs, and read the end-to-end encryption notes in the documentation, because that claim is what makes the hosted option acceptable for sensitive payloads.

## FAQ

### What job types does Quirrel support?

The README states that Quirrel supports delayed jobs, fanout jobs, recurring jobs and CRON jobs. Integration details are in the documentation at docs.quirrel.dev, including per queue client libraries.

### How do I run Quirrel on my own infrastructure?

The repository Dockerfile builds from node:16, runs npm ci and npm run build, sets RUNNING_IN_DOCKER and exposes port 9181 before starting node dist/cjs/src/api/main.js. The repository also includes a Procfile and a fly.toml.

### Who owns Quirrel now?

The README announces that Quirrel joins Netlify, with a link to an article about the acquisition. The repository is not archived and the last push was on 2026-10-05, while the newest release tag is v1.14.1 from 2023-06-26.

## Sources

- [License: MIT](https://github.com/quirrel-dev/quirrel/blob/main/LICENSE)
- [Project website](https://quirrel.dev)
- [quirrel-dev/quirrel on GitHub](https://github.com/quirrel-dev/quirrel)
- [README](https://github.com/quirrel-dev/quirrel/blob/main/README.md)
- [Releases](https://github.com/quirrel-dev/quirrel/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/quirrel-dev-quirrel