Local AI in practice – Redmine ticket analysis with Ollama

It started as it often does: a customer writes an email with five topics, three questions and two new ideas. The whole thing ends up in the ticket system as a confusing collective ticket.

What if a local LLM dissects these messages automatically - directly in its own infrastructure perimeter, without the cloud, without data outflow?

That’s exactly what I implemented. And this article shows how local AI can be practically integrated into real workflows.

From experiment to productive task

The previous article “Local LLM – AI language models without the cloud” was primarily about a technical experiment: What can a language model do locally? What does offline inference feel like? How much control do you regain?

This follow-up article describes the specific use of a local LLM in my everyday life:

• I run Redmine as a ticket system for customer communication.
• Collective tickets that contain several topics are often created, especially via the email interface.
• The aim was therefore an automated breakdown of these messages into structured individual tickets.
• And that without any form of data transmission to external services.

An ideal use case for a locally operated LLM, integrated into an existing workflow.

Operating environment and objectives

Before we start implementing, take a look at the environment.

The prototype from the exploration phase should go into a container. Not as a security measure (container insulation is not hardening), but for practical reasons:

• File system isolation – cleanly separated runtime without side effects
• Resource Control – because the model shares the home or branch server with other services
• No real-time requirements – ticket processing can easily run asynchronously and with a time delay

Here, containerization is an operational and organizational tool, not a security feature. It ensures that the AI ​​environment can be operated in a reproducible, maintainable and clearly defined manner, without encroaching on the infrastructure of other components.

A proof of concept in Go should then be created that uses both the Redmine API and the Ollama API to map the entire task end-to-end: Read tickets, pass description to the AI model, extract subtasks, create subtickets and automatically advance the main ticket.

The goal is a minimalist but robust solution that shows that local AI can be integrated into existing workflows productively, comprehensibly and confidently with reasonable effort.

Ollama container build

First clone the Ollama repository:

git clone https://github.com/ollama/ollama.git
cd ollama

A Dockerfile is already included - build attempt:

ollama/ollama [ podman build -t ollama -f Dockerfile                                                    main ] 04:49
WARN[0000] missing "CGO_CFLAGS" build argument. Try adding "--build-arg CGO_CFLAGS=<VALUE>" to the command line
WARN[0000] missing "CGO_CXXFLAGS" build argument. Try adding "--build-arg CGO_CXXFLAGS=<VALUE>" to the command line
[1/21] STEP 1/7: FROM --platform=linux/amd64 rocm/dev-almalinux-8:6.3.3-complete AS base-amd64
Error: creating build container: short-name "rocm/dev-almalinux-8:6.3.3-complete" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.conf"

The registry error is easy to fix:

sudo nano /etc/containers/registries.conf
unqualified-search-registries = ["docker.io"]

CGO flag warnings can be suppressed using explicit null values:

podman build -t ollama   -f Dockerfile   --build-arg TARGETARCH=amd64   --build-arg FLAVOR=amd64   --build-arg CGO_CFLAGS=""   --build-arg CGO_CXXFLAGS=""   .

After a longer term:

Successfully tagged localhost/ollama:latest
e53dcbfcbecefedcffb00862e8202623de88b4d0f3e98823b0ab8914fec53a7b

Optional push into your own registry:

podman tag e53dcbfcbece registry.ext.d2ux.net/ollama:latest
podman login registry.ext.d2ux.net
podman push registry.ext.d2ux.net/ollama:latest

Testing

Before an AI model is put into the real workflow, it should first be thoroughly tested. It’s less about content and more about understanding the interfaces, testing functionality and gaining initial experience. This allows you to assess early on how stable the API is, how different models behave and what performance your own hardware delivers. Only then is it worth looking at details such as quality, speed or specific application scenarios.

API container test launch:

podman run -p 11434:11434 -it registry.ext.d2ux.net/ollama

Download a model:

curl http://localhost:11434/api/pull -d '{
  "name": "phi3"
}'

First ticket splitting test:

curl http://localhost:11434/api/generate -d '{
  "model": "phi3",
  "stream": false,
  "prompt": "Erfasse die Einzelaufgaben dieser Email und gib sie als Stichpunkte aus: ..."
}'

Test different models

Models have different numbers of parameters, which – in addition to the actual weights – has a noticeable effect on the processing time and the quality of the results. Larger models typically provide better decompositions and understand context more deeply, but require significantly more CPU resources. Smaller models respond faster, but are less precise or miss implicit tasks. Based on my tests, the following relative and partly subjective assessment results:

Idea & Specification: The Taskbot

Example call

To run the taskbot, all you have to do is set the access data for Redmine and configure the desired processing. The bot then reads all matching tickets, extracts the tasks using the local AI model and automatically creates the corresponding sub-tickets.

export REDMINE_URL="https://redmine.example.com"
export REDMINE_TOKEN="1234567890abcdef"

./taskbot \
  -project=inbox \
  -from-status-id=1 \
  -to-status-id=2 \
  -ollama-url="http://192.168.2.250:11434" \
  -ollama-model="qwen2.5:3b-instruct-q4_K_M"

The call filters all new tickets (status ID 1) from the project inbox, passes their description to the AI ​​model and creates a separate subticket for each recognized task. Once the decomposition is complete, the main ticket is automatically transferred to the status in progress (Status ID 2).

Performance evaluation

For this use case, a classic multi-role standard server is used - specifically an HP MicroServer in the version that is common in many small locations, branches and edge environments. Such systems often run as all-in-one servers for file storage, container runtime and light automation tasks - and are therefore well suited as a reference platform for purely local AI processing.

Hardware base:

• Intel Xeon E-2314
• 16GB RAM
• SSD storage

Risk analysis

The models I tested in Ollama are exclusively GGUF models. This eliminates a significant portion of the usual risks that arise with cloud or remote AI - in particular the possible leakage of sensitive data. Processing is completely local and the models themselves have no functions to transmit information externally.

What remains are two manageable risk areas: On the one hand, the content behavior of the model. Language models can misinterpret tasks, miss unclear passages, or occasionally produce hallucinations. However, for the use case of task decomposition, the risk can be easily controlled because the AI ​​only generates structuring suggestions and does not make any safety or process-critical decisions.

On the other hand, there is the risk of a compromised supply chain. Models should therefore only be loaded from trustworthy sources and checked via hash. If you only use official repositories such as Ollama, HuggingFace or ModelScope and avoid models from non-transparent sources, this risk can be largely minimized.

The locally isolated operation - model, processing and taskbot in the same security perimeter - creates an overall very high level of protection that is more than sufficient for the intended purpose.

Conclusion

A real, practical benefit becomes apparent immediately:

• Tickets are structured automatically
• better prioritization and transparency
• cleaner processing chains
• no external data flows
• confident, fully local AI usage

Local AI works — simple, secure, confident.