Ollama

Models running on YOUR machine: no key, no data leaving. Just point at the server address.

Connect an Ollama server so that AI nodes work with models running on your machines. No account and no key are needed, and the content of your emails never leaves your infrastructure. The connection is set up once for the whole organisation by an administrator.

Mankomail talks to Ollama through its OpenAI-compatible API, at http://localhost:11434/v1 by default. The address can be changed.

At a glance

• Identifier: ollama
• Family: AI provider
• Set up by: An administrator, for the whole organisation
• Authentication: Provider API key
• Credential type: llm_provider

Before you start

• An Ollama server, running, with at least one model pulled (for example ollama pull <model>).
• The server must be reachable from the Mankomail server, not from your browser: calls are made by the instance. localhost designates the machine — or the container — where Mankomail runs. If Ollama runs elsewhere, make it listen on the network (Ollama binds to 127.0.0.1:11434 by default; its OLLAMA_HOST variable changes this, for example OLLAMA_HOST=0.0.0.0:11434) and use that address.
• An administrator account on Mankomail: only administrators manage AI connections.
• An instance with an encryption key (ENCRYPTION_KEY): the connection is stored like any other secret, even without a key.

Who configures it

AI connections belong to the organisation, not to a member. Only an administrator can create, edit, test or delete them, from the Connections page. Members see the Artificial intelligence section with the note “AI providers are configured once for the whole organisation, by an administrator.” They never see a key: in the workflow editor they only pick a connection by its label and a model.

The key is encrypted before it is stored and is never displayed again: the screen only shows its last four characters (“Key saved (ends with …)”). Storing a key requires the instance encryption key (ENCRYPTION_KEY, see Environment variables); without it, saving fails with llm.encryption_disabled.

Add the connection

1. Open Connections in the main navigation.
2. In the Artificial intelligence section, find the Ollama row and click Configure. (You can also click Add in that section and pick Ollama in the catalogue.)
3. Label: pre-filled with “Ollama”. Change it if you connect several servers.
4. API key: leave it empty (placeholder “No key needed”). Fill it only if your Ollama sits behind a proxy that asks for a token; it is then sent as a bearer token.
5. Server URL: pre-filled with http://localhost:11434/v1 (“Pre-filled with the usual address. Change it if your server listens elsewhere.”). Keep the /v1 suffix: it is the OpenAI-compatible endpoint, and the model list is read from /api/tags next to it.
6. Enabled models: nothing to tick yet; see the next section.
7. Click Save.

The card then shows the Local server badge and “Configured without a key — this server does not ask for one”. Test and Show available models are only available once the connection is saved.

Choose the enabled models

Mankomail has no built-in model catalogue for Ollama: model ids change too often to be written down. You pick them from what your own account or server exposes:

1. Save the connection first (the card says “This provider has no fixed catalogue. Save the configuration, then ask it for its available models.”).
2. Click Show available models. The card shows “n models returned by the provider.” and lists them.
3. Tick the models your workflows may use, then click Save.

The ticked models become the allow-list of this connection:

• a node that names another model fails with llm.model_not_allowed, and the editor warns about it in the provider node;
• when a node names no model, Mankomail uses the first enabled model — the first one ticked (there is no recommended model per purpose for Ollama);
• the Test button needs at least one enabled model to test with (llm.no_default_model otherwise).

Models that stay ticked remain listed even if a later list no longer returns them, so a temporary gap at the provider never unticks them silently.

Test the connection

Test sends a real, minimal request (“ping”, at most 5 output tokens) with the key of the connection shown in the card. It proves the key can complete, not just that it is accepted. The test uses the first enabled model, so tick at least one model first. On success the card shows “Connected to model in n ms.”; otherwise “The test failed:” followed by the reason (see Common errors).

Show available models is a different check: it asks the provider for the list of models this key can see. A successful list proves the key is read, not that it can complete — a metadata endpoint can answer even when inference is refused (for example a model listed but unable to run). The list is kept for ten minutes, per connection; saving or deleting a connection of the provider clears it.

Which provider and model an AI node uses

AI nodes (such as Categorize, Extract, Compose (AI), Summarize and Free instruction (AI)) each call the model with a purpose: classify, extract, compose or general use. Mailbox analysis uses its own purpose. For every call, the provider and model are resolved in this order — the first rule that applies wins:

1. A provider node linked to the node’s model port — for example the Ollama (local) node. Its Connection and Model fields apply; an empty Model means “the recommended model for this purpose at this provider”.
2. The administrator’s choice for that purpose, in the Which AI for which use panel of the Connections page.
3. The instance default — the first row of that panel, “Default (every unset use)”. It can name a provider only (“… · recommended model”) or a provider and a model.
4. The first configured provider, by configuration date (no brand preference), with the recommended model for the purpose.

A choice that has become unusable (key removed, model unticked) is skipped in favour of the next rule, and the panel shows “Choice not applicable” next to it. Under each row, “Uses: provider · model” shows what the next call will really get. When nothing can serve a purpose, the row shows “None” and the nodes fail with llm.no_provider_configured or llm.no_default_model.

In the Which AI for which use panel, the per-use rows only list models of providers that have a built-in catalogue. To send everything to Ollama, choose “Ollama · recommended model” on the first row, “Default (every unset use)”: every unset purpose then uses the first model enabled on the default Ollama connection. To use a specific Ollama model for one node, link a provider node and name the model.

Several keys for the same provider

An organisation can hold several Ollama connections — for example two servers. Each connection has its own Label, key, server URL and list of enabled models.

• To add one, open the provider card and click Add a connection. The label is required and must be unique (“Another connection already uses this label.” otherwise).
• The provider’s first connection automatically becomes its Default connection. Once there are two or more, the card lists them; click Make default on another one to move the default.
• The default connection is what everything uses when no connection is named: per-use defaults, the instance default, mailbox analysis, and any provider node whose Connection field is left on “Default (…)”.
• To pick a specific key for one node, choose it in the Connection field of the Ollama (local) provider node.

To delete a connection, select it, click Delete, then Confirm deletion. Two refusals protect running workflows:

• if published workflows reference the connection, the card says “Published workflows use this connection; confirm to delete it anyway.” and lists them. Confirming again deletes it, and those nodes will then fail with llm.connection_not_found until you pick another connection;
• the default connection cannot be deleted while the provider has other connections (llm.connection_is_default): make another one the default first. Deleting the last connection removes the provider from the instance.

Use Ollama in a workflow

To make one AI node work with Ollama whatever the instance defaults are, link a provider node to it:

1. Add the Ollama (local) node to the canvas (node reference).
2. Draw a link from it to the model port of the AI node.
3. In Connection, keep “Default (…)” to use the provider’s default connection, or pick another connection by its label.
4. In Model, leave the field empty to use the recommended model for the node’s purpose, or enter a model id. The editor suggests the models enabled on the chosen connection and warns when the id is not enabled on it (“This model is not enabled on the selected connection: the run will refuse it.”).
5. Temperature is optional; leave it empty to keep the provider’s setting.

The provider node is not a step: it never runs on its own, carries no key, and only tells the linked AI node which provider, connection and model to use. One provider node can feed several AI nodes.

If the chosen connection has been deleted, the run fails with llm.connection_not_found — it never falls back to another key. If the connection belongs to another provider, the run fails with llm.connection_provider_mismatch.

Ollama model ids often contain a tag after a colon (for example name:tag). Write the id exactly as it appears in the list of enabled models.

Structured output

When a node expects a structured answer, Mankomail uses Ollama’s JSON mode and adds the expected schema to the system instructions. Smaller local models follow schemas less reliably: if the answer does not match, Mankomail makes one repair attempt; after that the step fails with llm.invalid_json. Use a more capable model if this happens often.

In a test run

A test run calls the real model: you see the category, extraction or draft the model actually produces. Only irreversible actions (sending, moving, HTTP requests) are simulated. A test call costs the same as in production and appears in AI usage and costs.

The output is fabricated only when the instance has no usable provider — no AI connection at all, or a provider node linked to a provider that is not configured. The editor then shows “AI skipped: no key on this instance”, and the step’s effect says that no model would have been called because no LLM provider is configured. When a model can be resolved, the effect names the model the run would really use. The fabricated output is the smallest value that fits the expected shape: the first category set to true, text fields set to simulated.

Policy refusals are not hidden in a test run: a model that is not enabled (llm.model_not_allowed), a deleted connection (llm.connection_not_found), an exhausted quota or a provider outage fail the test exactly as they would fail in production.

Privacy and costs

With Ollama, the prompts and the email content sent by AI nodes go only to the server address you entered: nothing is sent to a third-party AI provider. Calls are counted in AI usage and costs (calls and tokens) without a cost, since Mankomail has no price for them.

Common errors

Errors are reported by a stable code; the interface translates it. On the Connections page, the reason for a failed Test or model list appears in the provider card, and other refusals (saving, deleting) in a banner at the top of the section; during a run, the code appears in the step’s error. See also Error handling and replay and the error code reference.

For Ollama, llm.provider_unavailable usually means the server is stopped or unreachable from the Mankomail server, and llm.provider_rejected that the model id is not pulled on the server.

Code	Cause	What to do
llm.rate_limited	The provider answered 429, 502, 503, 504 or 529 (quota, credits or overload), or the instance’s own limit (LLM_MAX_REQUESTS_PER_MINUTE, 60 calls per minute per provider by default) is reached.	Nothing to do for a passing peak: the step is postponed and resumed without using up a retry. If it persists, check your quota or credits at the provider.
llm.timeout	The provider did not answer within LLM_REQUEST_TIMEOUT_MS (120 seconds by default).	Retried automatically. For long drafts on a slow server, raise the timeout.
llm.provider_unavailable	Network error, or another 5xx answer from the provider.	Retried automatically with backoff. Check the provider’s status if it persists.
llm.provider_rejected	The provider refused the request itself (HTTP 400, 404 or 422): unknown model id, input too long, schema refused.	Check the model id in the provider node or the enabled models. The run is not retried.
llm.model_not_allowed	The model named by the node is not enabled on the connection used.	Tick the model in the card, or name an enabled model in the provider node.
llm.no_default_model	No model can be chosen for this purpose: no recommended model at this provider and no enabled model. Also returned by Test when there is no model to test with.	Enable at least one model on the connection, or name the model in the provider node.
llm.no_provider_configured	No AI connection exists on the instance.	An administrator adds a connection on the Connections page.
llm.provider_not_configured	A provider node is linked to a provider that has no connection, or the first save was sent without a key.	Configure the provider, or link a provider node of a configured provider.
llm.connection_not_found	The connection selected in the provider node has been deleted.	Pick another connection in the node’s Connection field, then publish again.
llm.connection_provider_mismatch	The connection selected in the node belongs to another provider than the node.	Pick a connection of the right provider, or replace the provider node.
llm.invalid_json	The model returned unusable JSON for a structured output, even after one automatic repair.	Run again, or use a more capable model for this node.
llm.output_truncated	The structured answer was cut off by the output token ceiling.	Ask for less, or raise LLM_DEFAULT_MAX_OUTPUT_TOKENS (4,096 by default).
llm.empty_output	A reasoning model spent its whole budget reasoning and wrote nothing.	Run again, or use another model for this node.
llm.content_refused	The model refused to answer this content.	Review the prompt or the input. The run is not retried.
llm.connection_in_use	Deletion refused: published workflows use the connection (their names are listed).	Change their connection first, or confirm the deletion a second time.
llm.connection_is_default	Deletion refused: this is the provider’s default connection and others exist.	Click Make default on another connection, then delete this one.
llm.connection_label_taken	Another connection already uses this label.	Choose another label.
llm.encryption_disabled	The instance has no ENCRYPTION_KEY: it cannot store a secret.	Set the variable and restart the instance.
llm.invalid_api_key	The provider refused the key (HTTP 401 or 403): revoked, mistyped, or lacking access.	Create a new key at the provider, paste it in the card and Save, then Test. The run is not retried.
llm.invalid_base_url	The server URL is missing or malformed, or a URL was sent for a provider whose address is fixed.	Enter the full URL, version prefix included.
llm.discovery_failed	The model list could not be read: unexpected answer from the provider.	Check the key, the URL and the provider’s status, then try Show available models again.

Nodes that use this connection

• Ollama (local) — llm.ollama