Install LM Studio 0.4.20: Local LLM Desktop App Guide

You want a local LLM desktop app that doesn’t require compiling llama.cpp, hunting for the right BLAS flags, or writing a shell script just to talk to a model. LM Studio does that – one installer, a Hugging Face browser inside the app, and an OpenAI-compatible endpoint on port 1234 that any SDK will accept. Below is a deployment walkthrough for the current build, with the traps most tutorials skip.

The install is easy. The headless install is where people burn an afternoon.

What you’re actually installing

LM Studio is two things bundled together: a desktop GUI, and a background inference process. Per the official docs, that background process is called llmster (as of 0.4.x) – the same engine, packaged to run without the GUI on a Linux server. Most guides ignore this split. It matters because your install path depends on which one you want.

The app is free for personal and commercial use since July 8, 2025, no form, no license request. As of August 2026, the current desktop build is 0.4.20 – verify the exact number on the download page before you install, since these ship often.

System requirements (the honest version)

The official system requirements page is short, so here it is expanded into what actually matters:

Two footnotes the docs bury. First, on Apple Silicon unified memory acts as both RAM and VRAM, so a 16 GB M-series Mac runs 7B models that would need a discrete GPU on a PC. Second, that same docs repo states outright that Ubuntu versions newer than 22 are “not well tested” – if you’re on 24.04, expect to file bugs.

Install path 1: Desktop (Windows / macOS)

Grab the installer from lmstudio.ai. Windows gets an .exe, Mac gets a .dmg. Both are per-user installs – write that down, it will come back later.

Winget works too:

winget install --id=LMStudio.LMStudio -e

The trap: running that command as SYSTEM – through an RMM tool or automated deployment script – means the installer exits cleanly and puts nothing usable on the machine. LM Studio installs into the current user’s profile. Run it from the logged-in user’s session, full stop.

Install path 2: Linux AppImage

Linux gets an AppImage. Download it and mark it executable:

wget https://lmstudio.ai/download/latest/linux/x64?format=AppImage -O LM_Studio.AppImage
chmod u+x ./LM_Studio.AppImage
./LM_Studio.AppImage

If it fails on a modern Ubuntu with a chrome-sandbox permissions error, you have two choices. On a desktop machine: fix the SUID bit. On a headless server, wrap it:

xvfb-run --auto-servernum ./LM_Studio.AppImage --no-sandbox

xvfb-run creates a virtual display so the Electron shell has something to render into; --no-sandbox skips the chrome-sandbox permission check. Official docs omit this combination – it appears in Unsloth’s CLI install guide, not the LM Studio docs themselves.

First-run: bootstrap the CLI

Launch the desktop app at least once before touching the CLI. This is the single most common tripwire – the ~/.lmstudio/bin directory doesn’t exist until the app has run. From the official announcement post: you need to run LM Studio once, then bootstrap.

Mac / Linux:

~/.lmstudio/bin/lms bootstrap

Windows (cmd):

cmd /c %USERPROFILE%/.lmstudio/bin/lms.exe bootstrap

Open a new terminal window afterward – the PATH change won’t take effect in your existing shell. If lms still says command not found in the new window, restart the terminal emulator completely.

Verify the install works

Three checks, in order:

1. lms version – should print a version string
2. lms status – reports whether the server is running and what models are loaded
3. Download a small model and load it: lms get qwen2.5-1.5b-instruct then lms load qwen2.5-1.5b-instruct

Now hit the endpoint:

curl http://localhost:1234/v1/models

If you get JSON back listing your loaded model, the OpenAI-compatible server is live. Point any OpenAI SDK at http://localhost:1234/v1 and it works with no code changes.

Start with a Q4_K_M quant of any model you test. As of the SitePoint 0.4 headless guide (2025), Q4_K_M trades roughly 1-3% perplexity loss for ~40% less RAM versus FP16 – this may shift with newer quant tooling. If Q4_K_M runs fine, only then experiment with higher-precision quants. Doing it in reverse – starting at Q8 and downgrading – wastes hours of download bandwidth on models you’ll swap out.

Headless deployment (the real reason you’re here)

For a headless Linux box, the recommended path per the official headless docs is llmster – the server-native core packaged without the GUI. On a machine where you already have the GUI installed, you can also run the desktop app in headless mode via the tray icon or with lms server start.

A minimal headless server start:

lms server start --port 1234 --host 0.0.0.0 --cors

Fair warning about that --host 0.0.0.0: you’re exposing an unauthenticated inference endpoint to your LAN. Put it behind a reverse proxy with auth, or bind to 127.0.0.1 and tunnel over SSH.

Memory planning matters here. Models loaded via JIT stay resident until you call lms unload <model> – auto-unloading isn’t implemented as of 0.3.5, per the official headless docs. On a small server, a forgotten large model will quietly consume RAM until reboot. Build the unload step into whatever script manages your server restarts.

Common errors, real fixes

“lms: command not found” after bootstrap. You’re in the same terminal that ran the bootstrap. Open a new one. If it still fails, the GUI never ran – check that ~/.lmstudio/bin/lms actually exists on disk.

Model won’t load, no error, just spinner. You picked a quant too big for your VRAM and CPU RAM combined. Drop to a smaller quant (Q4_K_M) or a smaller parameter count. The Discover tab shows an estimated RAM footprint next to each variant – trust it.

Winget install “succeeded” but no app. Ran as SYSTEM. Re-run as the target user in an interactive session.

AppImage exits immediately on Ubuntu 24. Try the xvfb-run --auto-servernum ... --no-sandbox wrapper above, or accept that you’re on an unsupported distro version.

Upgrade and uninstall

The GUI checks for updates on launch and installs them in place – no config migration required, your models directory (~/.lmstudio/models) is untouched. If you’re on the AppImage, delete the old file and drop in the new one; the models stay.

To uninstall cleanly:

• Windows: Add/Remove Programs → LM Studio. Then delete %USERPROFILE%.lmstudio to remove models and config.
• macOS: Drag from Applications to Trash, then rm -rf ~/.lmstudio.
• Linux: Delete the AppImage, then rm -rf ~/.lmstudio.

Watch the disk. A serious LM Studio user accumulates 50-200 GB of GGUF files without noticing. That ~/.lmstudio/models directory is where they hide.

FAQ

Is LM Studio open source?

No. The desktop app and llmster daemon are proprietary, though free for commercial use as of July 2025. The underlying inference engines (llama.cpp and Apple’s MLX) are open source. If auditability is a hard requirement, look at Ollama.

Can I run LM Studio in Docker?

Not directly with the desktop app – it’s an Electron GUI, not a headless service. What you can do is run llmster or the AppImage in a container with the xvfb-run --auto-servernum --no-sandbox wrapper, expose port 1234, and mount a volume for ~/.lmstudio/models so model downloads persist across container rebuilds. It’s viable, but it’s not the shipped supported path – you’re gluing pieces together.

Do I have to use the built-in model browser?

No. Use lms import path/to/model.gguf to sideload any GGUF you already have.

Next: once curl http://localhost:1234/v1/models returns your model, swap your OpenAI base URL in any existing project to http://localhost:1234/v1, set the API key to any non-empty string, and run your test suite against the local model. That’s the fastest way to find out whether your prompts survive the switch – before you build anything new on top.