FlyEnv: a native local dev environment for PHP, Node.js and everything around them

The problem FlyEnv is aimed at: a local stack that outgrew one runtime

A single local project often needs a language runtime, a web server, a database, a cache, a queue, a search engine, object storage and a mail catcher. The README draws that tree explicitly: PHP, Node.js, Python, Java, Go or .NET at the top, then Nginx, Apache or Caddy, then MySQL, PostgreSQL or MongoDB, then Redis or RabbitMQ, then Elasticsearch or Meilisearch, then Minio or RustFS, then Mailpit, then a local domain with HTTPS and a reverse proxy. Assembling that by hand means one installer, one config format and one upgrade path per component.

The audience is developers who already know this pain. The README positions FlyEnv against tools such as XAMPP, MAMP and Laravel Herd, and says it targets people who want that convenience across a wider stack. It also names the case it is not built for: the README states plainly that FlyEnv is not a Docker replacement and does not try to reproduce Docker Compose or Kubernetes environments. That sentence does more work than any feature list, because it tells you the project is optimising for startup speed and direct OS access rather than for parity with production.

How FlyEnv works: native binaries, per-project versions, one shared workspace

FlyEnv runs native binaries as native processes. There is no VM and no container runtime in the path. The desktop app owns the lifecycle of each component: install, configure, run, then wire it to a local domain, a certificate, a reverse proxy rule and a tunnel. The README summarises the chain as install, configure, run, local domain, HTTPS, reverse proxy, tunnel, debug, and argues that the value is not that each feature exists somewhere, but that they share the same projects, services, versions and sites.

The mechanism that matters most day to day is version selection. The README shows the intended behaviour with a shell example: after switching, `php -v` reports PHP 7.4 in a legacy WordPress directory and PHP 8.3 in a modern Laravel directory. FlyEnv keeps multiple versions side by side and assigns them per project where the runtime supports it, so you do not rewrite global environment variables or edit system PATH entries each time you move between projects.

Around that core sits a services layer (Nginx, Apache, Caddy, FrankenPHP, Tomcat, MySQL, MariaDB, PostgreSQL, MongoDB, ClickHouse, Qdrant, Neo4j, Redis, Memcached, RabbitMQ, Elasticsearch, Meilisearch, Typesense, ZincSearch, Minio, RustFS, Mailpit, Consul, Etcd, R-Nacos, Temporal), a local sites layer for names like `https://myapp.test` with managed certificates, ports and reverse proxy rules, and a project services layer for apps that bring their own dev server, where you define start and stop commands, ports, runtime versions, proxy rules, HTTPS and local domains.

The repository layout backs this up. It is a TypeScript project with an Electron-shaped structure (`src/`, `build/`, `configs/`, `public/`, `static/`, `patches/`, `scripts/`, plus per-platform update manifests such as `latest.yml`, `latest-mac.yml` and `latest-linux-arm64.yml`). The package.json declares `"engines": { "node": ">=18.0.0" }`, which is the requirement for building the app itself, not for the runtimes it manages. There is also a `flyenv-helper` binary referenced in a macOS script that strips the quarantine attribute, which tells you some operations go through a privileged helper rather than asking for a password on every action.

Installing FlyEnv and running a first PHP or Node.js site

FlyEnv is a desktop application, so installation means downloading a build for your platform rather than running a package manager command. The README points to a download page on the project site and to the releases page on GitHub. The README does not give a Homebrew, winget or apt command, so do not expect one. The package.json scripts (`clean:dev`, `build-dev-runner`, and a long list of `test:*` entries) are for working on FlyEnv itself, not for installing it.

Once the app is running, the first useful exercise is a version switch. The README gives this example for the intended result:

cd ~/projects/legacy-wordpress
php -v   # PHP 7.4

cd ~/projects/modern-laravel
php -v   # PHP 8.3

If those two commands report different versions in the same terminal session, the per-project assignment is working. If both report the same version, the project association has not been picked up, and the README does not document a fallback for that case.

The second exercise is a local site. The README shows the shape of the domains FlyEnv manages:

https://myapp.test
https://api.myapp.test

Creating a site in the UI is meant to handle the local domain, the certificate, the port and the reverse proxy entry together, so you should end up with a working HTTPS URL without editing a vhost file by hand. For an application that already has its own dev server, the project services form is where you supply the start command, stop command, port, runtime version, proxy rule, HTTPS setting and local domain.

Where FlyEnv is the wrong tool, and what it does not promise

The clearest limitation is written into the README: native processes are not containers, so the environment you develop in is not the environment you deploy to. If your production contract is a Docker Compose file or a Kubernetes manifest, FlyEnv will not reproduce it, and the README says so rather than pretending otherwise. Teams that rely on container-level isolation between services, or that need to test against the exact base image used in CI, should keep their container workflow.

The second limitation is scope. The README's own comparison table says another approach may be better if you only use one runtime and prefer the system package manager, or if you prefer to configure and operate every local service manually. FlyEnv's value comes from breadth; a developer with one language and one database gets less from it than someone running four services across three projects.

Third, the README does not document rollback or downgrade behaviour for managed services, and it does not document what happens to existing service data when a component is upgraded or removed. That is the kind of gap you want to close before pointing FlyEnv at a database you care about. The README is also silent on resource usage when many services run at once, and on how port conflicts are resolved when two projects want the same port. Treat those as things to verify in your own environment rather than as documented guarantees.

FlyEnv compared with Laragon, and with Docker Compose

Laragon is the closest comparison the README invites, and the difference is breadth and platform reach rather than the idea itself. Laragon is a Windows-first stack aimed mainly at PHP-style web development. FlyEnv ships for Windows, macOS and Linux, and its service list extends well past the classic PHP stack into search engines, message queues, object storage, service discovery tools such as Consul and Etcd, and workflow engines such as Temporal. If your work is PHP plus MySQL on Windows, Laragon covers it. If you also need ClickHouse, Qdrant or Temporal locally, FlyEnv's module list is the reason to look at it. The README also names XAMPP, MAMP and Laravel Herd as points of comparison, but does not go into mechanism-level differences with them.

Docker Compose is a different kind of comparison, and the README treats it as the boundary rather than the competition. Compose gives you reproducibility and isolation at the cost of a daemon, image pulls and a slower start. FlyEnv gives you direct native processes and faster startup at the cost of parity. The honest framing is that these solve different problems: Compose answers "does this work in the environment we deploy to", FlyEnv answers "can I get five services and a local HTTPS domain running in the next two minutes". A project can reasonably use both.

Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-08-21, which is recent enough to treat the project as live. The release history shows a steady cadence: v4.18.1 on 2026-08-21 focused on Windows setup reliability, Tomcat app mappings and Persian language support; v4.18.0 on 2026-08-08 added a Neo4j module along with pgAdmin 4, dbGate and Redis Commander; v4.17.2 on 2026-07-26 added ClickHouse, Temporal and Temporal CLI modules plus helper fixes. The pattern is new service modules and fixes rather than rewrites, which is what you want from a tool whose main job is to manage other people's binaries.

The upgrade cost sits mostly in the managed components, not in FlyEnv itself. Because FlyEnv installs and runs native runtimes and databases, each module brings its own version history and its own data directory, and the README does not describe a migration path when a service version changes. Budget time for that. The app itself updates through per-platform manifests in the repository root (`latest.yml`, `latest-mac.yml`, `latest-mac-arm64.yml`, `latest-linux.yml`, `latest-linux-arm64.yml`), which is the standard auto-update shape for an Electron application.

FlyEnv is BSD-3-Clause. That is a permissive licence: it allows use, modification and redistribution, including in closed products, provided the copyright notice and licence text are retained. It also means no copyleft obligation on your own code. This is a description of the licence text, not legal advice; read the LICENSE file in the repository if the distinction matters to your organisation. Note that the licence covers FlyEnv itself, not the third-party runtimes and databases it downloads and runs, each of which carries its own terms.

Editorial conclusion

Adopt FlyEnv if you juggle several runtime versions and a handful of local services on one machine, and you want local domains, HTTPS and cron in the same window as the services themselves. Skip it if your team's contract with production is Docker Compose or Kubernetes, or if you only ever run one runtime and are happy with the system package manager. Before committing, check the download page for your platform, confirm the BSD-3-Clause licence text in the repository LICENSE file, and try one project-specific PHP or Node version switch to make sure the PATH behaviour matches how you work.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes