Multi-tenancy and deployment

Learn how multi-tenancy and deployment have improved working with Frontend.

  • After completing this page, you should be able to:

    • Identify the key changes to multi-tenancy and deployment in Frontend Studio in the past year.
  • Multi-tenancy

    Multi-tenancy hub is one of the most exciting changes to our overall architecture, making the development of new features a lot easier. It brings the following improvements for you:

    • Eliminates the need to create sandboxes. You no longer need to wait for the sandbox creation process to finish before you can test for any errors in their creation.
    • Eliminates the need to use sandboxes to develop extensions; an environment in a development cluster is created automatically.
    • Decreases website latency since cloud functions run on a cluster close to your customer's target location.

    If you've already set up your projects on the multi-tenant architecture, you do not need to take any actions.
    If you've set up your projects on the single-tenant architecture, you need to perform some changes. For more information, contact your Customer Success Manager.

    Project setup updates

    To kickstart your improved experience working in a multi-tenant environment, we need to review the adjustments that need to be made.

    Multi-tenant flag

    We've introduced a new flag for initializing the project. The following command enables the new architecture and offers you access to all the new improved features that come with it.

    frontastic init --multitenant

    Since the release of CLI version 2.4.0, the multi-tenant parameter is no longer necessary. Projects are now automatically detected as multi-tenant. Use the parameter if using a previous CLI.

    API token

    To connect the hub and your local project, get the API token from the Studio.

    Sudo password

    When using the new multi-tenancy flag, in some cases, you must provide your sudo password to update files like /etc/hosts.

    You're now ready for development! Great, isn't it?


    We've made deployments easier; to take full advantage of it, use our built-in Continuous Integration (CI) features. If you use a custom Git repository, you'll have to set up CI by yourself.

    Frontend follows a trunk-based model, with the main branch as the source of truth. Let's have a look at the details.

    Branch deployments

    Each commit creates a new build for the respective branch. The deployed build will remain active for one hour, after which the build is removed and reactivated if space is available for a new branch deployment.
    The maximum number of active branch deployments is 20. For newer branch deployment requests, a 503 response code will be returned.

    Netlify deployment previews

    After each pull request, the commercetools Frontend CI builds your backend, while Netlify deploys your frontend website and connects it to the new backend. After the Netlify deployment is complete, a comment—with a link to the deploy preview—is added to your pull/merge request. However, to use this, your Netlify administrator must activate this feature for you.


    To help you get started faster and enjoy project development work instead of setup issues, we've extended the installation troubleshooting section in our documentation for comments related to ENOENT or Yarn install errors.

    Test your knowledge