wavebreakmedia/burritodeps repository overview

⁠burritodeps

Pre-baked Docker base image and dependency manifest for the Burrito media processing service (DesignWizard).

⁠Overview

burritodeps is a dependency-only repository that has no application source code. Its sole purpose is to build and publish the wavebreakmedia/burritodeps Docker base image — a pre-installed layer containing Node.js, FFmpeg, Google Chrome (headless), international fonts, and all npm packages required by the Burrito service. The actual Burrito application code lives in the sibling burrito repository, which uses FROM wavebreakmedia/burritodeps as its Dockerfile base. By separating heavy dependency installation into a standalone image that changes infrequently, Burrito's CI/CD build times are dramatically reduced.

Burrito belongs to the DesignWizard pillar. See the workspace map: ../WBM_ECOSYSTEM_ARCHITECTURE.md⁠.

⁠What it does

• Builds a Docker image (wavebreakmedia/burritodeps) on top of wavebreakmedia/node-ffmpeg:latest.
• Installs Google Chrome Stable and a broad set of international fonts (Japanese, Chinese, Thai, Arabic, FreeFont) required for headless rendering and multilingual text composition.
• Declares all production npm dependencies for the Burrito service, including image/video processing libraries and private WBM packages.
• Provides npm scripts and .npmrc configuration for local development against the Burrito service codebase.

⁠How it works

⁠Build layer strategy

The Dockerfile extends wavebreakmedia/node-ffmpeg:latest (which already bundles Node.js and FFmpeg):

FROM wavebreakmedia/node-ffmpeg:latest

RUN wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | gpg --dearmor -o /usr/share/keyrings/google-chrome.gpg \
  && echo "deb [arch=amd64 signed-by=...] http://dl.google.com/linux/chrome/deb/ stable main" > /etc/apt/sources.list.d/google-chrome.list \
  && apt-get update \
  && apt-get install -yq google-chrome-stable \
       fonts-ipafont-gothic fonts-wqy-zenhei fonts-thai-tlwg fonts-kacst-one fonts-freefont-ttf \
       libxss1 libxtst6 --no-install-recommends \
  && rm -rf /var/lib/apt/lists/*

Chrome is required because Burrito uses Puppeteer for headless browser-based composition rendering. The fonts are necessary for multilingual text rendering in design templates.

⁠How the actual Burrito service uses this image

The burrito repository's Dockerfile begins with:

FROM wavebreakmedia/burritodeps

ENV HOME=/home/app
WORKDIR $HOME/burrito

COPY fonts/*.ttf /usr/share/fonts/
ENV PUPPETEER_SKIP_CHROMIUM_DOWNLOAD true

COPY .npmrc $HOME/.npmrc
COPY package.json $HOME/burrito
RUN npm install --unsafe-perms

COPY . $HOME/burrito
RUN npm run headless:prod

EXPOSE 7070 7171
CMD ["node", "index.js"]

The Burrito service itself (index.js) listens on two ports:

• Port 7070 — main Express HTTP API
• Port 7171 — headless browser static asset server (/headless)

It also starts SQS consumers for these queues (see current burrito repo, config/_default/servers.json):

• burritoBNDownload (bulk/brand-name download)
• burritoDownload (standard download)
• burritoVideoDownload (video download)
• burritoDebug (debug queue)
• burritoTemplatePackage (template packaging)

Each queue is toggled via environment variables (READ_BN_DOWNLOAD_QUEUE, READ_DOWNLOAD_QUEUE, etc.).

⁠npm package manifest

The package.json in this repo contains the pinned/ranged dependency versions that were locked at the time of the last base-image rebuild. Because burritodeps is updated infrequently, its dependency versions may lag behind the live burrito service (see Caveats below).

⁠Tech stack

Private packages (GitHub Package Registry npm.pkg.github.com):

• @designwizard-com/dw-log-module ^1.0.0
• @designwizard-com/wbm-assets-url ^1.0.5

⁠Project layout / entry points

burritodeps/
├── Dockerfile       # Builds wavebreakmedia/burritodeps base image
├── package.json     # npm dependency manifest for the Burrito service
├── .npmrc           # Private registry config (GitHub Package Registry)
├── connections.md   # AI-generated relationship notes (for tooling)
└── description.md   # AI-generated description (for tooling)

There is no index.js, src/, or any application source file. All logic lives in the burrito sibling repository.

⁠Configuration

⁠Private package registry

.npmrc is pre-configured with a GitHub Package Registry auth token for the @designwizard-com and @wbm-waveflow scopes:

"@designwizard-com:registry"="https://npm.pkg.github.com/"
"@wbm-waveflow:registry"="https://npm.pkg.github.com/"
//npm.pkg.github.com/:_authToken=<token>

When rebuilding the base image in CI, ensure the token in .npmrc has read:packages access to the WavebreakMedia GitHub organisation.

⁠npm scripts

The localwm script sets the following environment overrides:

NODE_ENV=production
READ_DOWNLOAD_QUEUE=false
READ_BULK_DOWNLOAD_QUEUE=false
READ_RESIZE_QUEUE=false
READ_WATERMARK_QUEUE=true

Note: these env var names (READ_WATERMARK_QUEUE, etc.) are from an older naming convention; the current burrito service uses READ_BN_DOWNLOAD_QUEUE, READ_VIDEO_DOWNLOAD_QUEUE, etc.

⁠Environment variables for the Burrito service

These are set in the Burrito service config, not here, but are relevant to understand what the base image supports:

⁠Data flow & relationships

burritodeps itself has no runtime data flow — it is a build artifact, not a running service. All data flow described below belongs to the burrito service this image powers.

⁠Inputs / upstream

• AWS SQS queues consumed (by burrito, not by this repo directly):
  • burritoBNDownload — bulk/brand-name download jobs
  • burritoDownload — standard composition download/render jobs
  • burritoVideoDownload — video processing jobs
  • burritoDebug — debug/test messages
  • burritoTemplatePackage — template packaging requests
• AWS S3 buckets read: composer.user.images, wbm.compositions (JSON composition definitions)
• HTTP callers: DesignWizard frontend / wbmcomposer backend calls the Express API on port 7070 for image resizing, video probing, and composition rendering

⁠Outputs / downstream

• AWS SQS queues produced: The burrito service sends error messages to wfError-queue and API callback messages to wfAPI.fifo. No queues are produced by this deps repo itself.
• AWS S3 buckets written: Rendered images and processed assets are written back to composer.user.images / dw.user.images buckets.
• External services called: DesignWizard API (http://api.designwizard.com/api), Redis cache (dw-redis-burrito-db.iussnl.0001.euw1.cache.amazonaws.com:6379), Elasticsearch (for logging via bunyan-elasticsearch)

This repo is effectively a leaf node in the workspace dependency graph — it has no in-workspace sibling repos feeding it and produces no messages consumed by other repos. Its only consumer is the burrito repo (which uses its Docker image as a base).

⁠Local development / running / deployment

⁠Building the base image

# From the burritodeps directory
docker build -t wavebreakmedia/burritodeps .

This is the only reason to work in this repo. The resulting image is pushed to Docker Hub and consumed by the burrito build pipeline.

⁠Running the Burrito service locally (from the burrito repo)

The burritodeps scripts assume you are running the burrito service source code from this same directory (the actual source is in the sibling burrito repo):

# Install dependencies
npm install

# Development mode (auto-reload, NODE_ENV=development)
npm run dev

# Local mode (auto-reload, NODE_ENV=local)
npm run local

# Watermark queue only (production-like)
npm run localwm

# Run tests
npm test

⁠Docker Compose

The docker-compose file lives in a sibling docker-compose directory:

npm run docker-compose
# equivalent to: cd ../docker-compose && docker-compose up

⁠Caveats / notes

1. No source code: This repository contains only a Dockerfile, package.json, and .npmrc. Any issue or feature work on the Burrito service must target the burrito sibling repository.

2. Stale dependency versions: The package.json here represents an older snapshot of Burrito's dependencies. The live burrito service has since migrated to AWS SDK v3 (@aws-sdk/client-sqs, @aws-sdk/client-s3) and newer sqs-consumer versions. These burritodeps packages are not automatically kept in sync with the burrito repo and must be manually updated before rebuilding the base image.

3. Stale queue env var names: The localwm npm script references READ_WATERMARK_QUEUE, READ_BULK_DOWNLOAD_QUEUE, and READ_RESIZE_QUEUE. These names no longer match the current burrito service config, which uses READ_BN_DOWNLOAD_QUEUE, READ_VIDEO_DOWNLOAD_QUEUE, READ_BURRITO_DEBUG_QUEUE, and READ_BURRITO_TEMPLATE_PACKAGE_QUEUE.

4. Dual logging libraries: Both bunyan and pino are declared as dependencies. The active burrito service may only use one — verify before upgrading.

5. Auth token in .npmrc: The .npmrc contains a hardcoded GitHub Package Registry auth token. Rotate this token if it has been compromised or if access needs to be revoked.

6. Chrome EULA in Docker: The Dockerfile installs google-chrome-stable from Google's official Debian repository. Ensure the build environment accepts Google's Terms of Service before running in CI.

7. PUPPETEER_SKIP_CHROMIUM_DOWNLOAD: Must be set to true in the burrito Dockerfile (it is) to prevent Puppeteer from downloading a second Chromium binary, since Chrome Stable is already present in this base image.