What infrastructure do I need to run an OFN instance and what are the estimated associated costs?

As a hub manager, whether you have your own front end or use the basic OFN front end, you want to ensure that the site remains available at most times. So you need to ensure the infrastructure is well set up so that it ensures a high availability. This will be addressed through the provisioning of redundant servers, so that the site will continue to run if any server has an issue. Additionally, you can store regular database backups in multiple locations so that the site can be recovered in the case of an emergency.

What does the OFN requires in terms of load?

We have measured load performances based on the Australian server. So you can use that as a reference to scope your target infrastructure, but you will of course need to test your own load locally to make sure the assumptions apply to your specific situation.

By average response time

OFN Australia shows an average response time of approx 700ms per request. Given that there are three web server workers on the Australian server, the throughput is: 60 / 0.7 x 3 = 257 RPM (Requests Per Minute)

By load test

Load testing (200 different users in one hour) the Australian server remotely shows a real-world response rate of 186 RPM.

To take our estimates forward, we’ll use the lowest of these estimates (186 RPM). A crucial part of the work would be lowering this to provide a more responsive site to customers as well as to improve scalability. However, let’s use the current figure to generate a pessimistic estimate.

Broad estimation of the need

All figures are based on statistics pulled from the Australian server where during peak hours there is an average of:

  • 8 page view per order
  • 14 % of daily page views

All figures are calculated with servers running at 75% load at peak to provide some headroom (140 RPM).

You need to calculate of course based on your own assumptions in terms of number of orders expected.

Example 1: Assumptions = 2 hubs, 260 orders per week per hub = 87 orders/day in total (6 open days)

→ 87 * 8 = 696 page view/day
→ 14% in peak hour = 100 page views or 1.6 RPM
The estimate is well below the server capability of 140 RPM. In theory we could run this pilot off a single server. However, we recommend running two web servers and two database servers. That provides you with redundancy in case one server fails and prepares the infrastructure to scale in the future.

Example 2: The project scales to 100 hubs > Assumption = 85300 orders per week= 14217 order/day (6 open days)

→ 14,217 * 8 = 113,736 page view/day
→ 14% in peak hour = 15,923 page views or 265 RPM
This could be served by 2 web servers (running at 75% capacity). As a starting point, we could propose the following architecture:

  • 1 load balancer
  • 2 web servers
  • 2 database servers (the second as a hot standby)
  • 1 delayed job worker

We need to add to this production infrastructure a build pipeline infrastructure, staging servers that enable the developers to test the new versions in real conditions before pushing to production, in order to avoid any disturbance / bug in production.

Associated infrastructure costs

Of course the cost will depend on the provider you work with to host the infrastructure.

Broad estimation done by OFN Australia team based on AWS excluding data charges in US$ excl. VAT (price for Europe zone - London)

  • Load balancer: $21.46/month

  • c4.xlarge server (web, db): $173.01/month
    So for the example above, the estimated monthly cost would be:

  • 1 load balancer = $21.46

  • 5 servers = $692.04
    Total: $886.51/month (833€ on 19/01/2017)

  • You’ll need on top some server that stores static files like products images. Today OFN Australia uses AWS S3 service that costs around 30 AUD = 20€ HT per month.

  • We also need to add the infrastructure for the non-production servers (build pipeline). We have not included that in this first estimation. You can count around 60€ HT / month for a simple build pipeline (we need to adjust depending on your requirements). Or depending if you have a simple or complex build pipeline (with pre-production servers) you might you to have a “production like” staging.

  • So you can add at least 80€ per month to that cost for the build pipeline and image storage.

Also bear in mind that someone will need to dedicate the time to set up the whole infrastructure. You should count 5 to 8 days of work (so around 3-5 K€ depending on local rates)


  • You can get much greater performance out of one server (perhaps 2x) by working on optimising the application.
  • We haven’t addressed here database scaling. It’s likely that you’ll need far fewer web servers and far more resources dedicated to the database. However, this estimate serves as a starting point to examine the infrastructure cost of the full rollout of the project.
  • Since this is a project supporting local infrastructure and sustainability, you might want to choose a hosting company using renewable energy might be a consideration.

The system administration

In order to have reactivity in case there is any issue on a server (attack / load issue / etc.) you need to have someone available when we need, and reactive in case of emergency. Again, depending on the expected service level, the cost will differ. Usually hosting providers ensure a level 1 support with high reactivity for all the basic problems. But you need to have someone around who can fix any problem that could happen on the production server.

Application management

You need also to be able to regularly upgrade the version, when new releases with new functionalities and security/bug patches are available. As bug correction and application deployment are not a sysadmin job but a dev job, this will need to be counted in the development time needed on your project. The developer needs to test the new version in a staging environment, make sure with the product owner that everything is ok, no bug, test the performance, etc. And then deploy in production.

Basic adaptations and localization

For a local instance to be fully operational, you will need to make sure the basic localization features meet your needs: translations, VAT management, invoice frame, payment methods, etc.
Of course we can support you in identifying the adaptations required and find the skills/people to make those adjustments.

The OFN community can support you in setting up you your local instance

Contact us at hello@openfoodnetwork.org