Looking Glass gives your routers a public command line, with a PHP web front end

What a looking glass is and who this one is for

The project describes itself as an easy to deploy Looking Glass made in PHP, and the documentation explains what that term means. A looking glass is a tool used to get information about networks by giving the opportunity to execute some commands on routers, with the output sent back to the user.

That is a narrow purpose and a real one. Network operators have traditionally published a looking glass so that other networkers, peers and researchers can check how your routes look from the outside, run a traceroute through your infrastructure, or query a prefix. Doing that by hand means giving shell access to the outside world, which nobody wants. A looking glass constrains that access to a list of commands and returns only the output.

The audience is therefore network operators, particularly at networks that publish peering information. The topic list names BGP, routers, routing and network alongside PHP, and the supported router families are all the ones you would find in an ISP or a transit network: Arista, BIRD in both v1 and v2, Cisco IOS and IOS-XR, Extreme and Brocade NetIron, FRRouting, Huawei VRP, Juniper, Mikrotik RouterOS, Nokia, OpenBGPd, Quagga, Vyatta and EdgeOS, and VyOS.

The project is honest about its state. The documentation opens by saying that a lack of time and funding has slowed the project down quite a lot, while it is still maintained, and that you can sponsor it or contribute in any way you can. The release history supports that reading: version 2.3.1 in March 2026, before that 2.3.0 in February 2024 and 2.2.0 in May 2022. The repository is not archived and the last push was on 2026-10-01, so the code is still being touched, but the version numbers are not moving quickly.

How commands actually reach the routers

The mechanism is straightforward once you know it, and it has three moving parts: a per-router configuration, a transport, and a filter.

The transport is either Telnet or SSH, and the documentation is specific about the authentication options, supporting password authentication and SSH keys. The routers/ directory in the repository holds the per-model definitions, which is how a generic tool ends up knowing the difference between how you query a Juniper and how you query a FRR daemon.

The filter is the security-relevant part and it is configurable in two directions. There is a configurable list of allowed commands, so you decide per looking glass instance, and per router, what may be run. There is also customizable output with regular expressions, which lets you strip or reshape what comes back before it is displayed. The list of routers is configurable too, so one instance can front several routers with different credentials.

Two more features round out the design. All commands are logged to a file, which is what you want when the tool is publicly reachable and you need to know what was asked. And custom routing instances, meaning VRFs, are supported for Juniper for now, which is the one place the project admits a limitation in its own feature list. The feature list also mentions an interface built on Javascript and AJAX calls, which the documentation notes needs a decent browser.

The future list in the documentation is short and honest: support for more routers, and support for other types of authentication. So there is no multi-user account system, no per-user permissions, and no authentication beyond what the routers themselves accept. That is a meaningful constraint for a public deployment, and it is the constraint to think about before you expose one.

The anti-spam mechanism and the SQLite dependency

Among the requirements listed is the PDO extension, needed to interact with SQLite for the anti-spam feature, with php8.4-sqlite3 named as the Debian package example. That is a small requirement to list but it points at the design decision that makes this project safe to put on the internet.

A looking glass lets strangers run commands on your routers. Even with an allowlist, an endpoint that runs commands on demand is a target, because the commands themselves consume resources on the router and the responses consume resources on your web server. The anti-spam feature, implemented in SQLite via PDO, is the mechanism that limits how often a visitor can act.

This is the part of the design that differs from a typical shell-runner, and it is the reason the SQLite requirement is called out separately from the general PHP module requirement. A SQLite file is also a nice operational property. There is no database server to run, no credentials to rotate and no migration to manage, and the state is a file you can back up, move or delete when you want to reset the rate limits.

The requirement list in full is a web server such as Apache 2 or Lighttpd, PHP 8.2 or newer as a module for the web server, Composer to install dependencies, the PDO extension for SQLite, and the XML package. The documentation gives the Debian package names for the last two. PHP 8.2 as a floor is worth noting, since it means the project has been kept on a recent language version rather than left on an old one.

Deploying it, with Composer or with Docker

There are two documented routes, and the choice is between running a classic PHP application and running a container.

The classic route is three steps. Install Composer and run composer install to pull in the dependencies, which the documentation notes is not necessary if you use Docker. Then copy the configuration file config.php.example to create a config.php, which contains all the PHP variables used to customise the looking glass. Then point your web server at it. The details of each option live in docs/configuration.md, and the repository root includes an.htaccess file for Apache deployments.

The Docker route is a multi-stage build that is worth reading, because it shows what the project author considered necessary to ship. The builder stage is based on php:8.5-fpm-alpine, copies the Composer binary in from the composer image, installs the build dependencies including git, unzip, gmp-dev and sqlite-dev, and installs the gmp and pdo_sqlite PHP extensions. It then copies composer.json and composer.lock and runs a production install:

FROM php:8.5-fpm-alpine AS builder

COPY --from=composer:latest /usr/bin/composer /usr/local/bin/composer

The second stage then strips the vendor tree down, deleting markdown files, licence files, changelogs, gitignore and gitattributes, and removing test and docs directories from vendored packages, and pruning the Bootstrap distribution to just the minified CSS and JS. The final stage is again php:8.5-fpm-alpine with Caddy copied in as the web server, the openssh-client, openssl, gmp and sqlite-libs packages added, the cleaned vendor tree copied across, the Caddyfile placed in /etc/caddy/Caddyfile and the docker-entrypoint.sh made executable. Bundling Caddy with PHP-FPM in one image is a choice worth noting, because it means you get a TLS terminating reverse proxy and an application server in a single container with no separate web server to configure.

Where Looking Glass is the wrong choice

The first limitation is the authentication story, and it is structural rather than a missing feature. The project lists support for other types of authentication as future work, which means today there is no user account system. Anyone who reaches the page can run any command on the allowlist against any configured router. For an internal looking glass on a private network that is often acceptable, because network access is the control. For a public instance it is not, and the allowlist plus the anti-spam table are the only brakes.

The second limitation is the router coverage. Thirteen families is a lot by any standard, but a looking glass is only useful for the protocols its targets speak, and each supported family brings its own quirks in output format and command dialect. The documentation notes that VRF support is Juniper only for now, and the future list mentions more routers, so coverage is uneven by design and by age of the underlying support. If your estate is built on one vendor that is not on the list, this tool does not help.

The third is the pace. The project says so itself, and the release dates back it up, with 2.3.1 in March 2026, 2.3.0 in February 2024 and 2.2.0 in May 2022. Anyone planning to rely on this needs to accept that security fixes in the PHP dependencies or in the underlying libraries arrive when the maintainer has time, not on a schedule.

The alternative to weigh is Reflet, the newer project the README points at, described as a new project with a new approach. The difference in approach is the one that matters for a tool that runs commands on your routers: this implementation executes against a list of routers with credentials held server side and returns output to an anonymous visitor, whereas the newer project is a departure from that design, and the README points readers to it. There is also the general alternative of exposing a read-only SNMP or streaming telemetry endpoint instead of a command interface, which gives structured data rather than free-form output but also removes the ability to run a traceroute on demand, which is often the reason a looking glass exists in the first place.

Editorial conclusion

Adopt Looking Glass if you operate routers and want a self-hosted looking glass with a configurable command allowlist, per-router credentials and output filtering that you control. Do not adopt it as a public service for arbitrary users without hardening, because the command execution and the anti-spam table both need attention first, and do not expect an actively fast moving project, since the project states that a lack of time and funding has slowed it down. Before you deploy it, read docs/configuration.md for the configuration options, decide which commands each router type may run, and confirm your web server and PHP extensions meet the stated requirements of PHP 8.2 or newer with PDO and XML.

Frequently asked questions

Official sources

1. gmazoyer/looking-glass on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases