Headless Deployment with llmster

Every chapter so far has assumed the LM Studio desktop app is running. That is fine on your own laptop, but it does not fit a server. Servers have no screen, no one is logged in to click buttons, and you want the model service to start on boot and stay up. For this, LM Studio runs as a headless daemon named llmster.

llmster is LM Studio with no GUI. It installs with one command, runs in the background, and serves the same REST API, OpenAI-compatible API, and SDKs you have used throughout this book. Your client code does not change. You point it at the server’s address instead of localhost, and everything works the same.

This short chapter shows how to run models on a Linux server: install the daemon, run it as a service, serve several models with JIT loading, lock the API down with authentication, and reach the server from other devices with LM Link.

Installing llmster on a Linux Server

Install the daemon with the same command you saw in the preface:

1 # Mac/Linux
2 curl -fsSL https://lmstudio.ai/install.sh | bash
3 
4 # Windows
5 irm https://lmstudio.ai/install.ps1 | iex

The installer sets up the lms command line tool and the llmster daemon. Start the daemon and check that it is up:

1 $ lms daemon up
2 $ lms daemon status

Once the daemon runs, pull down a model and start the server:

1 $ lms get openai/gpt-oss-20b
2 $ lms server start

The server now listens on port 1234, the same port the desktop app uses. From another machine you reach it at http://<server-ip>:1234/v1 for the OpenAI-compatible API.

Running as a systemd Service

You do not want to start the daemon by hand after every reboot. On a Linux server, run it under systemd so it starts on boot and restarts if it crashes.

The unit file below is a template. Confirm the path to lms on your server with which lms, and set the User to the account that owns your model library:

 1 # /etc/systemd/system/llmster.service
 2 [Unit]
 3 Description=LM Studio headless daemon (llmster)
 4 After=network-online.target
 5 Wants=network-online.target
 6 
 7 [Service]
 8 Type=simple
 9 User=lmstudio
10 ExecStart=/usr/local/bin/lms daemon up
11 ExecStop=/usr/local/bin/lms daemon down
12 Restart=always
13 RestartSec=5
14 
15 [Install]
16 WantedBy=multi-user.target

Enable and start the service:

1 $ sudo systemctl daemon-reload
2 $ sudo systemctl enable --now llmster
3 $ sudo systemctl status llmster

Check the exact daemon command against the official CLI docs for your version, because the invocation can change between releases. The Restart=always line is the important part: it brings the service back if it ever exits.

JIT Loading for Multi-Model Serving

A server often needs to answer requests for several models. You do not have to load them all at once, which would use far too much memory. JIT (Just-In-Time) loading, covered in the API chapter, does the work for you. When a request names a model that is not in memory, the server loads it on demand.

Three settings make this practical on a shared server:

JIT loading brings a model into memory the first time a request asks for it.
Idle TTL unloads a model after it sits unused, which frees memory for other models. Set it per request with the ttl field, or per load with lms load <model> --ttl <seconds>.
Auto-Evict unloads the previous JIT-loaded model before it loads a new one, so a single request for a new model does not run you out of memory.

Together these let a modest server present many models to clients while it holds only the ones in active use. A client simply names the model it wants, and the server manages memory behind the scenes.

API Authentication for Network Deployments

On your own machine an open API is fine. On a network-reachable server it is not. Anyone who can reach the port could load models and run inference on your hardware. Turn on authentication before you expose the server.

LM Studio 0.4.0 and later support API tokens with configurable permissions. When authentication is on, every request must carry a valid token. Enable it and create tokens through the Developer tab and the API Tokens modal, as described in the API chapter.

Clients then send the token as a bearer token. With the OpenAI client, put it in the api_key field:

1 from openai import OpenAI
2 
3 client = OpenAI(
4     base_url="http://your-server:1234/v1",
5     api_key="YOUR_LM_STUDIO_TOKEN",
6 )

For a raw REST call, send an Authorization: Bearer <token> header. Pair authentication with a firewall rule that limits which hosts can reach the port, and you have a service that is safe to run on a shared network.

Serving Models to Remote Clients with LM Link

Opening a port on the network is one way to reach a remote model. LM Link is another, and it is often the better one for personal use. LM Link gives you end-to-end encrypted access to your models across your own devices, built in partnership with Tailscale, with no open port to manage.

Enable it on the server with the CLI:

1 $ lms link enable
2 $ lms link status

Now a laptop or phone signed in to the same account can use the server’s models over the encrypted link. This lets you keep a powerful, always-on machine at home serving a large model, and reach it from a lightweight device wherever you are, without exposing the API to the public internet.

Wrap Up

With llmster you take everything this book taught on the desktop and move it to a server. The daemon serves the same APIs, so your code does not change. Run it under systemd for reliability, use JIT loading with idle TTL and Auto-Evict to serve many models from limited memory, protect the API with tokens and a firewall, and use LM Link when you want private access from your other devices. The result is a private inference server that you own end to end.

Local Agents With LM Studio Bionic