Local Studio: a control panel for vLLM, SGLang, llama.cpp and MLX

The problem Local Studio targets: four runtimes, four sets of flags

Serving a model locally is easy once. Keeping it easy across vLLM, SGLang, llama.cpp and MLX is not, because each backend has its own launch syntax, its own process lifecycle and its own way of reporting whether it is healthy. Local Studio positions itself as the layer above those runtimes. The README describes it as a "local-first workstation for running, managing, and using self-hosted LLM backends", and version 2.0 reorganised the interface around Status, Workbench, Configure and Usage rather than separate model, integration and server screens.

The audience is narrow and specific: people who own the GPU, or rent one, and want to keep inference on hardware they control while still having a dashboard. The repository topics (vllm, sglang, llamacpp, exllama, local-ai) match that. If you are happy calling a hosted API, this project has nothing to offer you. If you already run llama-server or vllm serve by hand and keep notes on which flags worked, the pitch is that the recipe layer remembers for you.

Controller, frontend and the SSE stream between them

The architecture is two modules sharing one controller API. The controller lives in controller/ and is a Bun/Hono backend. It owns model lifecycle (launch, evict, recipes, downloads, runtime process coordination), an OpenAI-compatible proxy covering chat, models, tokenization and audio, system state such as GPU metrics, logs, usage, settings and SSE, plus controller integrations. The frontend lives in frontend/ and is Next.js 16 with React 19, plus the macOS Electron shell. It hosts the Workbench at /agent, the Configure surface, settings, usage, logs and browser-facing API routes.

The split matters because the frontend does not have to sit on the same machine as the GPU. The README states you can run a controller locally or point the frontend at a remote controller on a GPU host. That is the deployment shape most people actually want: a laptop for the UI, a Linux box with the NVIDIA driver for inference. The controller is where state lives, including a SQLite database created automatically on first start.

Events flow back over SSE. One production note in the README is easy to miss and expensive to ignore: `npm run start` launches the standalone server through scripts/project.mjs, and the README says never to use plain `next start` because it breaks SSE streaming. If the UI loads but live status never updates, that is the first thing to check.

Installing Local Studio and launching a first model

There are two paths. The README offers a signed and notarized macOS Apple Silicon build, Local-Studio-arm64.dmg, which updates itself from GitHub releases. The source path needs Bun 1.3.14+, Node.js 22.19+, npm 10+, Python 3.10+ and Git. The README strongly recommends uv and notes that engine installs fall back to pip. vLLM and SGLang serving on Linux needs the NVIDIA driver plus CUDA; Apple Silicon uses the MLX backend.

From the repository root, validate the toolchain and then install every locked workspace dependency:

npm run doctor
npm run setup

The doctor script is a preflight check against the prerequisites above. The setup script installs the controller, shared contracts, agent runtime and frontend from their lockfiles. Expect it to take a while on a cold machine.

Start the controller in one terminal. It listens on 127.0.0.1:8080, creates the data directory and SQLite automatically, and keeps model weights in LOCAL_STUDIO_MODELS_DIR, which defaults to /models:

bun --cwd controller run dev

Start the frontend in a second terminal and open the setup wizard:

npm run dev

The wizard at http://localhost:3000/setup walks through choosing a models directory, installing an engine, downloading a model, launching it and benchmarking. Engine installs for vLLM, SGLang and MLX land below the data directory at runtime/venvs/<backend>-latest. For production, build first, then run the controller and the standalone frontend in separate terminals:

npm run build
bun --cwd controller run start
npm run start

Where the security model stops: agent tools and remote bind

Two limits deserve attention before anyone exposes this beyond localhost.

The first concerns the agent surface at /agent. New Workbench chats start with Pi's read, grep, find and ls tools. Full access enables every tool registered in that Pi session, including extension tools. The README is explicit that read only is a model-tool allowlist, not an operating-system sandbox, and that loaded extensions may still have their own behaviour. Pi runs with the full permissions of the host user. Tailscale limits who can reach the dashboard; the README states plainly that it does not sandbox Pi. Anyone expecting container-grade isolation from the permission toggle will be disappointed.

The second concerns binding the controller to a non-loopback address. The .env.example file documents that LOCAL_STUDIO_API_KEY is required when LOCAL_STUDIO_HOST is non-loopback, and that the controller refuses to start without it unless LOCAL_STUDIO_ALLOW_UNAUTHENTICATED=true. Setting that flag is an explicit opt-out that the file says to use only on trusted LANs, and keyless wildcard binds must also list every accepted hostname or IP in LOCAL_STUDIO_ALLOWED_HOSTS. There are two privileged-capability opt-ins as well, both off or defaulted in the documented way: LOCAL_STUDIO_ALLOW_CUSTOM_LAUNCH_COMMAND defaults to false because it permits recipes to specify a raw launch_command, and LOCAL_STUDIO_DEFAULT_TRUST_REMOTE_CODE defaults to true, which the file notes means models needing custom modeling code work out of the box. Teams that treat remote code execution as unacceptable should set that second value to false and opt in per recipe.

Against Ollama and the raw OpenAI-compatible server

The obvious comparison is Ollama, which also gives a local OpenAI-compatible endpoint and a model pull command. The difference is the layer each one owns. Ollama abstracts the runtime away: you get its scheduler and its model format, and you do not choose vLLM or SGLang flags. Local Studio goes the other way and keeps the runtime visible. Recipes launch through the controller runtime layer against wired backend families: vllm through configured, discovered, system, Docker or bundled targets; sglang through launch-server recipes against configured or discovered Python targets; llamacpp through llama-server recipes for GGUF models; and mlx through mlx_lm.server recipes on Apple Silicon.

That is more surface area to configure, and runtime target discovery, models, integrations and server controls are all surfaced in Configure, with selections persisted in the controller data directory. The payoff is that you keep the throughput characteristics of the engine you picked and can move between targets without changing tools. If your needs fit inside Ollama's defaults, Local Studio asks you to learn more than you need. The other alternative is running vllm serve or llama-server directly and skipping the dashboard entirely, which is a reasonable choice for a single fixed model and becomes tedious the moment you want eviction, GPU metrics and usage in one place.

Mobile pairing, licence and what an upgrade costs

KittyLitter connects to Local Studio so the same agent sessions, streaming content, reasoning, tool calls and tool results appear on iPhone, iPad and Android. Pairing happens from Settings, Profile & phone, Connect your phone. The README warns that the QR code and copied connection JSON are private controller credentials and should be shared only with a device you trust. It also states version floors: pairing requires Local Studio 2.9.0 or newer and KittyLitter 1.6.0 or newer. Note that the repository package.json reports version 2.1.0 while the latest release listed is v2.16.0, so treat the release page as the version of record rather than the manifest.

On maintenance: the repository is not archived and the last push was on 2026-09-14, two days before this was written, with v2.16.0 released on 2026-09-02. That is a fast release cadence, and it is also the upgrade cost. The README documents that the macOS build updates itself from GitHub releases, and it documents no rollback path for that self-update, so pinning a known-good release from the releases page is the only stated way to stay put. Source installs are pinned through the lockfiles that `npm run setup` reads.

The licence is Apache-2.0, which permits commercial and private use and includes an explicit patent grant. Apache-2.0 also requires that you keep the licence and notice files and state significant changes if you redistribute a modified version. This is a description of the licence text, not legal advice; if you plan to ship a modified controller inside a product, have counsel read the NOTICE requirements rather than taking this paragraph as clearance.

Editorial conclusion

Adopt Local Studio if you already run vLLM, SGLang, llama.cpp or MLX on a machine you control and want one dashboard for launch, eviction, GPU state and an OpenAI-compatible proxy, with the controller able to sit on a remote GPU host. Skip it if you need a Windows or Linux desktop build, since the README offers only a signed macOS Apple Silicon download, or if you want an OS-level sandbox around agent tools, because the README states read only is a model-tool allowlist and Pi runs with the full permissions of the host user. Before committing, run npm run doctor, then npm run setup, and read .env.example in full: decide whether LOCAL_STUDIO_DEFAULT_TRUST_REMOTE_CODE should stay at its documented true default, and check whether any recipe you depend on needs LOCAL_STUDIO_ALLOW_CUSTOM_LAUNCH_COMMAND.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. sybil-solutions/local-studio on GitHub