# Deploy API Maker > Upgrade API Maker v4 on every server of the cluster from the admin panel, from npm or from an uploaded package, with live progress for each server and an automatic way back. Source: https://docs.apimaker.dev/v4/docs/features/deploy-api-maker.html - Install another version of API Maker on every server of the cluster from the **Deploy API Maker** page of the admin panel. - This page upgrades API Maker itself. To deploy your APIs, use a Git pull. Learn more [Git](https://docs.apimaker.dev/v4/docs/Git/git.html). > Diagram : Deploy API Maker v4 : admin panel → Caddy → API Maker → Redis → every server installs the package of its machine (5 stages, live progress) → systemd starts it, wait for the new version, reload > > How Deploy API Maker upgrades a cluster of API Maker v4 : the admin panel sends the chosen version, or an uploaded package, through Caddy to API Maker, which sends it through Redis to every server. Each server gets the package of its own machine from npm (its SHA-512 checked) or takes the uploaded one, unpacks it next to the running version, checks its program, moves the current link to it and is started on it by systemd; a watchdog goes back to the version which ran before when the new one does not answer. Every stage is reported live over the WebSocket. When every server is done the page waits until they answer on the new version and reloads. A server which fails keeps its version and the page says why. ## Two ways - **Deploy from NPM**: pick a published version and click **Deploy**. Every server downloads the package of its own machine (`@sava-info-systems/api-maker-engine-linux-x64` or `-linux-arm64`) from the npm registry and checks its SHA-512 before anything is installed. A cluster of x64 and arm64 servers is upgraded in one go. - **Upload a package**: select the `.tgz` of a version (the npm package of one machine), or the `.tar.gz` of a release, up to 512 MB, and click **Upload**. The page sends it in pieces of 4 MB, a request each, so a slow connection or a package of more than 100 MB is no problem; a piece whose request fails on the way is sent again. The pieces wait in the Redis of the installation for an hour, every server reads the package from there, and each one checks its SHA-256 before using it. A server of another machine refuses it. ## What happens on each server 1. The package is downloaded (its SHA-512 checked) or received (its SHA-256 checked). 2. It is unpacked next to the running version, into `~/projects/api_maker/releases/`. 3. Its program is checked : built for this machine, and it starts (`api_maker_be --version`). 4. The `current` link moves to it, all at once. The 3 newest versions are kept, the older ones removed. 5. systemd starts API Maker on the new version. A watchdog outside of API Maker waits for it to answer; when it does not answer within two and a half minutes, `current` goes back to the version which ran before and that one is started again. The server which took the request from the page restarts last, once every server has answered, so the page gets the result of each server. - `.env`, `license.txt`, the uploads and the logs are outside of the versions : nothing has to be kept aside. - The page shows a card per server and the live progress of each stage, then waits until every server answers on the new version and reloads. - A server which fails keeps the version it runs, and the page says why : deploy again once the cause is gone. ## Good to know - The page works on servers installed by the installer of API Maker v4 and run by systemd. A server laid out otherwise refuses and is upgraded by running the [installer](https://docs.apimaker.dev/v4/docs/getting-started/install-on-server.html) again with the version. - Versions of the Node.js edition (v1 to v3) are not deployed from here : the installer moves a server to v4. - A deployment waits up to 20 minutes for the servers to finish. - If the WebSocket connection of the page is down, the deployment keeps running and the page reports the result when it ends.