3. Add a Redis export worker
The web app queues a job and immediately returns its ID. A separate process reads the notes and generates JSON. This chapter stores that JSON in Redis; the next moves it to S3.
1. Create Redis
Dashboard: in rust add Database notes-queue, engine Redis, 1 GB storage;
wait until running. In notes-web → Config, attach it with variable name REDIS_URL.
Do not use the default DATABASE_URL, which already points at PostgreSQL.
CLI:
paas dbs create notes-queue --type redis --storage-gb 1 -o "$TUTORIAL_ORG" -p examples -e rust
paas apps attach notes-web notes-queue --env-var REDIS_URL -o "$TUTORIAL_ORG" -p examples -e rust
2. Create the worker from the same code
Dashboard: add a Background Worker named notes-worker, Framework rust
(the same selection as the web app), Repository The environment’s shared repository,
Directory blank, Process type worker, one replica. A worker has no public HTTP endpoint.
Open its Config tab, set DATABASE_ENGINE=postgresql, and attach both notes-db as
DATABASE_URL and notes-queue as REDIS_URL.
CLI:
paas apps create notes-worker --worker --framework rust --shared-source --process worker -o "$TUTORIAL_ORG" -p examples -e rust
paas config set DATABASE_ENGINE=postgresql -a notes-worker -o "$TUTORIAL_ORG" -p examples -e rust
paas apps attach notes-worker notes-db -o "$TUTORIAL_ORG" -p examples -e rust
paas apps attach notes-worker notes-queue --env-var REDIS_URL -o "$TUTORIAL_ORG" -p examples -e rust
The worker must have its own attachments; the web app’s configuration is not inherited. The process value is a named buildpack process, not a shell command. See the worker source for the job loop.
3. Push and check the worker
Trigger a shared build after both apps have their configuration:
git commit --allow-empty -m "Deploy web and export worker"
git push d2o main
Dashboard: wait for both apps to run, then open notes-worker → Logs and look for
Worker ready. CLI: paas watch -o "$TUTORIAL_ORG" -p examples -e rust follows both apps; then use
paas logs -a notes-worker -o "$TUTORIAL_ORG" -p examples -e rust. The web app must still answer /health.
4. Export and recover a queued job
In the browser, click Export notes, wait for the download link, and open the JSON.
It must contain your saved note. Logs show Export ready: <id>.
To check queueing while the worker is unavailable, open its dashboard Overview and use − in the Replicas row to reach 0,
then confirm the stop, or run paas scale 0 -a notes-worker -o "$TUTORIAL_ORG" -p examples -e rust. Request an export; it stays queued.
Use + in the same row to restore replicas to 1 (or paas scale 1 -a notes-worker -o "$TUTORIAL_ORG" -p examples -e rust); the same job should complete.
If the UI polling times out after 90 seconds, query /exports/<id> and download from
/exports/<id>/download once ready, or submit another export.
The worker uses Redis Streams with a consumer group. It acknowledges only after saving the result. A replacement worker claims unacknowledged jobs idle for 30 seconds; writes use the same export ID so a retried job overwrites the same result. Failures remain queued for retry and appear in worker logs. This is at-least-once delivery, not exactly-once delivery. Do not use this loop unchanged for side effects such as charging a payment.
Redis itself is not backed up by the platform. For essential jobs, retain enough information in the primary database to recreate or reconcile them. See durability and recovery and production preparation.