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, Playwright and Redis — 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.

On first run the library fills with examples: 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.

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 with templates for Research, Analytics, Data, Proxy, MultiAgent, plus chat bots, Telegram, UI and CRM. Details — in the installation guide.

← Back to documentation