Add-ons for running processes or task queues

Add-ons are deployed in tandem with your website, and provide additional products, services, or support packages related to your website.

Note

Add-ons are currently available by request only. Contact support to create or manage add-ons.

Process

Process add-ons run in the background, using your website codebase, but are not exposed to the web. A common use-case is to run a task queue such as Celery or Huey.

All processes use the exact same runtime environment configuration as your website. For example, if your website is running Python 3.13, and has custom environment variables set, each process will use the same version of Python and have the same environment variables as your website. Additionally, each process’s environment will pip install from the same requirements.txt file before finally launching the process.

Following the Python example: when your website is deployed, a fresh Python environment is created and your website code is loaded into it as usual. The website is then started (i.e. Django, Wagtail, etc.) as normal. Immediately after the website environment is created, an additional identical environment is created for each of your processes. Note that each environment is separate, and may be started at slightly different times depending on variables such as: how long the pip install runs, how long the process takes to start, server load, etc. Therefore, it is important to be mindful of race conditions that could occur when trying to communicate with a process that may not yet have started.

Process command

Each process has a single command that will be executed after the environment is ready (i.e. after the pip install is finished, environment variables have been loaded, etc.).

The command must be an executable, such as python or a shell script. The command also must never exit. If the command exits, it may be re-started automatically by CodeRed Cloud.

For example, let’s start a Huey task queue. From the CodeRed Cloud dashboard, set your Process to: ./cr-run-huey.sh. Then in your codebase, create the file cr-run-huey.sh as so:

#!/bin/sh
exec huey_consumer.py my_app.huey

The environment variable WORKERS is the recommended number of worker processes/threads based on the amount of resources allocated to your CodeRed Cloud plan. Each use-case is different, however, creating too many worker threads may potentially harm performance if the server does not have enough resources to reasonably handle that many threads.

In many cases, a simple task queue such as Huey may run best with a single thread. But for busier websites that need to process a higher volume of tasks, you can set the number of worker threads as so:

#!/bin/sh
exec huey_consumer.py my_app.huey -k thread -w ${WORKERS}

Filesystem access

Your website, and all processes, use a shared filesystem for the /www and /log directories. /www is where your code lives, and for Django and Wagtail sites, may also contain media files, a SQLite database, etc. All processes have read and write access to this shared filesystem with the same permissions.

Communication between processes

In a typical Django or Wagtail site, all processes, including the website, have shared access to the filesystem (see above) and the database. Therefore it is highly encouraged to use the filesystem (such as SQLite) or the database as a message broker.

Processes DO NOT have shared memory, as they run in isolated environments.