Install Frontman in Vite and Share It with Localtonet

What Frontman adds to a Vite application

Frontman approaches AI-assisted frontend work from the rendered application rather than from source files alone. After its framework integration is installed, the development server provides a browser interface at the /frontman route. A user can open the running application, select an element, describe a change in plain English, and review the resulting source update while Vite reloads the page.

This runtime context is important for visual work. Frontman can work with information such as the live DOM, component tree, computed CSS, routes, source maps, and development-server logs. Instead of asking a coding tool to infer what a screenshot represents, a reviewer begins with the actual rendered component. That makes the workflow particularly relevant to copy corrections, spacing adjustments, color changes, layout fixes, responsive design review, and other focused frontend tasks.

The integration edits the existing codebase. It is not a detached website generator or an isolated mockup environment. A requested change can therefore affect files in the project that you are running. Treat the session like any other source-editing workflow: use version control, inspect the diff, run the project's normal checks, and obtain the required review before merging or deploying.

Supported Vite frameworks in this workflow

Prerequisites and pre-installation checks

Begin with an existing Vite project that already starts successfully. The official Frontman installer auto-detects React, Vue, or Svelte from the project's Vite configuration, so run it from the project root containing that configuration and the project's package metadata.

You also need a working Node.js and npm environment because the documented setup uses npx and npm run dev. The supplied Vite integration evidence does not establish one universal Node.js version for every supported React, Vue, Svelte, or SvelteKit combination. Use the Node.js version required by your project, its lockfile and package manager policy, and the versions declared by its dependencies. Do not substitute the separate Astro Node.js requirement for a Vite requirement.

Confirm that the original project works

Before installing Frontman, start the project with its existing development command. For the documented npm workflow, that command is:

npm run dev

Open the local address printed by Vite and make sure the application loads without a build failure. Stop the server before running the installer if your shell or project workflow requires the terminal. This baseline matters because it distinguishes a pre-existing Vite problem from an installation problem.

Protect the working state

Check the source-control status and either commit the current work or otherwise preserve a known-good copy. The installer is expected to integrate Frontman with the project, so file changes are normal. A clean baseline lets you identify exactly what installation changed and revert those changes if the integration does not fit the project.

If the repository uses a team-specific package manager, monorepo command, workspace filter, or wrapper script, follow that repository's established dependency policy. The evidence for this article explicitly documents the npm and npx commands shown below, but it does not establish equivalent commands for every alternative package manager or monorepo layout. Rather than guessing at substitutions, run the documented path in a compatible project or consult the project's maintainers for its approved command mapping.

Plan for AI provider configuration

Frontman's interface requires an AI model to perform editing tasks. Current product information describes support for connecting a preferred model through options such as Anthropic, OpenAI, or OpenRouter, and also describes bring-your-own-key behavior. Exact account, subscription, key, and provider settings can change independently of the Vite installer, so complete the prompts shown by your installed Frontman interface rather than copying an unverified credential layout.

Remote-access prerequisites

Localtonet should be added only after Frontman works locally. For the remote stage, install and run the Localtonet client on the same device as the Vite server, or on a device that can reach the Vite service. You will also need a Localtonet device/auth token and an available relay server selection from the current dashboard. Tokens identify client devices and must not be guessed, copied into this guide, exposed in screenshots, or shared with reviewers.

Install Frontman in the Vite project

The official Vite quickstart is deliberately short: run the Vite installer, start the development server, and open the Frontman route. Follow that order before making any Localtonet configuration. This keeps installation testing on the local machine and avoids diagnosing a framework integration and a public tunnel at the same time.

The installation command is:

npx @frontman-ai/vite install

After installation completes, start the project:

npm run dev

Then open:

http://localhost:5173/frontman

Review what the installer changed

Once the installer exits successfully, inspect the repository diff before beginning an editing session. Confirm that the changes belong to the intended Vite project and that no unrelated files were modified. Do not manually discard an integration file simply because it is unfamiliar. First understand whether Frontman needs it for browser, server, source-map, route, or middleware context.

The extracted official evidence establishes the installer command and framework auto-detection, but it does not provide a stable, exhaustive list of every file generated for every Vite framework and version. Such a list could become inaccurate as the integration evolves. The repository diff on your machine is therefore the reliable record of what this installation changed.

Verify the local Frontman interface

A successful command is not enough by itself. Verification should cover the Vite application, the Frontman route, framework detection, and one reversible editing task. Keep all of these tests local until they pass.

1. Verify the normal application route

Open the base Vite application using the address shown in the terminal. Confirm that the page renders and that navigation still behaves as expected. If the project was healthy before installation but now fails to compile, inspect the first meaningful error in the terminal rather than continuing to the tunnel stage.

2. Verify the Frontman route

Open http://localhost:5173/frontman when the server uses its documented default port. A functioning route should present the Frontman browser experience rather than the application's ordinary fallback page, a Vite connection error, or an HTTP not-found result.

If the browser cannot connect at all, return to the terminal and confirm that npm run dev is still active. If the application opens but /frontman does not, verify that the installer completed in this exact project and inspect the resulting file changes and startup messages.

3. Complete the provider prompt shown by Frontman

Follow the current interface to select or connect a supported model provider. Frontman cannot execute a requested source edit until an appropriate model is selected. Provider availability, account requirements, model names, and credential fields are outside the stable Vite installation sequence, so use the options actually shown in the installed interface.

4. Run a small reversible test

Choose a harmless element in a development branch, such as a piece of temporary copy or a non-critical spacing value. Select the rendered element, request one precise change, and watch for the application to refresh. Then inspect the repository diff to confirm that the expected source file changed.

A good verification request is narrow and observable. For example, ask to change a temporary heading to another clearly identifiable phrase. Avoid using the first test for a broad redesign, dependency upgrade, routing change, or cross-application refactor. The purpose is to verify the path from browser selection to source modification and Vite feedback.

5. Validate the result outside the Frontman view

Open the affected application route normally and check the change at the viewport sizes relevant to the project. Run the repository's established lint, type-check, test, or build commands if they exist. Those commands differ between projects and are not defined by the Frontman quickstart, so use the scripts already declared by your repository rather than inventing generic ones.

Use Frontman effectively during frontend review

Frontman is best suited to requests that can be grounded in a visible page and a specific rendered element. The more precisely the reviewer identifies the current problem and expected result, the easier it is to evaluate the generated change.

Select the smallest useful scope

Begin with the button, card, heading, empty state, or layout region that demonstrates the issue. State what is wrong, where it occurs, and what should remain unchanged. A request such as “increase the space between these two controls without changing the card padding” is easier to verify than “make this page look better.”

Use browser context for visual defects

Runtime inspection is especially useful when the source alone does not reveal why a style behaves incorrectly. Computed CSS may differ from an individual style declaration because of inheritance, specificity, responsive rules, component libraries, or design tokens. Component and source-map context can also help connect a selected DOM node to the source that produced it.

Keep each change reviewable

Request one coherent adjustment at a time and inspect the diff after each completed task. Smaller changes are easier to understand, revert, and discuss. They also reduce the chance that a simple visual request becomes an unrelated refactor.

Use normal version-control boundaries

Create an appropriate branch, maintain a clean baseline, and commit only after review. If several people are participating in a remote design session, designate one person to own the final diff and repository state. Browser convenience should not replace branch protection, required reviews, automated checks, or deployment controls.

Remember what a remote reviewer can influence

The Frontman interface is attached to a development environment with source-editing capability. A person who can interact with that interface may be able to initiate changes through the configured AI workflow. Sharing it is therefore materially different from sharing a static preview. Only invite people who are authorized to participate in the source-change process.

Share the working Vite server through Localtonet

Once local verification succeeds, an HTTP tunnel can make the same service reachable from outside the development machine. With Localtonet, our client establishes an outbound connection to a relay server. The tunnel then provides a public URL for the local HTTP target without requiring inbound router port forwarding, firewall changes, VPN setup, or a public IP address.

For the documented default Vite setup, the local target is the HTTP service on port 5173. The public reviewer uses the assigned Localtonet URL and appends /frontman when needed. If Vite selected another port, target that actual port instead.

For current dashboard details, consult our Localtonet HTTP tunnel documentation. Dashboard choices, available relay servers, and plan-dependent options should always be taken from the current product rather than inferred from an older screenshot or copied configuration.

Build the public Frontman address

Suppose the running tunnel assigns a public base URL represented here as https://your-assigned-public-url. The Frontman route would be:

https://your-assigned-public-url/frontman

This is an illustrative format, not a real endpoint. Always use the exact public URL assigned to your running tunnel. Do not publish the URL in a public repository, issue, chat room, or document unless unrestricted distribution is explicitly intended and authorized.

Why HTTP is the appropriate tunnel family

Vite and the Frontman browser route are HTTP services, so an HTTP tunnel matches this workflow. A raw TCP tunnel is not required merely because HTTP ultimately uses a TCP connection. File Server is also not appropriate because the goal is to forward a running web application, not publish a local folder. VPN Manager is a separate private mesh VPN feature and should not be confused with the HTTP tunnel used here.

Secure a remote Frontman review session

A development server often exposes more context than a production application. Frontman adds source-editing capabilities, and the app itself may contain test accounts, debug output, internal routes, source maps, or connections to development services. Remote access should therefore be deliberate, temporary, and limited to authorized participants.

Do not treat an unlisted URL as authorization

A hard-to-guess public address is not a substitute for an access policy. Share the endpoint only with approved participants and apply the access controls required by your organization. The supplied evidence does not establish one universal Frontman authentication configuration or one access-control option available on every Localtonet plan, so this guide does not claim that a specific protection is automatically present.

Limit what the development application can reach

Review the environment variables and backend connections used by the Vite process. A frontend development server can still be part of a larger system that reaches local APIs, staging resources, or privileged test services. Use least-privilege credentials and avoid running the session from an environment that has unnecessary production access.

Inspect prompts and generated changes

Do not put passwords, private keys, customer records, or unrelated proprietary information into an editing prompt. Frontman sends relevant context to the selected LLM provider to produce changes, so the provider and organizational data-handling policy matter. Use only providers and accounts approved for the code and context involved.

Troubleshooting installation, Vite, and remote access

The installer command fails

Confirm that the shell has access to a working Node.js and npm installation, that you are in the intended Vite project root, and that the project can resolve packages through its configured registry. Read the first actionable error instead of repeatedly rerunning the installer. If the repository enforces a particular package manager or workspace command, use the team's documented policy rather than guessing an equivalent command.

Also check whether the repository was already modified by an earlier partial installation. Use source control to understand the current state before retrying or reverting anything.

Frontman does not detect React, Vue, or Svelte

The installer detects the framework from the Vite configuration. Verify that you ran it in the directory containing the relevant Vite project, not at an unrelated parent directory or in a different workspace package. Confirm that the project has a valid Vite configuration and that the original development server starts without Frontman-specific assumptions.

npm run dev fails after installation

Compare the current error with the baseline run made before installation. Inspect the repository diff and dependency changes, then address the earliest compile or configuration error. Do not create a Localtonet tunnel until the server starts locally because a tunnel cannot repair a failed build or a process that is not listening.

Port 5173 is unavailable

Read the Vite terminal output. If Vite starts on another port, use that reported port for both local verification and the Localtonet target. If the project is configured to require a fixed port and startup fails, identify and stop the conflicting process or follow the project's approved port configuration. This guide does not prescribe an unverified Vite configuration key because behavior can depend on the installed Vite version and repository setup.

The application loads, but /frontman does not

Make sure the URL uses the same host and port as the running Vite server and includes the exact /frontman path. Confirm that the Vite installer completed in this project and restart the development process after installation. Check the browser console and terminal for route, compilation, middleware, or module errors.

The Frontman interface opens, but no edit can be submitted

Verify that a supported AI provider and model have been selected through the current interface. Current release behavior prevents message submission until a model is selected. If the provider requires a key or subscription, confirm that it is valid without printing or sharing the credential.

The Localtonet public URL does not open

Check the dependency chain in order. The Vite process must be running, the configured local IP address and port must be reachable from the Localtonet client device, the client must be connected with the intended device token, and the tunnel must have been started. Remember that merely creating the tunnel does not make it active.

Test the base public URL first, then append /frontman. If the base application fails too, focus on tunnel status and local reachability. If the base application works but Frontman fails, focus on the Frontman route and browser or server diagnostics.

The page opens remotely, but parts of the app fail

Inspect the browser's network and console panels. A frontend may call an API through a URL such as localhost. In a remote reviewer's browser, localhost refers to that reviewer's own computer, not the Vite host. Any dependent API needs a safe, intentional remote-access design of its own, or the application must use a reachable development endpoint.

Asset paths, host validation, cookies, cross-origin behavior, and live-update connections can also depend on the project's Vite version and configuration. Use the actual browser and terminal errors to guide changes. Do not disable host checks or broad security controls merely to make the page load. Confirm the documented setting for the exact installed version and apply the narrowest safe adjustment.

Hot reload behaves differently through the public URL

First confirm that local hot reload still works. Then check browser console and network errors from the public session. The initial HTTP page and the development update channel are related but not identical failure surfaces. Because version-specific Vite settings and proxy behavior are not established by the supplied evidence, this article does not invent a universal hot-module-reload configuration. A remote reviewer can still refresh after a change while the exact project configuration is investigated.

The tunnel stopped unexpectedly

Verify that the Localtonet client remains connected, the selected device is online, and the tunnel is still running. A Localtonet tunnel is available only while the chosen client device is connected and the tunnel has been started. Also verify that the Vite process did not exit because of a compilation failure or terminal closure.

A generated edit is incorrect

Stop and inspect the diff. Revert the unwanted change through the repository's normal version-control workflow, restore the application to a known state, and retry with a narrower request. Specify the selected element, intended result, constraints, and what must remain untouched. Do not keep layering corrective prompts over a diff you no longer understand.

A repeatable operating checklist

A consistent opening and closing routine makes remote Frontman sessions easier to audit and safer to repeat.

Before the session

• Update the intended development branch and confirm the working tree state.
• Start the Vite app locally and verify its normal routes.
• Open the local /frontman route and confirm the provider setup.
• Check that no production secrets or customer data are present in the test environment.
• Start the Localtonet client and select the correct connected device.
• Confirm that the HTTP tunnel points to the port reported by Vite.
• Start the tunnel and test the assigned public URL yourself before sharing it.

During the session

• Share the public URL only with authorized participants.
• Keep requests narrow, visual, and easy to verify.
• Inspect source changes after each meaningful task.
• Watch the Vite terminal, browser console, and repository diff for unexpected behavior.
• Avoid entering secrets or unrelated sensitive context into prompts.

After the session

• Review the complete diff and discard unintended changes.
• Run the project's established lint, type-check, test, and build workflows where applicable.
• Commit only approved files through the normal review process.
• Stop or delete the Localtonet tunnel.
• Stop the Vite development server when it is no longer needed.
• Rotate any credential immediately if it may have been disclosed.

Frequently asked questions