What comes next, in the open.

planned Several PHP versions and database servers at the same time.

Today a stack runs one PHP version and one version per database engine: the container is a property of the stack, not of a project. The goal is the smallest number of containers that still lets every project have what it needs:

• one app container per PHP version in use, not per project; the version that nobody needs never starts;
• one container per database engine and version in parallel — mysql 8.0 next to mysql 9.7 next to postgres 16 — on their own ports;
• a mapping from project to versions, read by laser scan and by the CLI, so laser artisan in a project picks the container of that project;
• a small router in front, so all of it still answers on port 80 by host name;
• defaults that keep today's behaviour: a stack that declares nothing behaves exactly as it does now.

The direction we are working from: a .laserstack file in the project root (a KEY=VALUE file, read like .env), then composer.json as a floor, then the stack default. One container per version, shared by every project that needs it, instead of a stack per project.

---

planned A local DNS that the stack maintains itself.

A suffix of your own is resolved through /etc/hosts today: a manual step, easy to get wrong, and the first thing a newcomer trips over. Since laser already knows the suffix and every project, it should own the resolution:

• install what it needs, write the configuration, start the service, and keep it in step with laser scan, on macOS, Linux and WSL2;
• tell the user what it changed, and remove all of it again on request;
• work without a daemon where a machine cannot or should not run one.

The direction is dnsmasq — it resolves the whole suffix as a wildcard, so a new project needs no DNS step at all — for a user who wants a suffix of their own. .test is the candidate there, because that name is reserved by RFC 6761 for exactly this, while local belongs to mDNS/Bonjour and .app/.dev are real TLDs. SUFFIX stays a setting.

Mostly moot, and worth saying: the domain localdev.it already does this without any daemon. Every name under it resolves to 127.0.0.1 and ::1 for anyone, so SUFFIX=localdev.it gives every project a working name with nothing installed and nothing to maintain — which is why it is the default of env.example now, and a project needs no DNS step at all. What remains above is the convenience of a suffix of the user's own.

---

Just shipped — 0.13.2, 2026-11-05

• Each database version keeps its own data volume. The volume name carries the version, so switching MYSQL_VERSION, MARIADB_VERSION or POSTGRES_VERSION starts that version with its own data directory and leaves the data of the others alone: a version change needs no laser down -v and loses nothing. Before this, one volume per engine was shared by every version of it, which is what made a version switch fail on a downgrade or destroy data;
• Upgrading from an earlier release: the databases now live under the versioned names, so a stack that ran before starts with a fresh volume unless you copy the old one across — the README has the two commands, and the old volume is left untouched either way;
• A comparison page: Valet, Herd, Sail, DDEV, Lando, Laradock and lerd, on the axis that decides the bill — one stack for every project, or one container set per project — with every claim sourced from the project's own documentation;
• A terminal demo of the real flow, on the overview page and in the README: two containers, seventeen projects, one request answering 200.

Just shipped — 0.13.1, 2026-11-05

• Project names need no DNS setup: env.example defaults SUFFIX to localdev.it, and every name under that domain — any depth, IPv4 and IPv6 — resolves to loopback for anyone, so a fresh install serves projecta.localdev.it with no /etc/hosts line and no dnsmasq. A suffix of your own still needs the hosts file, and laser new writes that line for you;
• laser update: fast-forward the checkout, pull the newest images of the active profiles, and restart only the containers whose image changed, so a nightly app image patch reaches a running stack with one command;
• One-line install: curl -fsSL https://localdev.it/laserstack/install | bash checks bash, git and docker, clones the stack next to your projects and writes .env, touching nothing else on the machine;
• This site, published from the repository: overview, features, measured numbers with the method, documentation, examples and this roadmap — static HTML and one CSS file.

The project is also called the localdev.it stack now, tied to the domain of the default suffix.

Just shipped — 0.13.0, 2026-11-04

• Database versions are selectable the same way PHP always was: one variable per engine selects the image tag and the config directory. mysql 8.0/8.4/9.7/26.10, mariadb 10.11–13.0, postgres 15.1–18, redis 7.4–8.10, elasticsearch 7.14.2/8.19.23/9.5.5, memcached 1.6 — each combination verified with the smoke test;
• laser mysql runs the client inside the database container, over its own socket. That is what makes MySQL 8.4, 9.7 and the 26.10 series work at all, since their accounts use caching_sha2_password;
• Config per version: the mariadb, redis and elasticsearch profiles have their config in the repository now, and the mysql host cache setting moved into config/mysql/<version>/docker.cnf;
• The documentation is split into a user part (README) and a development part (CONTRIBUTING), including how to run the tests.

The full changelog → · Releases →

How to push these along

• Say what your projects need. Which PHP and database versions do you have to run side by side? That decides the defaults of the mapping;
• Open an issue for a bug, a missing driver, or a version the stack should support — the version work has a small, documented recipe, so adding one is a good first contribution;
• Bring a project type. The drivers behind laser scan are one file each, and a new framework or CMS usually needs a dozen lines;
• Star or share the repository if the stack fits your work: it is the whole distribution channel of this project.

Issues and ideas → · Working on Laser Stack →