Deploying Quirrel is straight-forward.
There are three main environment variables you need to specify in your deployment settings:
|Variable||Meaning||Where to get|
|access token for the Quirrel server.||Create a new Project + Client in the Dashboard.|
|The base URL of your deployment.||You probably know this. Something like |
|A 32-character-long secret used for end-to-end encryption of your jobs.||Can be generated using |
After setting these variables, you can deploy your application and Quirrel should be working. If it doesn't, feel free to reach out.
If you're using CronJobs(), make sure to run
quirrel ci during the deploy process.
If you're on Vercel, you can connect
QUIRREL_BASE_URL to your
Only do this for preview environments, not for production!
QUIRREL_BASE_URL is used to determine the deployment that your jobs should be executed on.
If you set it to
VERCEL_URL, that means all jobs will be executed on the exact deployment that they were
created on, excluding them from future bugfixes.
Hosted vs On-Prem
For most people, the hosted version of Quirrel is the easiest, and probably also cheapest way of using Quirrel (there's a free tier if your project is just starting out, and OSS and side projects can apply for discounts).
If you still want to host Quirrel yourself, you can do so using the Docker Image.
REDIS_URL should be set to a Redis connection string. For production deployments,
PASSPHRASES should be set to a
:-separated list of passphrases used for securing the token endpoints. Additionally, the deployment should be secured using HTTPS.
Using self-hosted Quirrel requires you to set the
QUIRREL_URL variable to the location of your deployment (it defaults to
QUIRREL_TOKEN can be obtained using the server's REST API. If a passphrase was set, it must be passed in using basic authentication.