Development strategies for multitenant platforms


Major issue when handling multiple customers in single platform is how to manage development environments – how to maintain code changes and how to work with version control systems (Git, SVN etc.).

This part will cover such questions. We will show you some different approaches of handling multitenancy in your codebase, facilitate code changes while still having possibility to maintain custom changes for tenants – from custom templates to whole custom-fitted code.

You may also be interested in other parts of the series:

  1. Design at the Clouds – the series
  2. Development strategies for multitenant platforms
  3. Database modeling in SaaS platforms

Different environments per tenant

Tenants can have very custom code changes. Development starts with single code base and while adding new customers with custom requirements we change default code to met their requirements.

Common usage is to deploy application on dedicated tenants’ servers. In some cases it could be needed due to policy of firms.

To allow such development flow, Version Control System (like Git) should be used. It’ll allow to have all the code changes for tenants spread across multiple branches and to simpler handling of changes in the baseline (using branch merges).

Development - custom codebase

Development – custom codebase


  • Dedicated changes for tenants – this model will be the most flexible for the customer’s requirements. In fact it could behave like having dedicated applications for tenants. Usage of systems like Git will simplify code changes – if some tenants won’t have any custom code it will be possible to use master branch for them.
  • Handling common changes – branches will let you to merge common changes like new functions, bug-fixes, from the baseline to tenants code. Process could be also automatized to handle such operation for bigger number of tenants.
  • Code security – dedicated tenant branches could be located in different repositories (servers) – that would allow to grant permission for developers only to specific customers code


  • Deployment process – deploy of the application could be difficult because we have to maintain multiple different servers
  • Maintenance – while adding custom code, the risk of bugs increase. We will have to prepare for many issues and change requests from tenants. Time needed to maintain contact with customers will be high.
  • Changes management – due to possibility of custom code changes in the core of the system, process of making changes, fixing common bugs is very hard to make. Developers will have to check if changes won’t break compatibility with the custom code of the other tenants.

Code with custom additions

Mainly, all of the code is common for every tenant. Changes implemented for them are being kept in single repository/single branch. We use our application logic to decide which code, templates etc. should be shown for a particular customer.

Development - single codebase

Development – single codebase

The code could be organized into modules – we’ve Core Module and specific modules for customers, which extend main code.


  • Easier deployment – deployment process is made from the same source repository, from single branch. Every server handles code of all of the tenants so there aren’t needed any special procedures.
  • Possibility of custom changes – while using given model we are still allowed to have custom code for customers using templates system and features of Object Oriented Programming like extending core classes/modules.


  • All of the code in single repository – as all of the code is being kept in single repository it won’t be possible to grant developers access only to code of “their” tenants. Also deployment will result in having code for all customers spread across all of our application servers
  • Bugs in dedicated modules – if the code of tenants modules isn’t appropriate isolated, bugs in them could affect the rest of the platform. If for e.g. new dedicated functionality causes compilation problems, the rest of the application could be unstable.

Last thoughts…

As you can see every strategy has some positive and negative sides. Decision which one will be used should be made based on keeping in mind how far dedicated changes for tenants can go.

If we’d like to allow more custom changes, the “different environments” will probably fit better. On the other hand if you’re planning that the only changeable part of the application will be the graphical template we should stay with single codebase.

The complexity of the code could drastically rise as we’re having more and more customers with specific requirements. To facilitate maintenance of the platform, we should automatize as much as we can:

  • Automatic deployment processes must be used, otherwise deploying application for 100 different tenants servers will be nightmare!
  • Continuous Integration will automatically check the project to decrease the risk of bugs.

…but that will be covered in next articles 🙂

Are you looking for experienced team to develop your SaaS platform? Check Octivi!

Looking to scale-out your
web application?

Hire Octivi!

Antoni is a Software Architect and Scrum Master at Octivi. He is responsible for software architecture of our key projects, he also holds Professional Scrum Master certificate.