In Ocean Protocol, marketplaces and publishers play different roles (outlined in the [Terminology page](/concepts/terminology/)), but both roles can be played by the same person or organization. Initially, we anticipate that will be the most common setup. As a result, this guide explains how to set up and run a combined marketplace/publisher (for now).
- data sets stored in Azure Storage (i.e. with "core.windows.net" in their URL). See [the tutorial about setting up Azure Storage to work with Ocean Protocol](/tutorials/azure-for-brizo/).
- data sets stored in Amazon S3 storage (i.e. with "s3://" in their URL). See [the tutorial about setting up Amazon S3 storage to work with Ocean Protocol](/tutorials/amazon-s3-for-brizo/).
- data sets stored in on-premise storage. See [the tutorial about setting up on-premise storage to work with Ocean Protocol](/tutorials/on-premise-for-brizo/).
Note: You can use _all_ of the above. You aren't restricted to using only one storage provider.
For more examples and inspiration, check out [the source code for Pleuston](https://github.com/oceanprotocol/pleuston) and the [the source code for the Commons Marketplace](https://github.com/oceanprotocol/commons). Both have an Apache v2 open source license. Both use React and squid-js. Both are "serverless" apps: they run entirely in the browser and have no server-side component.
A marketplace/publisher app could have both a back-end component and a front-end component. The main consideration is that you should probably use a programming language with an existing Squid library:
**At the time of writing, there was no production-ready Ocean Protocol network, but once one _does_ exist, the following must be done to run your marketplace/publisher app in production.**
When developing your marketplace/publisher app, you will probably use Barge to run all the Ocean Protocol components on your local machine. When it comes time to go to production, you will have to run some of those components in production:
