Deploying multiple apps from a mono repository on Scalingo

Some teams of developer prefer to gather the source code of all the applications they are working on in a single repository instead of the traditional one repo per application. This code organization strategy is often called "mono repository" or "monorepo" in short. Deploying such applications requires some configuration. Follow our steps to deploy multiple applications from code hosted in a mono repository.

Why a monorepo?

Imagine your project follows the monorepo pattern and has the following code structure:

my-app
├── api
├── front
├── admin
└── cockpit

It's easy to imagine that these applications form a homogeneous whole with a standardized communication method (synchronous HTTP calls, message queuing, etc.) between them.

Monorepos have several advantages:

Simplified organization
Easy to coordinate changes across applications
Simplified dependencies
Single lint, build, test and release process
Single place to report issues
Tests across modules are run together → finds bugs that touch multiple modules easier
Simplify large-scale code refactoring – Since developers have access to the entire project, refactors can ensure that every piece of the project continues to function after a refactor.
Smooth collaboration across teams
Code reuse

In our example, a release is the release of the whole set of api, front, admin and cockpit applications and by setting up a robust Continuous Integration pipeline you can ensure that the 4 applications will work correctly together.

And by the way, Google uses monorepo.

Deployments on Scalingo

With such a setup, you will need to create 4 applications on Scalingo: one for the API and 3 for the other applications. You can use the web dashboard or the CLI to do so.

Using the GitHub integration

In the "Code" section of each application on the web dashboard, enable the GitHub integration with your mono repository. You can activate the auto-deploy on one of the branch so that the application automatically get deployed when a commit is pushed on this branch. It's better if you choose the same branch for the 4 applications.

With the code of each application being in a different subfolder, you must teach Scalingo where to find the source code by defining the PROJECT_DIR environment variable of each application to match the corresponding folder. For instance, the API application should have the following environment variable: PROJECT_DIR=api.

Review Apps

If you've set up the GitHub integration and activate the Auto Deploy feature, you can also activate Review Apps. Review Apps are applications built dynamically every time a Pull Request is open against the connected GitHub repo. Of course this feature will work as well in the case of a monorepo!

For example, if the PR #42 is opened against our example monorepo, Scalingo will automatically build and deploy 4 Scalingo applications named api-42, front-42, admin-42 and cockpit-42 available behind their own scalingo.io domains. And they will follow the standard Review Apps workflow: when the PR is closed these 4 temporary applications will be destroyed by Scalingo.

The Git Only Alternative

If your code is not hosted on GitHub, the workflow is a bit more manual. We will configure Git to send the code to different remote. After creating the 4 apps on Scalingo, go to the root directory of your project and add the 4 remotes with:

git remote set-url scalingo --push --add git@scalingo.com:api.git
git remote set-url scalingo --push --add git@scalingo.com:front.git
git remote set-url scalingo --push --add git@scalingo.com:admin.git
git remote set-url scalingo --push --add git@scalingo.com:cockpit.git

When you want to deploy a modification, just push to the scalingo remote: