Product Opener is the Perl server behind the Open Food Facts database

The database is a crowd, and the server is a Perl application

Product Opener is the server software for Open Food Facts and Open Beauty Facts, released under the AGPL license and developed in Perl, HTML and JavaScript as free and open-source software. The data it serves is a database of food products with ingredients, allergens, nutritional facts and the other information available on product labels, and the striking number is the scale of the contribution: 25,000+ contributors have added 1.7 million+ products from 150 countries, scanning barcodes and uploading pictures of products and their labels with the Android, iPhone and Windows Phone apps. The data is published as open data and can be reused by anyone for any use, on the reasoning that food data is of public interest and must be open. That last point is the one that shapes the licensing and the architecture.

The stack is a set of services, not one process

The compose file shows how large the deployment is. The backend image is built from the repository and configured through a long environment variable list that names the external systems it talks to: MongoDB for the product data, Postgres, Redis, and then a set of sibling Open Food Facts services, among them Robotoff for the AI processing, the query service, the events service, Folksonomy, the facets knowledge panel, the NutriPatrol service, the recipe estimator, and the Odoo CRM. It also carries third party integrations such as the Google Cloud Vision API for image work, Crowdin for translations, Brevo for email, EcoBalise and a GeoLite2 path. That is the real shape of this project: an application that is the hub of a wider ecosystem, and an instance has to decide which of those services it actually needs.

The Perl side is built from a cpanfile on a modperl base

The Dockerfile is a good description of the Perl stack. The base image is a modperl setup on Debian trixie slim, with the user uid and gid kept at 1000 on production and aligned with your user in development, and a cache busting argument to force rebuilds when needed. The build installs cpanminus to pull the dependencies from the cpanfile, and the comment explains the policy: if the cpanfile specifies a newer version than apt has, cpanm will install the newer version. Alongside the usual build tools it installs imagemagick, graphviz and tesseract-ocr for image processing, lftp for file transfer, and a set of Perl modules that come from the distribution packages, with several of them marked for deletion after a Keycloak migration. The image also carries the Apache module for Perl and gettext, which is the Perl half of the translation pipeline.

One Makefile, several compose files, and a ban on cmd.exe

The Makefile is the entry point and it opens with a guard that refuses to run under cmd.exe, telling you to use a git bash console, and then forces bash everywhere. It reads an environment file and an optional extra environment file, sets the buildkit flags for Docker, and derives the CPU count from the host, capping it at eight because otherwise the build can run out of memory. The hosts variable lists the local domains the stack serves, including a world and a French variant of the product opener host and a static host, and the compose command is invoked with the environment file and the merged compose files for dependencies. The version comes from a version.txt file, and the project name is quoted as ProductOpener.

The front end is a separate concern with its own build

There is a Dockerfile.frontend alongside the main one, and a package.json for a project named product-opener that is private and carries the GNU Affero General Public License as its licence. The build is gulp, with a watch mode, and there is a dynamic build variant that runs an install first. The linter is split into three passes, one for JavaScript over the gulpfile and the html/js files, one for CSS, and one for SCSS, and the prepare script runs the Snyk protection tool, which is a dependency-level security check wired into the install itself. The JavaScript dependencies give a picture of what the interface does, with a barcode library, an image cropper, a map library with marker clustering, a vector map, a charting library, a file upload widget, a tag input, select2 and papaparse for parsing, plus the Open Food Facts web components and a Node client library of their own.

Design, community and release process

The project has a design charter and a nascent design system, and the stated rule is that features are thought through before implementation, with mockups kept in Figma for the current site and for future plans, and a separate design team repository for people who want to join that. The community runs on a weekly online meeting on Mondays at 17:00 Paris time, with a rule that agenda items are added early and reviewed in advance so the discussion is informed, that the meeting handles agenda items first and does collaborative bug triage if time permits, that the core decision making is timeboxed to 30 minutes with optional free discussion afterwards, and that comprehensive notes go into the weekly agenda. Development uses feature-based sprints tracked on a GitHub project board. Translations run through Crowdin, and the crowdin project identifier and key are part of the backend environment configuration.

The pieces around the server

Product Opener does not stand alone, and the README names the neighbours. Robotoff is the AI system, written in Python and also installable locally, and the repository description adds that for helping in Python you should look at Robotoff or the taxonomy editor. The Open Food Facts app can work with a local instance once dev mode is enabled, and the description of the repository asks for Perl, CSS and JavaScript coders. The Open Food Facts query service and the upcoming openfoodfacts-auth are named as related components, and an architecture diagram is available in the project organisation's repository. The repository root reflects the scale of the project, with directories for the CGI layer, configuration, the cron jobs, the HTML and SCSS front end, the Perl libraries, the overrides, the external data, the packager codes and the environment templates, plus a `madenearme` directory, a `howmuchsugar` directory, an `emb_codes` directory and a `misspellings` directory, which suggests the codebase is organised around the many small features the product database has grown.

Editorial conclusion

Adopt Product Opener if you want to run your own instance of a food product database with a full editing interface, an API and the data under your control, since the whole server is open source and the mobile app can be pointed at a local instance. Do not adopt it for a small side project, because the dependency surface is large and the AGPL terms are strict about network use. Verify first that you can run the Docker stack with MongoDB, Postgres and Redis, that the import path for existing product data is workable for your dataset, and that the API key handling and rate limiting configuration matches how you intend to expose the instance.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. openfoodfacts/openfoodfacts-server on GitHub
3. Project website
4. README
5. Releases