Skip to content
.dev
cs

The Nux AI stack

Six layers, one system. The tools are only the last one.

Each layer stands on the one before it, and the order could not be skipped. We built processes, data and infrastructure before AI reached the boardroom. That is why the tools work for us.

Context

The foundations came before AI was a topic

  1. 1

    Processes and data

    Wiki, GitLab, documentation. Without data, AI has nothing to work with.

  2. 2

    Infrastructure

    Data centres, virtualisation, GPUs. Models run under our control.

  3. 3

    Local models

    Ollama: models run with us. Sensitive data stays.

  4. 4

    Gateway to AI

    Open WebUI: answers grounded in company knowledge.

  5. 5

    Automation

    n8n and the PR agent: AI in processes, not just in chat.

  6. 6

    Development with AI

    Cline, Roo Code, Claude Code: AI in developers’ hands.

Layers

What each layer does and what it gives us

1 / 6

Infrastructure: Own hardware, own rules

Own data centres · Proxmox · Ceph · GPU

Our own infrastructure in two locations in the Czech Republic. The AI layer runs on the same platform as our clients’ production systems.

AI without your own infrastructure means sending data to a third party. We solved that before it was a topic.

What it gives us

  • Models and data under physical and legal control, no third-party cloud.
  • Predictable cost: capacity is not paid per token.
  • Spare capacity is room for AI workloads without touching production.

2 / 6

Local models: Models running with us

Ollama · llama.cpp ecosystem · open-source models

Open-source language models run on our GPUs. Prompt and answer stay in our network; nothing goes to the model provider.

Public AI has its place, just not with sensitive data. For that we have models that run at home.

What it gives us

  • Sensitive tasks (internal documents, logs, client data) without compromise.
  • A model per task: small and fast, or larger and more accurate.
  • Independence from cloud API pricing and availability.

3 / 6

Gateway to AI: AI that knows our environment

Open WebUI · RAG over the wiki, GitLab and documentation

The internal interface to AI. The key is RAG: the model receives relevant excerpts of our knowledge and answers from the company’s reality, not the general internet.

The difference between “asking AI” and “asking AI that knows our environment” is the difference between an opinion and an answer.

What it gives us

  • Answers grounded in our documents, not hallucinations.
  • One place, one set of rules: who, for what, over which sources.
  • Expert roles with their own instructions: Architect, Security, Proxmox, MikroTik.
  • Company knowledge available to everyone. A junior asks like a senior.

4 / 6

Automation: AI wired into processes

n8n · workflows · AI as a process step

Connects systems (GitLab, monitoring, e-mail, APIs). AI in the process classifies, summarises and extracts, and the output goes straight into the system.

The biggest value of AI is not created in a chat window, but where the process does not need to mention it.

What it gives us

  • Routine runs by itself: notifications, reports, request triage.
  • Repeatability and an audit trail, because the workflow is defined.
  • People handle exceptions, not routine.

5 / 6

PR agent: AI code review on every change

Automated review of merge requests in GitLab

Every merge request gets an automated AI review before a human reviewer sees it: risks, inconsistencies, deviations from standards. In the MR discussion it answers questions about the change.

This is AI you will never see in a chat. Yet it checks every change on its way to production.

What it gives us

  • A consistent first check on every change.
  • Senior capacity for architecture, not typos.
  • Two-stage review (AI and human) as the standard.

6 / 6

IDE and agents: AI in developers’ hands

Cline · Roo Code · Claude Code · VS Code

AI assistance right in the development environment, from completion to agents that carry out a multi-step change. Always under the developer’s control.

Claude Code is a great tool. But it is the sixth layer of six. Without the ones below, it would just be an expensive chat.

What it gives us

  • Faster implementation of well-specified tasks.
  • AI handles the mechanics, the expert holds architecture and intent.
  • Tool and model per task, which also keeps token costs under control.

Cross-cutting layers

Two layers that hold the rules across all of them

The tools on top do not talk to models or systems directly. Between them stands a gateway that decides where a request may go, and a protocol that lets AI reach only what it is permitted to.

LiteLLM

One gateway to all models

A proxy between our tools and the models. Open WebUI, the IDE, n8n and the agents all talk to one OpenAI-compatible endpoint, and the layer below decides where each request goes.

Open WebUIIDE and agentsn8n
LiteLLM · routing, limits, audit
own cluster (Ollama)cloud models
  • The choice of model is configuration, not an individual’s call.
  • Sensitive data to our own cluster; the rest may go to the cloud.
  • Limits and an audit log in one place: who, which model, when.
  • Agent pipelines: security tests and code review as controlled sequences of steps.

Choosing a model is an operational decision, not a developer’s taste. So a layer makes it, not a person.

MCP

AI looks into our systems

A standard protocol through which AI reaches our systems. Not last week’s export, but the current state, through service accounts with a defined scope.

Open WebUIIDEpipeline agent
MCP · permissions, scope, audit log
GitLabDocumentationNetBoxInternal APIs
  • Answers from the real state of a project, not a copy of the data.
  • Even a non-technical person can ask about the status of a task in GitLab.
  • Every query is traceable: permissions and an audit trail.

MCP is the bridge between AI and our systems. Without it AI guesses; with it, it answers from the project’s reality.

Economics

Routine on cheap local models, flagships only for exceptions

Not every task needs a flagship model, and tokens cost money. Classification, extraction, summarisation and triage are handled by a small local model at a fraction of the cost of a cloud API.

  • Our own GPU stack: capacity for local inference.
  • LiteLLM chooses the model centrally; it is a rule, not an individual’s judgement.
  • We measure GPU load in Grafana (utilisation, temperature, memory allocation), so we know when to scale.
  • Cheap tokens mean automation pays off even at high volumes.

The economics of AI are not decided in the chat, but in the choice of model.

What it runs on

GPU
NVIDIA Tesla P6 (Pascal architecture)
Inference
Ollama, llama.cpp ecosystem
Models in production
Gemma 3 12B, Qwen 2.5 14B
Virtualisation
Proxmox VE, Ceph storage
Locations
two data centres in the Czech Republic
Monitoring
Grafana: GPU metrics

Pascal is an older GPU generation. Newer inference servers (vLLM, TensorRT-LLM) do not run on it, so we build on the llama.cpp ecosystem and models up to the size the card can hold. That is enough for routine tasks; for demanding ones we have cloud models behind the same gateway.

Design and code

Penpot instead of Figma, run in-house

Penpot is an open-source tool for design and prototyping. We run it on our own infrastructure, so designs stay with us and there are no per-seat licences. We generate prototypes from code and code from designs; AI connects designs and components in both directions.

Design is not separate from development. Design and code hand work over in both directions.

FAQ

What developers and management ask

Why local models when cloud models are smarter?

Because most work inside processes is routine: file an e-mail, summarise an issue, extract data from a document. A 12-billion-parameter model on our own GPU is enough for that, the data does not leave, and tokens cost nothing. We use a cloud model where it is really needed and where the data allows it.

Who decides whether a request goes to a local or a cloud model?

Configuration, not the person at the keyboard. Tools call one gateway (LiteLLM) and the model is set by the task’s rule. Agents that work with client data also check with the gateway before their first request that the model runs on our hardware, and send nothing otherwise.

Do you use ChatGPT or Claude?

Yes, where they make sense and the data allows: developers in the IDE, harder summaries, draft replies. Always through the same gateway with an audit trail, and never with data the rules keep inside.

Is an older GPU enough for production AI?

For routine tasks, yes. We measure it: in e-mail triage the local model files a message in 5 to 10 seconds, which holds nobody up at dozens of messages a day. Where performance is not enough, a rule decides, not improvisation.

No-obligation consultation

Let’s find the first job for AI in your company.

An hour’s conversation about where your data lives, which processes slow you down and what of it may leave your network. You leave with a proposal for a first pilot, not a tool demo.

Write to meet@nux.czCall+420 250 250 500
Radek Růžička, Managing Director and CTO, Nux s.r.o.

Built and is accountable for the AI layer at Nux

Radek Růžička

Managing Director and CTO, Nux s.r.o.

radek.ruzicka@nux.cz
meet@nux.cz
Happy to sign an NDA