Normally MultiAgent is the control center: it holds the server records, deploys agents and products onto the servers, and manages routing. But a server can belong to your client rather than to you — and then it makes sense to hand management over to the client: they get their own MultiAgent on their own server and run their own agents. Handover is a one-time operation that moves control of the records from your central instance to the client’s instance. The running applications themselves are not touched: they keep working, nothing stops and nothing gets reinstalled.
What this gives you in practice: the client becomes the full owner of their agents, applications and routes, while you stay responsible only for the server itself — SSH access, checks, folders, Docker cleanup. During the handover, secrets travel directly between the two instances over a protected machine channel and never show up in the interface, the logs, or programmatic API responses.
How it works
MultiAgent itself is deployed onto the server — as a regular product from the catalog, “New Agent” tab. Nothing separate to configure: the moment it appears, this instance receives its own server record from central and connects to it right away. Records travel directly between the two MultiAgents, so the client types nothing by hand and no extra addresses need to be opened to the outside world.
While the server has its own MultiAgent, the server page on the central instance grows a “Handover” tab, and the page header gets a “Manage” button.
The Handover tab
The tab shows a preview: what exactly will move to the client and what stays with you. Changing your mind at this step costs nothing — the preview changes nothing.
- Moves: agents, product applications, tools, custom routes, certificate data, repository access keys, and optionally the licenses the agents reference;
- Stays with you: the server row itself — SSH access, checks, folders and Docker cleanup — and the MultiAgent application row, so you can keep updating its image.
The “Hand over” button starts the operation: it contacts the client’s instance once more, sends it all the records, and shows the transfer’s progress in a progress panel. The handover counts as successful only when every agent and tool record has landed on the client’s side. After that, the central instance forgets the transferred records — nothing is deleted on the server itself, and the containers keep running as before.
If something goes wrong, nothing changes on your side: no marks, no deletions. The report names what blocked the operation — most often a name that is already taken on the client’s instance. Fix that on their side and run the handover again: a retry is safe. Failures in moving routes, certificates or repository keys do not block the handover — those records can be re-created manually on the client’s side if needed.
What happens after the handover
- The client controls routing. The virtual web server is assembled from the client instance’s own records, so the client decides where the subfolders lead. Changing addresses and deploying new agents and products on the server now goes through their instance;
- Your side no longer rebuilds the configuration. Every operation that used to refresh the routes now simply notes in the log that the server is handed over. This does not stop you from working with files over SSH, or from starting and stopping the applications you are still responsible for;
- The server is handed over once. A second handover of the same server is rejected with a clear message. Two systems editing one configuration at the same time are ruled out.
The Manage button — enter the client’s side without a password
After the handover it is convenient to peek into the client’s instance: check how the agents settled in, sort out a taken name, look at their routes. The “Manage” button in the page header opens the client’s interface in a new tab, already logged in — no password to type, and none is stored anywhere.
For this, the central instance issues a one-time login link: the code is valid for five minutes and works exactly once. Someone else’s or an expired code simply lands on the client’s login page. The access key itself stays on the server and never reaches the browser. If the client’s instance sits behind a central login, you first pass that usual login once — the code is unaffected.
When something does not work
- The reply says “enable the machine API”. The MultiAgent application was deployed before the access key — the one the instances use to talk to each other — existed. Recreate that application on the central instance and run the handover again;
- The reply says “key rejected”. That happens when the client’s instance was deployed from scratch and minted a new key. The fix is the same — recreate the application on the central instance;
- The transfer rejected some name. A record with that name already exists on the client’s instance. Rename or delete it there and run the handover again;
- The routes look stale. The client has not applied their configuration yet — it does not block the handover. Open their “Nginx” tab and press “Apply configuration”.
More on how server routes work on the Nginx Routing page; on the MultiAgent application itself — on the Products page.