How is MultiAgent different from Agent?
Xedant Agent works with one project in an isolated container. MultiAgent is the central control panel over a fleet of Agent instances on any number of servers: deployment, updates, monitoring, analytics and backups — all from one window. Agent does the work; MultiAgent runs the army of agents.
Which products can be deployed on the servers?
Eleven ready-made templates — from MultiAgent itself (port 6000) to the Portal Agent (6100): Research (6010), Analytics (6020), Data (6030), Proxy (6040), Chatbot (6050), Telegram (6060), Test (6070), CRM (6080), News (6090) and Portal (6100). Each takes its own port, and in the “New Agent” dialog the template card is labeled with its short name — “Analytics”, “Data”, “Proxy”. The full list with descriptions and variables is on the Products page.
What is Management?
Management is the section for those who have many agents and one or two people watching them. It is built around exceptions: while everything is fine, the console is almost empty. The moment an agent needs your decision or something goes wrong, it floats to the top with a short explanation. Ten screens — the root Fleet plus Fleets, Registry, Chats, Decisions, Cost, Tokens, Posture, Policies and Analytics — answer three questions: is everything all right, what is waiting for a human, and where does the money go. Decisions gather in one queue with a response deadline, and a spare entry can be dismissed with one action: it leaves the queue without deciding anything. Details are on the Management page.
What are Tasks?
It is the queue of long jobs across all servers: deploying and recreating agents, updates, installs, moves and other operations that do not finish instantly. A live log shows what is happening right now, and any job can be stopped with one button. Records are kept for a week, with the last two thousand jobs in the list; jobs of one server run strictly one at a time, while fleet-wide jobs run on their own lane. The queue opens with the “Tasks (N)” button in the sidebar footer, which also shows how many jobs are running and waiting. Details are on the Tasks page.
What does a managed server need?
Managed servers are Linux (Ubuntu/Debian) with SSH access and root/sudo rights. MultiAgent installs Docker and all the dependencies itself — with one button, right from the interface; nothing needs to be installed by hand. And when MultiAgent runs on Windows, agents can live on the very computer: add a server with the Local WSL connection type — no password or key needed.
Where is the data stored?
MultiAgent itself keeps everything in the /data volume: the SQLite database (or PostgreSQL when MULTIAGENT_DATABASE is set), the encryption keys and the license. Data on the managed servers lives in configurable folders — docker, the home page, data, projects and tools. The roots of these folders are built from the server’s deployment slug: by default it is /root/agents/…, and when several deployments live on one machine, each gets its own slug.
How is security handled?
SSH keys, agent passwords and API keys are encrypted in the database — the encryption keys live in /data/keys and never leave the server. Machine access (Agent API) is guarded by an X-API-Key key and works only when it is explicitly set with the MULTIAGENT_HASH environment variable; human login and machine access are kept separate. User login sessions are JWT tokens valid for 90 days.
Can it manage agents that already run?
Yes. MultiAgent can import agents: it scans the server, finds the existing agent containers and registers them without recreating anything. All chats, projects and data stay in place.
Are agent ports open to the internet?
No. New agents, apps and tools come up with a private port: it does not answer from the outside and is reachable only through that server’s nginx — via its subfolder — and from the machine itself. That is how deployments on one computer stay invisible to each other. A port can be opened to the world with the Public port switch — the Ports tab of an agent or an app, or the port row of a tool. Two ports are always public and have no switch: nginx’s own HTTP/HTTPS — the front door to all the server’s apps — and the backup service port, through which other machines pull backups. The shared Postgres, on the contrary, is always closed.
Does every agent need its own domain?
No. On each server MultiAgent installs its own Nginx container (agents-nginx), which serves all the apps from subfolders of one domain: every agent, product and tool gets an address like https://your-domain/name/. The domain and SSL certificate are configured once — nothing extra is needed for the subfolders — and at the root / nginx serves the server home page with app cards. Details are on the Nginx Routing page.
How does Nginx routing work, and do I need my own certificate?
Three kinds of certificates are issued on the Nginx tab of the server page: self-signed (the default), your own PEM pair, or Let’s Encrypt via ACME — the last one needs your own domain. Without a domain, the self-signed one is enough: the browser asks you to confirm it once, and the connection is encrypted from there on. With a domain, Let’s Encrypt is more convenient: it is issued by the webroot method through nginx itself, and renews automatically when the route configuration is updated. If the HTTPS port is not set yet, a successful Let’s Encrypt request turns it on (443) by itself — the certificate starts serving right away. When secure mode is enabled locally, all HTTP — including the route subfolders — is redirected to HTTPS (the only exception is the ACME check path); behind an upper reverse proxy that terminates TLS, the subfolders keep being served over HTTP too, since the browser already talks HTTPS to the proxy.
What is central login (single sign-on to a server’s apps)?
Central login is single sign-on for the apps of one server (Authelia). It is installed on the Authelia tab of the server page, and it has its own address — {serverHost}/auth/. While it is active, agents and products are closed behind the central login by default, and tools with a web interface and custom routes — by your choice: a visitor signs in once and then opens any protected app of the server without logging in again. The login needs HTTPS — a certificate and port on the Nginx tab, or the server’s public address (an address template like https://{serverHost}/{slug} works too) when an upper reverse proxy terminates TLS. Reaching an app directly by host:port, bypassing nginx, keeps the app’s own login. Details are on the Servers and Nginx Routing pages.
Can I log into Forgejo without a separate password?
Yes. Forgejo connects to the central login by itself, as soon as the login is installed, protection is working and Forgejo is running — there is no switch to flip. The Forgejo login page gets a button for signing in through the central login, and the first such sign-in creates the account from the central-login identity; the administrator’s login and password are synchronized with the “Sync authorization” button. When the conditions go away, the button disappears by itself, and Forgejo’s own accounts keep working. Note: applying central-login settings ends the sessions of agents and apps — you will need to sign in again afterwards.
How do I sign out of all apps at once?
The server home page has a Logout corner button. It leads to a confirmation page, after which you are signed out of the central login, of all agents and products (their tokens are deleted) and of the home page itself.
What does the check button on the server page show?
The Check and fix button on the server page opens a service health checklist: the SSH connection, Docker, the folders on the server, the agent user, Nginx, the SSL certificate, the home page, central login, the database (Postgres), the Git service (Forgejo) and the backup service. Rows with a problem that can be fixed automatically carry a “Click here to install it” link (or “create it” / “start it” / request a certificate): it is the same one-step install as on the tab, and after a successful fix the checks re-run themselves.
What is server handover?
Server handover is a one-time operation that gives control of the server to its own MultiAgent: a separate MultiAgent is deployed on the server, and the records move to it — agents, apps, tools, routes and access keys. The running apps are not touched, and you keep the server itself: SSH access, checks, folders and Docker cleanup. After the handover, you can peek into the client’s instance with the “Manage” button — the login happens by itself, with no password. Details are on the Server Handover page.
Can MultiAgent live in a subfolder?
Yes. The same image works both at the domain root and in any subfolder — for example, your-domain/multiagent. Nothing needs rebuilding: MultiAgent detects the subfolder from the request address. It is enough to either set the MULTIAGENT_BASE_PATH variable, or to have the upper proxy pass the X-Forwarded-Prefix header. On a managed server, MultiAgent configures this itself during deployment. Details are on the Nginx Routing page.
What is the own agent (Own Agent)?
The own agent is an external Xedant Agent that MultiAgent connects with the AGENT_API_URL and AGENT_API_KEY environment variables. Its interface is built into every page: a sidebar block with a chat summary, a global chat panel, a prompt queue from the input field, voice input, and the “Tasks (N)” and “Chats” buttons in the panel footer. The reverse direction — the agent controlling MultiAgent — works through the machine interface: the agent gets the MultiAgent address in the MULTIAGENT_URL variable and the key itself in MULTIAGENT_KEY, while MultiAgent keeps only its fingerprint in MULTIAGENT_HASH. Details are on the Own Agent page.
What is the Agent API?
Agent API is the machine interface /api/agent/* for automated clients, guarded by an X-API-Key key (the MULTIAGENT_HASH variable stores its SHA-256 fingerprint). Through it, an external agent manages servers, agents, tools and products; the GET /api/agent request returns a catalog of all the operations with descriptions. Without the variable, the interface answers 503 Agent API is disabled (“the API is off”). Details are on the Agent API page.
What is the server home page?
The server home page is the single bookmark from which all of a server’s apps open. It is a static board of cards: MultiAgent builds it from its own database and uploads it to the server, and nginx serves it at the root /. It needs no separate container and no own login, and the cards (agents, apps, tools) appear automatically, while the corner of the board holds the “Git”, “QR login” and “Logout” buttons. Details are on the Server Home Page page.
How are tasks and bots different from the old triggers and managers?
The old managers and triggers (cron, webhooks, email, Telegram) have been removed from the product. Instead, the agents’ chats now hold scheduled tasks, bots and the prompt queue — plus MCP servers and skills. These are the agent’s own entities: MultiAgent passes them through instead of reinventing them — the dialogs open from the agent page and work through its own API. Details are on the Tasks and Bots page.
How do I install MultiAgent on Windows?
With the XedantMultiAgent-Setup-<version>.exe setup wizard. MultiAgent installs as a Windows service (administrator rights are required): it starts with the computer and keeps managing the servers even when nobody is logged in. The web interface opens at http://localhost:3990, and the data lives in C:\ProgramData\Xedant\MultiAgent\data and survives reinstallation. The managed servers stay Linux machines over SSH, and if you need agents on the computer itself, add a server with the “Local WSL” type. Details are on the Windows Installation page.
Can I keep agents on my own computer?
Yes, when MultiAgent runs on Windows: in the add-server form choose the Local WSL connection type and a distribution. No password, key or address is needed — the Windows service itself runs the commands inside the distribution, and app links open on localhost. WSL2 with Docker inside the distribution is required. On Linux and in Docker deployments this connection type does not exist — there, servers are added over SSH.
What are Environments?
It is a library of named environment variable sets. A set is a name and a list of KEY=VALUE lines you assemble once and then upload to the servers and agents you choose. Variables can be imported from an already-configured server or agent, and uploading to an agent recreates its container right away so the values take effect. It is useful when a dozen agents need the same key or address: fill it in once — and send it everywhere. Details are on the Environments page.
What are Fleets?
They are named groups of agents gathered by meaning rather than by server: for example, “Support bots” with agents from three different machines. Inside a card the members are laid out by server, server groups are collapsed by default, and a server label or a member name leads to its page. A fleet is handy to pick in reports: the filter in analytics and in Management is assembled from fleets, servers and individual agents. Details are on the Management page.
How do I move an agent to another server, or erase it?
A move relocates an agent to another server in full: its rows, folders and database appear at the new place right away — with the move’s progress shown — while the source server is left unchanged (you remove the old copy separately). You can move one, a chosen group or all at once, and you can hit “Cancel” at any moment. “Erase agent” is irreversible: the container, all data folders, the database and the record itself are deleted, so it asks for a separate confirmation. A plain “Delete” works differently: the container is stopped and removed, while the data folders are kept. Details are on the Agents page.
Does MultiAgent work without the internet?
MultiAgent is fully self-hosted: the server, the database, the Forgejo Git server and the files are all inside your infrastructure. Outbound, it only needs access to the model APIs and — when updating — to the Docker registry.
Why is it not open-source?
We already tried running and supporting free products — more than 20 years ago. It is not worth it: the support load is much higher, while there are no resources left for further development. We prefer to have far fewer users who genuinely love the products and are ready to pay for them. One more important reason is control: we like keeping the products simple and minimalist. With open source, we would expect tons of AI-generated PRs with features we deliberately avoided for their complexity and poor design decisions.