# Best way to design my development setup for multiple projects **URL:** \ **Category:** Ignition\ **Tags:** ignition81, vision\ **Created:** [March 14, 2022, 4:48pm UTC](https://forum.inductiveautomation.com/t/best-way-to-design-my-development-setup-for-multiple-projects/57169 "2022-03-14T16:48:05Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Brianw\_Wolowich](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/brianw_wolowich/32/32743_2.png) [@Brianw\_Wolowich](https://forum.inductiveautomation.com/u/Brianw_Wolowich)\ **Post date:** [March 14, 2022, 4:48pm UTC](https://forum.inductiveautomation.com/t/best-way-to-design-my-development-setup-for-multiple-projects/57169/1 "2022-03-14T16:48:05Z")
I will need to be able to create multiple projects for multiple customers. There will be over 40 projects in total. What is the best way to setup my development computer so I don’t have 40 VMs. The sites are all individual and different but our structure of equipment naming is common across all sites. ie: Conveyor 1 would use tags CV01\_Aux, CV01\_FLA, etc. The first idea I had was use one gateway with each project using a different TagProvider named after the project number. Then in Vision Client Tags have a sitenumber memory message tag. The value would equal the TagProvider name so then I can use this in Expression bindings. Most templates and control windows would be common across all projects. The Main windows being unique to each project. Are there any glaring problems with my idea that would make it more complex than having 40 virtuals? I am interested what others have done. What are the upside/downside of your method? ---
**Author:** ![josborn](https://avatars.discourse-cdn.com/v4/letter/j/4bbf92/32.png) [@josborn](https://forum.inductiveautomation.com/u/josborn)\ **Post date:** [March 14, 2022, 11:57pm UTC](https://forum.inductiveautomation.com/t/best-way-to-design-my-development-setup-for-multiple-projects/57169/2 "2022-03-14T23:57:59Z")
Your question is pretty open ended. If you havent already, I suggest you review the documentation on security zones / roles to start, but also check out [Project Inheritance](https://docs.inductiveautomation.com/display/DOC81/Project+Inheritance). I am a little confused on the 40 VM though, do you mean 40 virtual machines running the gateway, if so licensing is going to be a problem unless they are running in trial? IA also has a best practices guide for this that you may find informative: > **[Ignition 8 Deployment Best Practices](https://www.inductiveautomation.com/resources/article/ignition-8-deployment-best-practices#deployment-environments)** > > This guide is aimed to help you better understand how to deal with deploying Ignition applications and provides some best practices for setting up your development and testing workflow. ---
**Author:** ![Chris\_Bingham](https://avatars.discourse-cdn.com/v4/letter/c/e5b9ba/32.png) [@Chris\_Bingham](https://forum.inductiveautomation.com/u/Chris_Bingham)\ **Post date:** [March 15, 2022, 12:59am UTC](https://forum.inductiveautomation.com/t/best-way-to-design-my-development-setup-for-multiple-projects/57169/3 "2022-03-15T00:59:55Z")
I am curious about other approaches as well. In my scenario, I have different projects which are at different Ignition versions (albeit all are 8.1+). As I am not well-versed in multi-project development within a single gateway, I opted for a single Ubuntu VM with separate Ignition installations/folders, one installation per project, none are licensed… The time to switch between projects is fairly quick, and forces me to be intentional in any project-specific development: cd /usr/local/bin (my installation location) sudo ignition\_proj1/ignition.sh stop sudo ignition\_proj1/ignition.sh remove sudo ignition\_proj2/ignition.sh install sudo ignition\_proj2/ignition.sh start So far, this has been working for me. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 15, 2022, 1:11am UTC](https://forum.inductiveautomation.com/t/best-way-to-design-my-development-setup-for-multiple-projects/57169/4 "2022-03-15T01:11:15Z")
Use 40 VMs. Or 40 docker containers. Don’t mix different clients on the same gateway. Figure out how to repeatably deploy VMs with scripts, or use IAs scripts with Docker. Figure out how to closely match your client’s operating environments so a gateway backup can just be dropped into your corresponding VM. Developing under trial mode is perfectly viable for all but stress testing before deployment. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [March 15, 2022, 1:18am UTC](https://forum.inductiveautomation.com/t/best-way-to-design-my-development-setup-for-multiple-projects/57169/5 "2022-03-15T01:18:22Z")
> [@Chris\_Bingham](#): > > The time to switch between projects is fairly quick, and forces me to be intentional in any project-specific development: > cd /usr/local/bin (my installation location) > sudo ignition\_proj1/ignition.sh stop > sudo ignition\_proj1/ignition.sh remove > sudo ignition\_proj2/ignition.sh install > sudo ignition\_proj2/ignition.sh start > So far, this has been working for me. I think this is a reasonable approach to having multiple Ignition versions installed. You can use the zip distribution and not the installers. Also, there's no need for the service install and remove on Linux - you can just start and stop the gateways as you need, unless there's some reason you need a dev gateway to automatically start with the OS. ---
**Author:** ![bmusson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bmusson/32/87530_2.png) [@bmusson](https://forum.inductiveautomation.com/u/bmusson)\ **Post date:** [March 15, 2022, 2:27am UTC](https://forum.inductiveautomation.com/t/best-way-to-design-my-development-setup-for-multiple-projects/57169/6 "2022-03-15T02:27:24Z")
I'd suggest looking into Docker Compose. It's a really great and lightweight way to store and run entire systems (as long as containers exist for everything in your clients' environment). But Phil hit the nail on the head: > [@pturmel](#): > > Figure out how to closely match your client’s operating environments so a gateway backup can just be dropped into your corresponding VM. If Docker doesn't work for your systems (something Windows dependent perhaps), then definitely use individual VMs. ---
**Author:** ![Brianw\_Wolowich](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/brianw_wolowich/32/32743_2.png) [@Brianw\_Wolowich](https://forum.inductiveautomation.com/u/Brianw_Wolowich)\ **Post date:** [March 15, 2022, 2:31pm UTC](https://forum.inductiveautomation.com/t/best-way-to-design-my-development-setup-for-multiple-projects/57169/7 "2022-03-15T14:31:07Z")
I want to thank everyone for their time and responses. Unfortunately my employer has pulled the plug on my investigation of Ignition. I definitely enjoyed playing with the new environment. From my stand point Ignition has a lot of bonus’ however we use an in house program that is the brains of our system as well as data collection, reports, etc. Which means we only would use ignition for some display graphics as well as the gateway to our PLC/Field Devices. Thanks again for all the responses. There definitely is a great community here!