# Open Food Network: many food hubs, one Rails marketplace

> Open Food Network is a Ruby on Rails marketplace that lets independent food stores, food hubs and farmers share one ordering, catalogue and payment platform instead of each running its own shop. It is a heavy but well-trodden stack, and its AGPL licence plus its multi-tenant design are the two facts that decide whether it fits your organisation.

**openfoodfoundation/openfoodnetwork** — Connect suppliers, distributors and consumers to trade local produce.

- Repository: https://github.com/openfoodfoundation/openfoodnetwork
- Website: https://www.openfoodnetwork.org
- Stars: 1,297 · Forks: 803
- Language: Ruby
- License: AGPL-3.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/openfoodfoundation-openfoodnetwork

## A marketplace for the shops that local food hubs run

Open Food Network describes itself as an online marketplace for local food that enables a network of independent online food stores. Those stores are run by farmers and food hubs, and the README names the kinds of hub explicitly: co-operatives, online farmers markets and independent food businesses. The point of the project is that a hub running several producers does not need to build a storefront for each of them, and that a farmer does not need to become a payment company.

It is run by the Open Food Foundation as a not-for-profit open source project with a network of global affiliates, and the framing in the README is explicitly political: the stated goal is to disrupt concentration of power in global agri-food systems. That matters for how you read the feature set. The subjects in the repository topics are farmers, food hubs, rails, ruby and sustainable consumption, not checkout conversion.

The licence is AGPL, and the README states it as copyright the Open Food Foundation from 2012 to 2024, released under the AGPL licence. The last push to the default branch was on 2026-10-15, and the project ships regular tagged releases, with v5.7.16 published on 2026-10-12 after v5.7.15 and v5.7.14 in the preceding weeks.

## The local stack is Postgres, Redis and a webpack container

The development environment is defined in a compose.yaml file, and it is the clearest description of what the application actually needs. The database service is Postgres 16 with a named volume and a healthcheck that uses pg_isready:

```yaml
services:
  db:
    image: postgres:16
    restart: always
    environment:
      POSTGRES_PASSWORD: f00d
      POSTGRES_USER: ofn
```

Next to it sits a Redis service for cache and background jobs, and a bundler service that installs the gems once into a named volume and writes a checksum sentinel file so the other containers can wait for the bundle to be ready. The web service mounts the source, maps the port and waits for that sentinel:

```yaml
    ports:
      - 3000:3000
    environment:
      OFN_DB_HOST: db
      OFN_REDIS_URL: redis://redis/
      OFN_REDIS_JOBS_URL: redis://redis
```

A webpack service is a separate dependency of the web service, with its own development server on port 3035 and environment keys SHAKAPACKER_DEV_SERVER_HOST and SHAKAPACKER_DEV_SERVER_PORT. The container command waits for the gem sentinel, prepares the database with bundle exec rails db:prepare, installs the JavaScript dependencies with yarn install, and then starts the Rails server. Anyone planning a deployment should read that sequence as the minimum viable startup path.

## Rails with a shakapacker front end and a plugin-style engine layout

The application is Ruby on Rails, and the repository is unmistakably a mature Rails codebase. You can read the toolchain off the root directory: a Rakefile, a Gemfile and Gemfile.lock, a config.ru, a Procfile and a Procfile.docker, a .ruby-version and .ruby-gemset, .rspec, and a set of RuboCop configuration files including a relaxed style guide, a todo list and separate style guides for RSpec.

The JavaScript side is not a separate SPA. package.json names the package openfoodnetwork, pins yarn 1.22.2 as the package manager, and brings in hotwired turbo and stimulus, stimulus_reflex, shakapacker, webpack, postcss, sass-embedded and a tail of form and date controls such as flatpickr, select2 and tom-select, plus trix for rich text and leaflet with geosearch for maps. There is a jest.config.js next to that, and the .prettierrc.json and .haml-lint.yml files show that HAML views and Prettier formatted JavaScript coexist in the same tree.

The engines/ directory is the other structural signal. Breaking distinct areas of the product into Rails engines is how a large application stays navigable, and the engines directory is where you should look before assuming a feature is a plain model concern.

## The image build pins Ruby 3.4 on Alpine and adds the awkward dependencies

The Dockerfile shows exactly what the runtime needs, and the dependency list is a useful warning about what you are signing up for:

```dockerfile
FROM ruby:3.4.8-alpine3.19 AS base
RUN apk --no-cache upgrade && \
    apk add --no-cache tzdata postgresql-client imagemagick imagemagick-jpeg && \
    apk add --no-cache --virtual wkhtmltopdf
```

Ruby 3.4.8 on Alpine 3.19 is the base, with the timezone database and the PostgreSQL client added because the app talks to Postgres over the network, and ImageMagick with JPEG support because the application processes images. The wkhtmltopdf package is installed as a virtual dependency, which is the tell that the product generates PDF documents such as invoices or order documents.

The build is staged. A development base layer adds the compilers and headers needed to build native gems, including build-base, postgresql-dev, nodejs and yarn, and installs the wait-for-it helper script. A separate yarn-dependencies stage copies package.json and yarn.lock and runs yarn install --frozen-lockfile, so the JavaScript dependency layer is cached independently, and only then are the gems installed with bundle install. Copying the node_modules directory back out of that stage is the kind of detail that saves several minutes per rebuild and tells you the build was optimised by someone who rebuilt it many times.

## AGPL-3.0 is the licence that decides the hosting question

The repository is under the AGPL-3.0 licence, and package.json repeats it in the license field for the JavaScript side. The README records the copyright as the Open Food Foundation from 2012 to 2024, released under the AGPL licence.

Why this matters operationally: AGPL carries a network use clause, and the practical consequence for a project like this is that if you modify the software and run it as a service for other people, the licence asks that your modified version be offered to those users. A food hub running its own instance for its own community is one case. A consultancy or a software vendor who runs a hosted, customised Open Food Network for many customers is a different case, and the obligations do not vanish because the instance is behind a login. This is not legal advice, and anyone in that position should read the licence text and LICENCE.txt and take their own advice, but the point belongs in the evaluation rather than in a footnote.

Two other things are worth noting. The project is operated by a foundation with a network of global affiliates rather than by a company selling support, and the README invites contributions through Slack, a handbook and a discussion forum. That model is a strength for a civic project and a support question for a business that needs a response time.

## Provisioning lives in a separate Ansible repository

If you are planning a server rather than a laptop, the README points you away from this repository. Provisioning is handled by the project's Ansible playbooks in the openfoodfoundation/ofn-install repository, and configuration of new servers is covered by a separate Super Admin Guide. The repository also ships a Dockerfile, Dockerfile.ubuntu, a compose.yaml, a .dockerignore and a Procfile.docker, so container based deployment is a supported path, and the .secrets.example file at the root shows where environment specific values are expected to go.

The .env, .env.development and .env.test files at the top of the tree, along with config/ and the .foreman file, suggest the classic Rails split between configuration layers, and the Procfile is the equivalent for a non-Docker process manager. The swagger/ directory points to a published API description, and db/ holds the migrations, which is where you look when you need to know what the schema expects.

For a first evaluation the fastest route is the documentation the README points to: the GETTING_STARTED and CONTRIBUTING guides for a development environment, the User Guide at guide.openfoodnetwork.org for the features and tutorials, and the ofn-install playbooks for a server.

## How the test suite is run and what it tells you

Testing is part of the project's identity rather than an afterthought. The README has a dedicated section that routes contributors to a #testing channel on Slack and to a Welcome New QAs board with good first issues, split between manual testing and automated testing with RSpec and Capybara. It names BrowserStack as the manual testing tool and says BrowserStack provides open source projects with unlimited free accounts. Automated test parallelism is handled by KnapsackPro, which the README says offers unlimited plans for non-commercial open source projects.

Both tools are external services, and that is a real consideration for a self-hosted contributor. A developer without a BrowserStack account can still write and run RSpec and Capybara specs locally, but the cross-browser manual pass that the project relies on is harder to reproduce on your own. The .simplecov and .undercover files in the root show that coverage measurement is part of the workflow, and the .rspec file, the spec/ directory and the knapsack_rspec_report.json file at the root are the concrete artefacts of that.

There is a build badge in the README pointing at a GitHub Actions workflow, and .github/ sits at the top of the tree, so continuous integration is part of the project structure. A fork that wants to be mergeable is expected to work in that pipeline.

## The trade-off is a large stack for a specific kind of operator

The honest case for Open Food Network is an operator who already runs a food hub and needs something beyond a single shop. The project gives independent stores, shared catalogue and ordering behaviour, and the association of many producers under one marketplace, which is exactly the arrangement that makes a farmers market or a co-op hard to run by hand. For a group of sellers who need one checkout, one customer list and one view of who is buying what, that is a lot of machinery to reuse.

The cost is visible in the repository. A Postgres database, a Redis instance, a webpack front end build, a background job system, a Rails engine layout, PDF generation through wkhtmltopdf, image processing through ImageMagick, and a JavaScript toolchain that has to be installed alongside the Ruby one. There is no single service you can start and immediately have a marketplace. Anyone adopting this is taking on a Rails application with a decade of accumulated structure, and the AGPL terms are the second decision that cannot be deferred.

So the question is not whether the project is capable, its releases run weekly and its community is organised, but whether a multi-producer food operation is your situation. If it is, the difference between installing this and writing the same thing is a decade of product decisions you get for free. If you run a single stall, none of it applies.

## Conclusion

Open Food Network suits a food hub, co-op or group of farmers who want a shared storefront, catalogue and ordering system under one operation rather than separate shops, and it is a poor fit for a single seller who only needs a checkout page. Before you commit, read the GETTING_STARTED guide against your own machine, confirm that the AGPL-3.0 obligations are acceptable for how you will host the platform, and look at the ofn-install Ansible playbooks, because provisioning and running the Postgres, Redis and webpack services is the real cost of this stack.

## FAQ

### What is Open Food Network and who runs it?

It is an online marketplace for local food that lets independent food stores run by farmers and food hubs share one platform, and it is supported by the Open Food Foundation and a network of global affiliates as a not-for-profit open source project.

### What licence is Open Food Network released under?

The repository is under the AGPL-3.0 licence, and the README records the copyright as the Open Food Foundation from 2012 to 2024. The package.json file repeats AGPL-3.0 in its license field.

### What services does the development environment need?

The compose.yaml file defines a Postgres 16 database with a healthcheck, a Redis service for cache and jobs, a bundler service that installs gems and writes a checksum sentinel, and a webpack service that the web service waits for. The web service then prepares the database and starts Rails.

### How do I install Open Food Network on a server?

The README points provisioning to the project's Ansible playbooks in the openfoodfoundation/ofn-install repository, with a separate Super Admin Guide for configuration. The repository itself ships a Dockerfile, Dockerfile.ubuntu, a Procfile.docker and a compose.yaml for container based runs.

### How is the test suite organised?

Automated tests use RSpec with Capybara, manual cross-browser testing uses BrowserStack, and parallel test runs use KnapsackPro, which the README says offers unlimited plans for non-commercial open source projects. Coverage measurement is configured through the .simplecov and .undercover files.

## Sources

- [License: AGPL-3.0](https://github.com/openfoodfoundation/openfoodnetwork/blob/master/LICENSE)
- [openfoodfoundation/openfoodnetwork on GitHub](https://github.com/openfoodfoundation/openfoodnetwork)
- [Project website](https://www.openfoodnetwork.org)
- [README](https://github.com/openfoodfoundation/openfoodnetwork/blob/master/README.md)
- [Releases](https://github.com/openfoodfoundation/openfoodnetwork/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openfoodfoundation-openfoodnetwork