Tools

Tools are quick deployments of Docker services onto your managed servers, from templates. A service (Postgres, Redis, nginx — anything) is described once as a template, then deployed as many times as you like — each instance with its own settings. The library ships with ready built-in tools — Dozzle, Watchtower, pgAdmin and Playwright — with the projects’ real logos.

Two levels

• Template library (the “Tools” section) — global, stored on the MultiAgent’s own disk in the AGENT_TOOLS folder and shared by all servers. Templates are edited right in the interface: the manifest, the files and compose.yml — as raw text;
• Instances on a server (server page → “Tools on this server”) — the deployed copies: each instance’s lifecycle, statuses, logs, files and variables.

Template structure

Each template is a folder named by its slug — lowercase letters, digits and hyphens:

{AGENT_TOOLS}/
  redis/                     ← template slug = folder name
    tool.json                ← name, description, icon, category, variables
    compose.yml              ← Scriban template
    redis.conf               ← any extra files
    init/
      01-init.sh             ← nested subfolders are supported

Variables are described in tool.json with a type schema:

• string — a text field;
• secret — a password field: the value is encrypted in the database and masked in the interface;
• int — a number field;
• choice — a dropdown of preset options;
• bool — a yes/no toggle.

A variable can declare an SSO variant — the “sign in through the server’s central login” option. When central login is active on the target server, the deploy dialog pre-fills exactly that variant (without it — the normal default), and the instance is born already protected behind the central login. Fields can also be hidden by a condition (when): such a variable is neither shown nor validated, at deploy time or when editing.

Example — the built-in Dozzle template: the sign-in method is chosen by the auth_provider variable (simple — Dozzle’s own password, forward-proxy — sign-in through central login), and the login and password are asked for only in own-password mode — deploying through central login needs no credentials. pgAdmin works the same way with its auth_sources choice: internal — the usual email-and-password form, webserver — sign-in through central login. Switching the method back to a password (for Dozzle, to simple) asks for the password again in the same dialog.

Every container MultiAgent puts on a server — agents, applications, tools and its own services — is labeled with the server’s name. If you watch several servers in one Dozzle, the containers group themselves by server automatically.

When the library is empty, MultiAgent fills it with examples on first run: redis, pgAdmin, dozzle and watchtower. Each template carries its logo (logo.svg/logo.png — the project’s real emblem), which the catalog shows instead of a glyph icon. The examples can be edited — the library is only overwritten when it is empty.

Deployment

1. Pick a template and a server — a form with the template’s variables opens;
2. Fill in the values (secrets are encrypted right away) and preview the assembled compose files against the variables you entered;
3. MultiAgent renders all the template files through Scriban, copies them into the server’s tools folder and runs docker compose up -d. The compose project name is the instance’s short name, so instances stay isolated in networks and volumes.

Templates can use the variable values plus built-in server contexts: {{ instance_slug }}, {{ instance_name }}, {{ data_folder }}, {{ tools_folder }}, {{ temp_folder }} (the temp-files folder), {{ server_host }}, {{ server_name }} (the server’s name) and more. Use {{ instance_slug }} in container_name so two instances of one template can live on the same server.

A tool whose template declares a web port becomes publicly available at the server’s subfolder http(s)://{serverHost}/{slug}/ through Nginx — the same route projection agents use (the route appears with the instance and disappears when it is removed). Without a web port, the tool stays at the direct address http://{host}:{port}. Details — Routes.

A new instance’s ports are closed by default: from the outside it is open only through the server’s subfolder, and the direct host:port address starts working after the “Public ports” switch — in the deployment dialog or on the instance itself, on the server page. The route through Nginx works either way: it points at the container inside the server’s shared network. Instances deployed earlier stayed public — this does not touch them.

When central login is enabled on a server, a tool with a web interface can be closed behind the central login — a toggle on the instance (server page → “Tools on this server”). Unlike agents and products, which are closed by default, tools are protected only by your choice: a visitor signs in once at the server’s login page and the tool opens without its own login; the direct host:port address keeps the tool’s own sign-in. An instance deployed through a template’s SSO variant is born already protected — no separate toggle. Without an active central login everything works as before: the tools’ own logins and passwords.

Instance lifecycle

• Start / Stop / Restart / Pull — container control; the files are untouched;
• Recreate — the only operation that rebuilds the files from the template with the saved variables. Manual file edits get overwritten — the interface warns you beforehand;
• Delete — stops and removes the container, its files and named volumes.

After deployment, an instance’s files on the server are free to edit — through the instance’s “Files” tab or over SSH. Instances are ordinary Docker containers, so they reuse the familiar agent UX: lifecycle buttons, status badges, log viewing, and a file browser with operation progress over SignalR.

Library persistence

By default AGENT_TOOLS points at /project/tools — inside the container, not saved across rebuilds. To let templates survive a container rebuild, set AGENT_TOOLS=/data/tools: the /data volume persists between rebuilds. The products catalog works the same way — the AGENT_PRODUCTS folder holds the templates of all eleven apps, from MultiAgent to the Portal Agent, including the Test, News and Portal agents. Details — in the installation guide.

← Back to documentation