API Maker
The backend engine for the AI era
DeployEpisode 47 6:07 12 chapters October 2026
A new version of API Maker on every server of the installation, from one page of the panel. See how Deploy API Maker installs it from npm or from a bundle, checks its hashes and the program, goes back on its own with a watchdog when the new version does not start, and where Launchpad and the license of each server fit in.
In the playlists The complete course Run in production
A new version of API Maker, on every server of the installation, from one page of the panel. In this video : how Deploy API Maker installs it, checks it, and goes back on its own when the new version does not start.
Upgrading a backend usually means SSH into each server, one after the other, a build copied by hand, for the right processor, a restart, and the hope that it starts, and when it does not, the way back, by hand too, while the APIs are down. With API Maker, one page upgrades every server at once, each one takes the package of its own machine, its hash checked, the new program is checked before it is used, and a watchdog goes back to the old version on its own.
In this video : the page, two ways to deploy, what each server does, the way back, a whole cluster, what stays in place, servers that refuse, and the license of each server.
Deploy API Maker is under Operations. The header shows the version this server runs, under the name of the page. On the left, upload a bundle : the file of a version. On the right, pick a version published on npm, and deploy it.
From npm, every server downloads the package of its own machine, x64 or arm64, and checks its SHA 512 before anything is installed : a cluster of both kinds is upgraded in one go. An upload goes to one server, which hands it to the others through the Redis of the installation, in pieces of four megabytes, kept for an hour. Each server checks its SHA 256, and a server of another machine refuses it.
On each server, the same steps. The package is downloaded, or received. It is unpacked next to the running version, in releases. Its program is checked : built for this machine, and it starts. The current link moves to it, all at once, and the three newest versions are kept. Then systemd starts the new version.
And if it does not start? A watchdog runs outside of API Maker, as a unit of systemd of its own. It restarts API Maker, then asks its port every two seconds, seventy five times. An answer, and its work is done. No answer within two and a half minutes : current goes back to the version which ran before, and that one is started again.
The page asks one server. That server asks every other one at once, and the page shows a card for each server, with the progress of each step. Each server restarts on its own, once it answered. The server which took the request restarts last, so the page gets the result of every server. Then the page waits until every server answers on the new version, and reloads.
The env file, the license, the uploads and the logs are outside of the versions : nothing has to be put aside. A server which fails keeps the version it runs, and the page says why. A deployment waits up to twenty minutes for its servers. And when the WebSocket of the page is down, the deployment goes on, and the page reports the result when it ends.
A server refuses what it can not do safely. This demo server runs on a Mac : asked for the latest version, it refuses at the first step, before anything is downloaded, written or restarted. A server not installed by the installer, or not run by systemd, refuses too : run the installer again, with the version, as video sixty one shows. And versions of the Node.js edition can not run on version four.
This page upgrades API Maker itself. Your APIs, schemas and websites go to every server with a pull from git, and the settings of every server are on Deployment Settings. Servers without API Maker yet? One command of the installer sets each one up, in video sixty one. Or the Cloud mode of API Maker Launchpad installs it from your laptop, over SSH : the same packages of npm, checked the same way, every change reviewed server by server first.
Then the deployment runs in stages, with the output of every server, from one server to a cluster. Video fifty eight shows it.
Licenses, under Operations, shows the license of every server of the installation, a card for each. This server has no key yet : invalid, no license key is set on this server, and the fix, Set Key. The key is written to the license file of this server only, and every process of it checks the license again at once. Here, the key of API Maker Launchpad : local, for this computer and private networks.
A card says one of four things : pending, until the first check, then valid, invalid, or local. The checks never refuse a request : a license which is not valid shows here, and as a warning in the header. Each server asks the license server a minute or two after it starts, every day around noon, India time, and at once after a new key. When it can not be reached, the last answer stays.
A key is bound to the MAC address of its machine : Reset MAC moves it.
To sum up. One page upgrades every server. Each one takes the package of its machine, its hash checked. The program is checked before it is used. A watchdog goes back on its own. A server refuses what it can not do safely. And Licenses shows the license of every server. Next : SSR websites, first steps. API Maker. Build faster, spend smarter, deliver better.
Length 5:33SSR websites
Length 8:06Install
Length 6:26Scale out
Length 5:31Upgrade from v3