ARBoard runs entirely on your servers, on your network: application, database and AI models. No data leaves the company network.
ARBoard is installed on one central server, in your rack, next to your other systems. Not a cloud service to reach, but a machine your IT team knows, runs and protects.
Every authorized workstation, in the browser.
In the company rack: ARBoard in Docker, with persistent data.
Wibu-Systems CodeMeter, on the server or on the CodeMeter host. Checked locally.
LLM engine and models, on your network.
An authorized PC comes in through one controlled gate, in an encrypted tunnel.
Database and documents, in your backup plan.
In the isolated profile, traffic to the Internet stops at the boundary.
Not needed for daily operation.
On site, the company PC connects over the LAN. Off site, an authorized PC comes in through the company VPN: an encrypted tunnel that brings it inside the perimeter, all the way to the server.
The server stays on the private network: your IT team manages the VPN and the rules for remote devices.
The VPN extends the logical perimeter; it does not create an isolated network. In an air-gapped environment, ARBoard is used on the LAN only.
The license lives in a Wibu-Systems CodeMeter USB key, plugged into the server or into the host that runs CodeMeter. It is checked locally, with no Internet and no cloud service.
In a virtual machine, the USB key has to be visible to the CodeMeter runtime.
The count is the same for people working on site, on the LAN, and for people coming in from outside through the VPN. The server keeps count of the seats in use.
Remote too: the VPN client takes one seat.
The installation is a package: Docker images and configuration for your environment. It arrives complete, with models and dependencies, so nothing needs to be downloaded at startup.
Docker images and configuration, in one package.
Images, models and dependencies, ready before startup. They come in through the gate your IT team controls.
Database and documents on local, persistent volumes, included in your backup plan.
Approved packages, transferred according to company procedures.
To bring a board into ARBoard, you start from the files you already have. The workstations are the standard PCs on your company network.
What that file becomes: components, nets, 3D and stack-up in the platformAt the heart of the AI is an LLM engine with its model, hosted locally. ARBoard calls it over the internal network, just as it calls its own database: ARBerto, ARBoard’s AI colleague, answers from here. The technicians’ questions never leave the building.
Alongside ARBoard, in your rack.
Depending on workload and available resources.
The choice depends on the workload and the resources available.
The engine changes; the connection does not.
ARBoard connects to models through the OpenAI-compatible API, an interface adopted by almost every major engine. You can use an open-source LLM you already run, or provide a new one.
“OpenAI-compatible” names the API format. The model and the data stay in the company.
The engine must support the model and the API features ARBoard uses, such as tool calls and structured output.
Document search, transcription and speech synthesis, when enabled, stay local as well.
What ARBerto, the AI colleague, does on the board: the platform
What stays inside? Everything. Processing and storage happen in your infrastructure.
Boards, documents and 3D models.
Sessions, history and reports.
Requests, answers and audio, if used.
In the isolated profile every service is local and outbound Internet traffic is blocked: if anything tries to leave, the boundary stops it.
This applies to the on-premise configuration described on this page: integrations that need external resources are not part of the isolated profile.
Where sessions, history and reports come from: repair and rework at the bench
| Connection | Protocol | Exchange |
|---|---|---|
| Browser → server | REST API over HTTPS | Requests and replies, JSON data and file uploads. |
| Browser ↔ server | Socket.IO over secure WebSocket (WSS) | Real-time events and updates, on a persistent channel. |
| Server → LLM engine | OpenAI-compatible API | POST /v1/chat/completions, with answers that can stream (SSE). |
HTTPS and WSS require a trusted TLS certificate. If your IT team places a reverse proxy in front, it must allow WebSocket and streaming responses.
Commissioning is done together with your IT team, in four steps: from the environment to the acceptance test, which ends with the Internet unplugged.
Server, network, storage, certificates and backup.
Docker and the Wibu-Systems CodeMeter USB key.
Internal endpoints, models and local services.
Clients, ports and firewall, licenses and data flows.
The last check is the easiest to grasp: we unplug the Internet. The workstations keep working, the server answers, the AI answers, and no traffic goes out to external services. Your IT team can verify it directly in the network traffic.
VPN access: tested separately, if your policies provide for it.
The application server and the AI resources are sized separately, with a test on your real load.
CPU, RAM and GPU sizes are set when the installation is sized.
In practice, what is needed? Here is what ARBoard brings and what your IT team prepares.
From ARBoardThese are prerequisites to prepare, not certified minimum requirements: the exact specifications are defined during sizing, together with your IT team.
The next step is a meeting with your IT team: together we define the sizing and the installation path.
Let’s plan the installationNo. In the local configuration everything runs without any external connection: workstations, server, data and AI sit inside the company network. The final acceptance check is done with the Internet unplugged.
Yes, through the company VPN: an encrypted tunnel brings the authorized PC inside the perimeter, while the server stays on the private network. Your IT team manages the VPN and the rules for remote devices. The VPN extends the logical perimeter; it does not create an isolated network. In an air-gapped environment, ARBoard is used on the LAN only, and VPN access is tested separately.
The browser calls the server through a REST API over HTTPS and keeps a Socket.IO channel open over secure WebSocket (WSS) for real-time events. The server talks to the LLM engine in the OpenAI format (POST /v1/chat/completions), with answers that can stream over SSE. HTTPS and WSS require a trusted TLS certificate.
No telemetry. With the Internet unplugged, no traffic goes out to external services, and your IT team can verify it directly in the network traffic.
On one central server in your rack, run by your IT team. ARBoard runs in Docker (Linux containers), with its persistent data alongside, on volumes included in your backup plan. One installation is shared by every authorized workstation.
A standard PC on the company network with a supported browser and access to ARBoard’s internal address.
As a package: Docker images and configuration for your environment, complete with models and dependencies, delivered offline through the gate your IT team controls. Updates are approved packages, transferred according to company procedures.
It depends on use: workstations and peaks, the AI model (concurrent requests, GPU memory, response times), the data to keep, VPN, backup and recovery times. The application server and the AI resources are sized separately, with a test on your real load; CPU, RAM and GPU sizes are set when the installation is sized.
The license lives in a Wibu-Systems CodeMeter USB key, plugged into the server or into the host that runs CodeMeter. It is checked locally, with no Internet and no cloud service; the key enables the seats and modules the license provides.
Yes: in a virtual machine, the USB key has to be visible to the CodeMeter runtime.
1 connected client = 1 license seat. The count is the same for people working on site, on the LAN, and for people coming in from outside through the VPN.
An LLM served by an engine compatible with the OpenAI API, for example vLLM, SGLang, Ollama, llama.cpp, LM Studio or Hugging Face TGI: one you already run or a new one. The engine must support the model and the API features ARBoard uses, such as tool calls and structured output. Your IT team only provides the internal endpoint, the model name and any credentials.
No. “OpenAI-compatible” names the API format: the model and the data stay in the company, and the endpoint is inside your network.
No. The LLM engine can sit on the same server as ARBoard or on a dedicated AI node, depending on the workload and the resources available.
Let’s arrange a technical demo: we’ll show you ARBoard at work, answer your IT team’s questions and define the sizing and the installation path together.
Giorgio Insinga — CEOgiorgio@arboard.eu
