LM Studio on Unraid: Headless Server Setup

The appeal is obvious. The GPU is already in the server, the server is already on, and every other machine in the house is a laptop or a phone. Running the model there and talking to it from anywhere is exactly the right architecture. The obstacle is that LM Studio is a desktop application, and Unraid is a headless server operating system with no desktop to run it on.

There is no official Unraid application from the vendor, and Community Apps listings for this have appeared and disappeared over time, so a template someone linked you to last year may no longer be published. What does exist is a supported headless mode plus two container-shaped workarounds. They are genuinely different tradeoffs, and picking the wrong one is how people end up with a browser streaming a remote desktop just to click a load button.

First decide what you actually want

Two quite different goals hide behind “run LM Studio on my server”, and the answer depends entirely on which one is yours.

If you want an OpenAI-compatible endpoint on your LAN that other tools call, you want a headless service and you will rarely look at a user interface again. If you want the LM Studio application itself — the model browser, the chat interface, the load-parameter sliders — accessible from a machine that is not the server, you want a remote desktop, and that is a different problem with a different solution.

Answer that first, because the three options below split cleanly along that line.

Option 1: the llmster daemon, the vendor’s own headless path

LM Studio’s documentation describes running as a background service in two ways, and the one it recommends is a standalone daemon that requires no GUI at all. The vendor publishes an install script at lmstudio.ai/install.sh, after which the service is controlled entirely from the command line:

• lms daemon up starts the headless daemon, and lms daemon down stops it
• lms daemon status reports whether it is running, lms daemon update upgrades it
• lms server start, lms server stop, and lms server status control the API server itself
• lms ls lists models on disk, lms ps lists models currently in memory
• lms load loads a model with GPU and context-length options, lms unload --all clears memory

This is the right answer for the endpoint goal. There is no X server, no AppImage extraction, no desktop being rendered to nobody.

The complication on Unraid specifically is that Unraid’s operating system lives in RAM and is rebuilt from the flash drive at boot, so software installed directly onto it does not survive a reboot. That makes a container the natural home for the daemon, running on a Linux base image with the install script applied and /data mapped to a real path on your pool. It is more assembly than clicking Install on a template, and it is stable once built.

Just-in-time loading is what makes this pleasant. LM Studio’s documentation describes JIT loading: with it enabled, /v1/models returns everything you have downloaded rather than only what is resident, and an inference request loads the model into memory automatically. JIT-loaded models are then auto-unloaded after a period of inactivity. On an always-on server that behaviour is close to ideal, because VRAM sits free until something actually asks for a model.

Option 2: a container that streams the full application

The alternative, when you genuinely want the interface, is a container that runs the desktop application and streams it to a browser. LinuxServer.io publishes a maintained image that does exactly this using the Selkies streaming protocol. Its documentation lists HTTPS on port 3001 as the primary interface, HTTP on 3000 which must be proxied, and a WebSocket data channel on 8082, with a single /config volume for the user’s home directory and program settings. It also requires --shm-size=1gb.

Its GPU notes are worth reading before committing. The documentation states CUDA support “requires a 2000 series or higher Nvidia video card running the latest binary drivers”, covers AMD cards through Vulkan, and says plainly that “ROCm is not supported at this time”. If your server’s card is an older GTX or an AMD card you were hoping to use through ROCm, that is the constraint that decides for you.

This option gets you the real application with its model browser and settings panels. The cost is that you are streaming a remote desktop to click buttons, which is heavier than it sounds and noticeably less pleasant than the native app on a laptop.

Option 3: a virtual machine with the GPU passed through

Unraid’s other native capability is virtual machines with PCIe passthrough. Give a VM the graphics card, install a desktop Linux or Windows in it, and run LM Studio normally.

This is the heaviest option and occasionally the correct one, because it is the only path that gives you the unmodified application with full hardware access. It is worth it when the server has more than one GPU and you can dedicate a card, or when you already run a VM for other reasons. It is a poor choice when the GPU is shared with other containers, because passthrough is exclusive: once the VM owns the card, nothing else on the box can use it.

Unraid details that matter regardless of option

Put the models on fast storage, not the array. Model files run from a few gigabytes to well over a hundred, and they are read constantly and written once. Storing them on a parity-protected array means slow writes and parity work for data that never changes. A cache pool or an unassigned NVMe drive is the right home, and the model directory should be mapped there explicitly rather than left on a default share.

GPU passthrough to containers needs the driver installed first. Unraid does not ship NVIDIA’s proprietary driver in the base OS; it is added through a Community Apps plugin, after which containers receive the card through the NVIDIA container runtime and a device UUID. Containers started before the driver is in place will silently fall back to CPU inference, which looks like a performance mystery rather than a configuration error.

Size the memory before you build anything. A headless server does not change the arithmetic: the model plus its context cache still has to fit in VRAM to be fast. Work the numbers out first with the VRAM and GGUF sizer, and see LM Studio’s system requirements for how the sizing works and where the hard floors are.

Do not expose the API to the internet. LM Studio’s server presents OpenAI-compatible endpoints — /v1/models, /v1/chat/completions, /v1/completions, /v1/embeddings, and /v1/responses — on port 1234 by default, and the compatibility layer exists so that existing OpenAI clients work by changing only the base URL. That convenience cuts both ways: it is designed for a trusted local network, not for a public address. Keep it on the LAN, and reach it from outside over a VPN rather than a port forward.

The honest recommendation

If your goal is an endpoint, use the headless daemon. If your goal is the application, use the streaming container and accept what it is. If you have a spare GPU and specific requirements, pass it through to a VM.

And one thing worth saying plainly: if you only ever wanted an OpenAI-compatible API on a server, the desktop application’s real value — the model browser, the guided quantization picker, the load-parameter interface — is precisely the part you are discarding. Purpose-built server runtimes exist for that job and are lighter to operate. The reason to run LM Studio on a server anyway is continuity: the same application, the same model library, and the same load settings you already understand from the desktop. That is a good reason. It is just worth choosing deliberately rather than by momentum.

Before any of this, make sure the model you intend to serve is in a format the runtime can open, since a server build is a frustrating place to discover a format problem: GGUF vs safetensors covers what loads and what does not, and choosing a GGUF quantization level covers which build to put on the box.