---
title: "Upgrading Corridor"
description: "How to upgrade an existing Corridor installation, including which install commands to re-run and how to restart each process."
---

Before performing an upgrade, it's always recommended to make a backup of the
`Metadata Database` and `Settings` before running the upgrade commands. The backup related details can be
found [here](/technology/maintenance/backups/).

To upgrade an existing corridor installation, the following steps need to be followed:

- Get the updated installation bundle
    - Once the installation bundle is received, place it in the `/tmp/` folder of the installation machine
      and unzip the contents in the `${CORRIDOR_HOME}/build` folder of the same machine. The bundle under `/tmp` folder
      can then be deleted.

- Re-run the corridor `install` script for the component being upgraded

    - The below components of Corridor need to be upgraded:

        - API: `python ${CORRIDOR_HOME}/build/install api --install-dir $CORRIDOR_HOME`
        - APP: `python ${CORRIDOR_HOME}/build/install app --install-dir $CORRIDOR_HOME`
        - Worker-API: `python ${CORRIDOR_HOME}/build/install worker-api --install-dir $CORRIDOR_HOME`
        - Worker-Spark: `python ${CORRIDOR_HOME}/build/install worker-spark --install-dir $CORRIDOR_HOME`
        - Jupyter: `python ${CORRIDOR_HOME}/build/install jupyter --install-dir $CORRIDOR_HOME`

    :::note
    - These commands need to be run on the machines on which the corresponding processes are running
    - By default, when upgrading corridor, the config files will not be over written. To over write the
        configuration file, use the `--overwrite` flag in the `install` script.
    :::

- Restart corridor

    - Each of the Corridor processes need to be restarted after an upgrade.
        The restart command would depend on how the corridor processes are handled at the system level. The below
        section lists down the commands which would be used for the most common processes managers.

        1. Corridor's `daemon` capability
            - API:
                - `${CORRIDOR_HOME}/venv-api/bin/corridor-api daemon stop`
                - `${CORRIDOR_HOME}/venv-api/bin/corridor-api daemon start`
            - APP:
                - `${CORRIDOR_HOME}/venv-app/bin/corridor-app daemon stop`
                - `${CORRIDOR_HOME}/venv-app/bin/corridor-app daemon start`
            - Worker-API:
                - `${CORRIDOR_HOME}/venv-api/bin/corridor-worker daemon stop`
                - `${CORRIDOR_HOME}/venv-api/bin/corridor-worker daemon start`
            - Worker-Spark:
                - `${CORRIDOR_HOME}/venv-api/bin/corridor-worker daemon stop`
                - `${CORRIDOR_HOME}/venv-api/bin/corridor-worker daemon start`
            - Jupyter:
                - `${CORRIDOR_HOME}/venv-jupyter/bin/corridor-jupyter daemon stop`
                - `${CORRIDOR_HOME}/venv-jupyter/bin/corridor-jupyter daemon start`

        2. `supervisor`
            - API: `supervisorctl restart corridor-api`
            - APP: `supervisorctl restart corridor-app`
            - Worker-API: `supervisorctl restart corridor-worker-api`
            - Worker-Spark: `supervisorctl restart corridor-worker-spark`
            - Jupyter: `supervisorctl restart corridor-jupyter`

        3. `systemd`
            - API: `systemctl restart corridor-api`
            - APP: `systemctl restart corridor-app`
            - Worker-API: `systemctl restart corridor-worker-api`
            - Worker-Spark: `systemctl restart corridor-worker-spark`
            - Jupyter: `systemctl restart corridor-jupyter`