Administration

Faktory tries to be as simple to manage as possible. The most important element to understand is that Faktory has a notion of "environment", which is development by default. If you deploy Faktory, you should change this to production.

In Production

Faktory stores its data in /var/lib/faktory/db/faktory.rdb.

Faktory starts a local copy of Redis for storage, it must be installed and in the PATH prior to starting Faktory. The Faktory Docker image ships with its own Redis binary.

In Staging

Faktory 1.4+ supports a staging environment which is identical to production except:

• commercial functionality will run 24/7, as in production
• commercial versions are limited to 100 connections
• does not count against your license

In Development

Faktory stores its data in ~/.faktory/db/faktory.rdb. On macOS, brew install faktory will also install Redis.

Managing Redis

Faktory starts its own private copy of Redis to minimize ops hassle.

Instance Size

Redis is not a RDBMS designed to store terabytes on disk. It stores data in RAM but most of Faktory's data is short-lived so it's common to see the RDB only 5-10MB in size. If you plan to have queues with 100,000s of jobs enqueued at once OR foresee significant backups with millions of jobs, you will want to run Faktory on an instance with gigabytes of RAM. Otherwise any "modern" instance with a gig of RAM or more should be sufficient.

The main thing that takes memory is the size of your job arguments. If you pass large documents or serialized objects, RAM usage can quickly grow when queues back up. Keep your job arguments limited to immutable references and IDs.

Faktory itself takes about 10MB of RAM, as does Redis. You can run Faktory on a 256MB VPS without a problem.

Faktory requires a 64-bit Linux image. It does not offer a smaller, 32-bit option.

Backups

You can backup your Faktory data with a simple cp. This command in crontab will keep 60 backups, rotating one per minute:

* * * * * root cp /var/lib/faktory/db/faktory.rdb /backups/faktory.`date +%M`.rdb

Need to restore?

0. Stop faktory.
1. Backup faktory.rdb somewhere.
2. Copy one of those backups over faktory.rdb.
3. Start faktory.

Note: if you run plenty of workers, your queues will be empty 90% of the time. The only thing you'll be backing up are scheduled jobs and retrying jobs.

Replication

If you want real-time replication rather than minutely backups, you can use Faktory Enterprise’s Redis Gateway.

CLI access

Faktory talks to Redis over a local Unix socket at /var/lib/faktory/db/redis.sock. While Faktory is running, you can attach redis-cli. Keep it read-only unless you like to live dangerously and risk crashing Faktory:

$ redis-cli -s /var/lib/faktory/db/redis.sock
> info

Running behind a reverse proxy

You can put a reverse proxy like nginx in front of Faktory's Web UI.
If you're using a path instead of a dedicated domain, make sure to set the X-Script-Name header:

location /faktory {
   proxy_set_header X-Script-Name /faktory;

   proxy_pass   http://127.0.0.1:7420;
   proxy_set_header Host $host;
   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   proxy_set_header X-Scheme $scheme;
   proxy_set_header X-Real-IP $remote_addr;
}

<Location /faktory/>
   ProxyPass http://127.0.0.1:7420/
   RequestHeader set "X-Script-Name" "/faktory"
</Location>