Set Up FlyEnv and Share a Dev Site with Localtonet

When FlyEnv is a practical XAMPP alternative

A local development environment usually has several moving parts. A PHP application might need PHP itself, a web server, a database, Redis, and Node.js for front-end assets. A Python project might need Python, PostgreSQL, Redis, and Nginx. Installing and maintaining each component separately can create version conflicts, scattered configuration files, and inconsistent startup procedures.

FlyEnv approaches this problem as a native desktop workspace. It can manage runtimes such as PHP, Node.js, Python, Java, Go, .NET, Ruby, Rust, Bun, and Deno; databases such as MySQL, MariaDB, PostgreSQL, MongoDB, ClickHouse, Neo4j, and Qdrant; and web or application servers including Nginx, Apache, Caddy, FrankenPHP, and Tomcat. It also covers supporting services such as Redis, Memcached, RabbitMQ, Elasticsearch, Meilisearch, MinIO, and RustFS.

This broader scope is the main reason to consider FlyEnv when moving beyond XAMPP. XAMPP is familiar to many PHP developers because it bundles a conventional Apache, database, and PHP workflow. FlyEnv addresses a similar local-development need while supporting more runtime families, web servers, databases, and project-level configurations. It can also switch runtime versions by project, define project start and stop commands, create local domains, enable local HTTPS, and configure reverse proxies.

Native operation and containerized operation are not interchangeable. Docker remains useful when a team needs an explicitly containerized environment, reproducible images, or close parity with a container-based deployment. FlyEnv is better aligned with developers who want a desktop-managed native stack and do not need container parity for the current task.

Prerequisites and decisions to make first

Before installing anything, identify what the application actually needs. FlyEnv can manage many technologies, but that does not mean every project needs all of them. A small static site might require only a static HTTP server. A Laravel application can require PHP, a database, Node.js, Redis, and Nginx. A Django application can use Python, PostgreSQL, Redis, and Nginx. Installing unnecessary services increases resource use and expands the number of components that can fail.

Choose the correct operating-system package

FlyEnv supports Windows, macOS, and Linux. Windows users can choose an installer or portable executable. macOS users can install through Homebrew or use a DMG package, with separate packages for Intel and Apple Silicon hardware. Linux packages are supplied in DEB and RPM formats for x86_64 and ARM64 systems.

Confirm both the operating system and processor architecture before downloading. An ARM64 package is intended for ARM64 hardware, while an x86_64 package is intended for 64-bit Intel or AMD systems. On macOS, Apple Silicon systems require the ARM64 build, while older Intel Macs use the Intel package.

Know the project requirements

Record the runtime and version expected by the codebase, the document root or application directory, the database engine, and any auxiliary services. Use the project lock files, dependency manifests, environment template, or team documentation to make these choices. FlyEnv can switch versions, but it cannot determine whether a project was written for a particular PHP, Node.js, Python, Java, or database release unless that requirement is defined by the project.

You should also determine how the application starts. Some applications are served directly from a document root by Nginx or Apache. Others start their own development server on a project-defined port and then sit behind a reverse proxy. FlyEnv supports project start and stop commands and project-defined ports, but the exact command and port belong to the application. There is no safe universal command to substitute for the project’s documented startup process.

Plan the local endpoint before remote access

FlyEnv does not define one universal hostname or port for every site. A site might use a local domain such as myapp.test, an HTTP listener on a selected port, a local HTTPS address, or a reverse proxy connected to an application server. Therefore, this guide does not claim that every FlyEnv site runs on port 80, 443, 3000, 8000, or any other fixed value.

Write down the actual local IP address and port that will accept HTTP requests from the machine running the Localtonet client. A loopback address such as 127.0.0.1 is appropriate only when the Localtonet client runs on the same computer and the application listens there. If the client runs on another device, the service must be reachable from that device through an appropriate local address, and the application must intentionally listen on an interface that permits that connection.

Install FlyEnv on Windows, macOS, or Linux

Use an official FlyEnv package that matches the operating system and processor architecture. Version 4.18.2 is the specific release represented in the evidence used to prepare this guide, but release versions change. Check the current official FlyEnv download or release page before installation rather than assuming that this remains the latest version.

Windows installation

FlyEnv provides two Windows distribution styles. The installer is named in the versioned form FlyEnv-Setup-<version>.exe. The portable package is named FlyEnv-Portable-<version>.exe. For version 4.18.2, the documented filenames are FlyEnv-Setup-4.18.2.exe and FlyEnv-Portable-4.18.2.exe.

Choose the installer when you want a conventional installed application. Choose the portable executable when you specifically prefer a portable distribution. Download the selected executable, verify that it came from the official FlyEnv release channel, and run it using the normal Windows application procedure. If Windows presents a security prompt, verify the publisher and package origin rather than dismissing the warning automatically.

The available evidence establishes the installer and portable package choices but does not document every page or checkbox displayed by the current Windows installer. Those details can change between releases, so this guide does not invent a sequence of installer screens. Complete the prompts presented by the signed package, then launch FlyEnv.

macOS installation

Homebrew users can install FlyEnv with the documented command:

brew install flyenv

FlyEnv also provides DMG packages. Select the Intel DMG for an Intel Mac or the ARM64 DMG for a Mac with Apple Silicon. Open the correct DMG and complete the standard macOS application installation process. Do not install the Intel package merely because it is listed first, and do not select ARM64 without confirming the processor architecture.

macOS may apply security controls to newly downloaded applications. Review the package origin and any system prompt carefully. Avoid weakening system-wide protections merely to make an installation prompt disappear.

Linux installation

FlyEnv publishes DEB and RPM packages for both x86_64 and ARM64 Linux systems. Choose DEB for a distribution that uses Debian packages and RPM for a distribution that uses RPM packages. Then select the architecture matching the computer.

Package installation commands differ among Linux distributions and package managers. The supplied official evidence confirms the package formats but does not establish one universal installation command or dependency-repair sequence. Use the graphical package installer or the documented local-package procedure for the specific distribution. This avoids publishing a command that is correct for one Linux family but wrong for another.

First launch checks

After installation, open FlyEnv and confirm that the application starts normally. At this stage, do not expect a project website to exist automatically. FlyEnv is the management workspace. You still need to select the project’s runtime and services, connect the application directory, and define how the site is served.

If FlyEnv starts but a needed runtime or service is not ready, use the application’s module and service management capabilities to prepare that component. The exact current controls can vary by release and platform. Follow the labels shown in the installed version rather than relying on an outdated screenshot.

Configure a FlyEnv project and local site

The correct stack is determined by the application, not by FlyEnv or Localtonet. Start with the smallest working set of components. Add services only when the application requires them.

Local domain, direct port, or reverse proxy?

A local domain such as myapp.test is convenient for browser-based development and can represent a site served through Nginx, Apache, or Caddy. A direct project port is useful when a framework starts its own HTTP server. A reverse proxy combines the two by accepting requests through a local site and forwarding them to the application process.

For the later Localtonet step, the most important value is the actual HTTP listener that accepts the request. A browser successfully resolving myapp.test does not by itself prove that a request addressed directly to the listener’s IP and port will select the same virtual host. Name-based virtual hosting can show a default site when the expected hostname is absent.

Verify the site locally before creating a tunnel

Remote-access troubleshooting is much easier when the local application is already known to work. A tunnel forwards traffic to a local target. It does not repair a failed runtime, create a missing database, run migrations, correct an invalid document root, or start a stopped web server.

Test the exact local site

Open the FlyEnv-managed site in a browser on the same machine. Use the domain and protocol you configured, or the project’s actual loopback address and port. Do not substitute a common development port unless it is genuinely the configured port.

Check more than the first HTML response. Load stylesheets, JavaScript, images, and a representative application route. If the application has a login screen, test it locally with a non-sensitive development account. If it performs database-backed operations, confirm that at least one safe read or write action succeeds.

Confirm the listener needed by Localtonet

The Localtonet client needs an IP address and port that it can reach. When FlyEnv and Localtonet run on the same computer, a service listening on loopback can normally be targeted through that machine’s loopback address. When they run on different devices, loopback points to the client device itself, not to the FlyEnv computer. In that arrangement, use an address reachable from the Localtonet client and configure the service intentionally for that local-network access.

Test the actual target separately from a friendly local domain when possible. If the domain works but the IP and port show another site, the web server is probably selecting content by hostname. Do not assume that a tunnel option exists to rewrite that hostname. Current Localtonet dashboard capabilities and HTTP tunnel settings should be checked before relying on any host-header behavior not documented in this guide.

Resolve local HTTPS questions before sharing

FlyEnv can create trusted local HTTPS sites, while Localtonet HTTP and File Server process types provide a public HTTPS address. These are different connections. Public HTTPS at the tunnel edge does not establish that an HTTP tunnel should be pointed blindly at a local HTTPS-only listener.

For this workflow, use a known working local HTTP listener as the Localtonet HTTP target. If the FlyEnv site is available only through local HTTPS, consult the current tunnel documentation and select a documented tunnel configuration that matches the origin protocol. Do not enter an HTTPS port into an HTTP target merely because both ultimately display a website.

Share the FlyEnv development site with Localtonet

Once the exact HTTP service works locally, Localtonet can expose it without requiring inbound router port forwarding, firewall changes, VPN setup, or a public IP address. Our client application establishes an outbound connection to a Localtonet relay server. The HTTP tunnel then provides a public HTTPS address that forwards requests to the selected local IP address and port.

Keep the two layers separate in your mental model. FlyEnv manages the development runtime, supporting services, local web server, and site. Localtonet provides remote reachability to the already working HTTP endpoint. Creating a tunnel does not start the FlyEnv project, and starting the project does not automatically start its Localtonet tunnel.

The exact Localtonet relay values and available process-type choices must come from the current dashboard rather than from a copied example. Custom-domain DNS requirements can also change, so check the current Localtonet HTTP tunnel documentation before configuring DNS. For temporary reviews, a generated public address avoids introducing custom-domain DNS into the initial test.

Test the public result as a remote visitor

Open the assigned address from a separate browser profile or another device. This helps reveal assumptions hidden by an existing local session. Check navigation, static files, form submissions, API requests, authentication, redirects, and any absolute URLs generated by the application.

A page can render while still producing links to localhost, a local domain, or an internal port. Those links work only on the developer’s machine. Correct the application’s development base URL, proxy awareness, or asset configuration according to the framework’s documented process. Do not publish production secrets merely to make a temporary development URL work.

Security boundaries for a shared development site

A development application often exposes more information than a production deployment. Detailed exception pages, framework profilers, database inspectors, seed accounts, mail previews, source maps, and administrative tools are useful locally but risky on a public address. Treat the tunnel URL as internet-accessible even when it is intended for only one reviewer.

Be especially careful with development conveniences. An application that permits arbitrary file uploads, executes queued tasks, sends email, or reaches other systems can have effects beyond the visible browser session. Replace integrations with development-safe equivalents where the framework supports them, and verify that testing cannot contact real customers or modify production resources.

Troubleshooting FlyEnv and Localtonet together

FlyEnv opens, but the site does not

Confirm that every required component is running. A web server can be healthy while PHP is unavailable, or an application process can be running while its database is stopped. Review the relevant service and application logs available through the FlyEnv workspace. Verify the runtime version, project directory, document root, project startup command, and database configuration against the project’s actual requirements.

The local domain works, but the IP and port show another site

This commonly indicates name-based virtual-host selection. The web server uses the hostname to decide which site should answer. Verify the local listener, virtual-host configuration, and reverse-proxy design. Do not assume that changing the tunnel port will correct a hostname mismatch.

One practical design is to give the application a dedicated local HTTP listener that unambiguously reaches the intended project. The precise FlyEnv configuration depends on the web server and project, and the available evidence does not establish one universal sequence for creating that listener. Avoid inventing host-header or origin-rewrite settings in either product.

The tunnel is created, but the public address is unavailable

Check the tunnel lifecycle first. A saved configuration is not automatically active. The selected Localtonet client device must be connected, and the tunnel must have been started. If the client was closed, the computer slept, or connectivity was interrupted, restore the client connection and verify the tunnel status.

Next, retest the local IP and port from the client device. If Localtonet runs on another machine, remember that 127.0.0.1 refers to that other machine. Use an intentionally reachable local-network address and permit only the required local connectivity.

The public address returns a connection error

A connection error usually means that no compatible service is accepting traffic at the configured target, the application has stopped, the port is wrong, or the service listens on a different interface. Compare the tunnel target with the address recorded during local verification. Also confirm that an HTTP tunnel points to a working HTTP service rather than a database, raw TCP service, or HTTPS-only listener.

The page loads without styles or scripts

Inspect the generated asset URLs. If they point to localhost, myapp.test, a private address, or an unavailable port, a remote browser cannot retrieve them. Configure the framework’s public development URL or proxy behavior using its documented settings. Also verify that the asset-building process is running if the project compiles front-end resources.

Redirects return visitors to a local address

Applications frequently generate absolute redirects from a configured base URL or from their interpretation of proxy headers. Update the project’s development URL configuration for the temporary public address where appropriate. Because frameworks use different variables and trusted-proxy models, there is no safe universal environment-variable name to provide here.

The application reports database or cache failures

This is a local stack problem rather than a tunnel problem. Confirm that the required database or cache is running in FlyEnv, the application has the correct development credentials, and the schema or migrations have been prepared according to the project. Keep these backend ports private while diagnosing them.

The application works until the computer sleeps

The Localtonet public endpoint depends on the selected client being connected and the tunnel running. The FlyEnv services must also remain active. Sleep, shutdown, network changes, client termination, or stopped project services interrupt access. Restore the local stack first, verify it locally, and then confirm that our client and tunnel are connected.

Frequently asked questions