OLS
Open Local Server is a local development environment manager for
Windows. It installs and supervises runtimes, gives every project its
own .test domain with trusted HTTPS, and keeps databases,
mail and caches behind one core engine.
Windows 10 / 11, 64-bit. OLS-1.1.0-setup.exe, a
portable zip,
and SHA-256 sums
to check either against. Source on
GitHub.
Other local stacks give you one PHP, one database and one shared web root, and the next project that needs a different PHP version changes it for everybody.
OLS keeps one environment per project instead. Multiple runtimes sit side by side, a version is pinned to the project that needs it, and the web server configuration, the database, the certificate and the domain registration are all done for you.
Every error it shows is a Diagnostic — what broke, why, and
how to fix it. It never overwrites configuration you edited by hand:
generated files are tracked, drift is detected, and history keeps a diff
and a restore for every change.
All three send the same CoreCommand JSON to
ols-core. The CLI drives the open app, or starts a
background daemon when the app is closed.
No hand-edited paths, no manual certificate trust, no per-project README telling you which commands to run in which order.
Side-by-side versions per runtime, with a default for new projects that a project can override.
Every project gets its own domain and a certificate Windows already trusts.
<folder>.test domain.test, .localhost and .internal; optional elevated helper for everything elseThree engines, generated configuration, and a history that shows every diff.
A project that describes itself, and a setup that can be previewed before it touches anything.
composer.json, package.json, manage.py.openlocalserver/*.yaml: environment, services, commands, lock file.env editorEngines, users and backups managed per project, with mail capture.
Health, traffic and findings in one place, with the fix next to the finding.
Ctrl+K search and Ctrl+Shift+P command paletteStart from a recipe, then run what the project already exposes.
Share a local site on purpose, and see what comes back.
The same engine, reachable the way your tools expect.
olsc.exe beside the app, so olsc works with the GUI closed, through a background coreScreenshots captured from the running desktop app in its dark theme. Nothing on this page is a mock-up.
Dashboard Sites and projects counted, resource rings, a traffic graph built from the access log, all nine services with their ports, and diagnostics. Unavailable services are shown flat grey rather than looking clickable.
Sites
One table for sites and projects. Tick rows and the bulk bar appears — enable, disable, add auto domains, move them to another web server, or delete — and a batch reports what changed and what it skipped. Each row's own settings open its web config, servers, terminal, .env, Git, workers, snapshots, repair and load testing.
Runtimes Every runtime with its installed versions, a default badge and a manage action — plus the two ways to bring your own: scan a folder, or locate a single executable.
Version manager Per runtime: search the vendor catalog, download and install, then manage extensions, Xdebug and the default for each installed version. SHA-256 is checked when the vendor publishes it.
Web server Engine choice, ports and ownership mode. The config is validated before the reload, rolled back if it fails, and compared against what is on disk so hand edits surface as drift instead of being overwritten.
Databases
Engines, databases and users with the connection details to paste. Backup takes a safety copy first; SQLite runs .backup and an integrity check. Databases from other common Windows stacks import live, without a dump file.
Tunnels
Nothing is made public without starting it and confirming the exposure. Provider binaries are found on PATH or in a known location rather than installed for you; tokens stay in Windows Credential Manager.
Everything below is done in the desktop app. The command line is optional and there is a section below for it, because most of the work is not terminal work.
Run the downloaded OLS-1.1.0-setup.exe and open OLS.
Windows 10 or 11, 64-bit.
Open Runtimes and install a PHP version, plus Node or Python if you use them. Checksums are verified on download.
Open Sites, add a project folder and give it a domain.
.test names resolve without editing the hosts file.
Apply the web config and trust the local certificate authority once, so HTTPS sites stop warning.
olsc command
The install folder holds OLS.exe, the app, and
olsc.exe, the command line — two separate programs with two
separate names. (olsc rather than ols because
Windows does not tell file names apart by case: the app is
OLS.exe, so anything called ols finds the app
and opens a window instead of running a command.) The installer does not
add that folder to your PATH, which is why olsc
can come back as "not recognised". Pick whichever of these suits you:
C:\OpenLocalServer under Path, then open a new
terminal. olsc status works from there on.
C:\OpenLocalServer\olsc.exe status
olsc talks to the app while it is open and starts a
background core when it is not, so it behaves the same either way.
olsc status # services, sites, runtimes
olsc start # start every enabled service
olsc stop # stop everything
olsc doctor # problems as Problem / Cause / Fix
olsc project list # registered projects
olsc service list # MariaDB, Postgres, Redis, Mailpit…
olsc runtime list # installed PHP and Node versions
olsc tunnel start --provider cloudflared --port 443
olsc worker run --queue default
olsc snapshot create --name "before-upgrade"
olsc search "mailpit"# Clone any PHP / Node / Python project
git clone https://github.com/example/my-laravel-app.git
cd my-laravel-app
# Runtimes, database, domain, DNS, SSL, mail, workers
olsc setup
# Preview the plan without applying it
olsc setup --dry-run
# Health, then safe fixes
olsc doctor
olsc repairFor working on OLS itself. Nothing in the four steps above needs this.
# Rust toolchain (if missing)
winget install Rustlang.Rustup
# Node 22 (if missing)
winget install OpenJS.NodeJS.LTS --version 22
# UI dependencies
cd ui
npm install# Tauri + Vite + Rust core, with hot reload
.\scripts\dev.bat
# Quality gates
cargo fmt --all
cargo clippy -p ols-core -p ols-helper --all-targets
cargo test -p ols-core -p ols-helper
cd ui; npm run lint; npm run build
cd ..
# NSIS / MSI bundle
cargo tauri build
ols-core is a single CoreCommand dispatcher over
shared state. The GUI, the CLI and the HTTP API are three front doors onto
the same managers — there is no second implementation of anything.
ols-core · Tokioolsc — a separate program beside the app; works once the install folder is on PATHols-helper — hosts, NRPT and services over a named pipe or one UAC promptapp.db; OLS_HOME overrides every path
The local API is off by default and listens on
127.0.0.1:7420. Every request needs a bearer token;
requests carrying an Origin header are refused. A
read-only scope covers queries, an operate scope covers changes.
curl -H "Authorization: Bearer ols_..." \
http://127.0.0.1:7420/v1/ping
curl -H "Authorization: Bearer ols_..." \
-H "Content-Type: application/json" \
-d '{"type":"list_services"}' \
http://127.0.0.1:7420/v1/command
Plugins are declarative: a plugin.yaml checked against a
schema, contributing runtimes, Quick App recipes, project detections
or health checks. A plugin stays off until you approve exactly the
permissions it lists, and remote catalogs are minisign-signed and
re-verified on every load.
OLS keeps specs/ as its source of truth for architecture,
modules, data models and API. A pull request that changes behaviour
without updating the matching spec is rejected in review — so the
documentation cannot drift away from the code.
Reports and discussions go to the issue tracker. Security issues follow the published policy rather than a public issue.
Start with the installer. The four steps above take a project folder from a clone to a working site on a certificate your browser already trusts.