Build a local codebase index first, verify the dashboard, then make a deliberate remote-access decision
Repowise turns repository structure, dependencies, git history, tests, code-health signals, and engineering decisions into reusable codebase intelligence for developers and AI tools. This guide walks through the documented PyPI installation, repository initialization, server startup, and local dashboard verification before adding remote access. Because the published quick start does not establish a universal dashboard port, bind address, transport, or authentication default, we will obtain those details from the running instance instead of guessing them. Once the local endpoint is confirmed, we will show how to connect it to an HTTP tunnel with Localtonet while treating repository intelligence as sensitive information.
📋 What's in this guide
What Repowise provides and where remote access fits
Repowise is a self-hosted codebase-intelligence system. It indexes a repository so that developers, reviewers, and compatible AI tools can work with structured evidence instead of repeatedly rediscovering the repository through broad searches. Its documented analysis includes source structure, dependencies, call relationships, git history, ownership, tests, engineering decisions, code-health signals, dead-code information, and generated documentation.
The same index can support several workflows. A developer can inspect the repository through a local dashboard, while an MCP-compatible coding tool can request task-shaped context from Repowise. Change analysis can connect a proposed edit to callers, related files, tests, and historical co-changes. Code-health views can help identify risky or difficult-to-maintain areas. Generated documentation remains connected to indexed source evidence rather than operating as an unrelated documentation snapshot.
The installation covered here is the documented local PyPI path. It installs the repowise package, initializes Repowise inside an existing repository, builds the local index without optional generated prose, and starts the service. This is intentionally an installation-first workflow. A tunnel should never be used as a substitute for confirming that the underlying application starts correctly on the host.
Repowise supports both a dashboard and MCP functionality, but the supplied installation evidence does not establish that every interface uses the same path, port, or transport. This guide exposes only a locally verified browser endpoint. Do not assume that publishing the dashboard also publishes, configures, or secures an MCP transport.
Prerequisites and decisions to make before installation
Begin with a working local checkout of the repository you want Repowise to analyze. The documented initialization command is run from inside that repository, so choose the repository deliberately and confirm that your terminal is in its root directory before starting. Repowise analyzes repository content and history, which means the resulting index and dashboard may reveal architecture, dependencies, symbols, ownership patterns, decisions, and other development information.
The documented installation method uses pip. You therefore need a Python environment in which pip is available and allowed to install the package. The supplied official evidence does not specify a minimum Python version, supported operating-system matrix, required compiler packages, or a mandatory virtual-environment tool. We will not invent those requirements. If installation reports a Python-version or platform compatibility error, follow the requirement stated by that error or check the current Repowise packaging metadata before changing your environment.
A dedicated Python environment is generally useful for isolating command-line tools and their dependencies, but Repowise's extracted quick start does not mandate a particular environment manager. If your organization already standardizes on virtual environments, containers, or managed developer workstations, follow that policy. The important operational requirement is that the environment used to install Repowise must also be active when you run the repowise commands.
For the remote-access portion, install and run the Localtonet client on the same device as Repowise or on a device that can reach the verified Repowise listening address. You will also need a Localtonet device auth token and an available relay server selection from the current dashboard. Tokens are device-specific secrets. Do not place them in shell history, screenshots, repository files, tutorial notes, or public issue reports.
| Requirement | Why it is needed | How to verify it safely |
|---|---|---|
| Local repository checkout | Repowise initialization runs inside the repository being indexed. | Inspect the current directory and confirm it is the intended repository root before running the command. |
| Python environment with pip | The documented local installation uses pip install repowise. |
Confirm that pip is available in the environment where you intend to run Repowise. |
| Permission to install a package | The Repowise package and its declared dependencies must be installed. | Use an environment approved for developer tooling and avoid overriding system protections without understanding the effect. |
| Local browser access | The dashboard should be tested directly before a tunnel is introduced. | Open the exact URL reported by the running service from a browser that can reach the host. |
| Localtonet client and device token | The client establishes the outbound connection to our relay service. | Use the current Localtonet dashboard and keep the device-specific token private. |
| Approved exposure policy | A repository dashboard may contain sensitive engineering information. | Confirm authorization, authentication expectations, and the intended audience before creating a public endpoint. |
For an initial evaluation, use a repository that your organization permits you to index and inspect. Confirm where Repowise writes its generated state and how that state fits your backup, retention, and source-control policies before applying the workflow to proprietary or regulated code. The supplied quick-start evidence does not define those storage paths, so inspect the files created by your installed version rather than assuming a location.
Install Repowise and initialize a repository
The official quick start is concise: install Repowise from PyPI, enter the target repository, initialize the index with generated prose disabled, and serve the resulting application. Keep this sequence intact. Starting the service before initialization would skip the documented index-building step, while running initialization from the wrong directory could analyze the wrong project.
Install the Repowise package
In the Python environment selected for this installation, install the published package with the documented pip command:
pip install repowiseLet pip complete before continuing. Read any error output rather than adding unverified flags. If your system has several Python environments, confirm that the environment receiving the package is the one your terminal will use for the next commands.
Change into the repository to be indexed
Move into the root of the intended repository. Replace the placeholder path with the real local path:
cd /path/to/your/repoPause here and verify the directory. This command determines the context in which the next initialization runs.
Initialize Repowise without optional generated prose
Run the documented non-interactive initialization command:
repowise init --no-prose -y
The quick start states that this builds the graph, git, decisions, health, dead-code, and structural-wiki layers locally. The --no-prose option follows the documented no-API-key quick start by omitting optional model-written prose. The -y option is part of the official command and permits the documented initialization flow to proceed without interactive confirmation.
Allow initialization to finish and read its output. Indexing work can vary with repository contents, but no universal completion time or resource requirement is established by the supplied evidence. Avoid treating a lack of immediate dashboard output as a reason to rerun initialization in parallel. First determine whether the current process is still working or has reported an actionable error.
Repowise also documents that initialization wires Claude Code automatically. That behavior may be useful if Claude Code is part of your workflow, but it is not required for local dashboard verification. This article does not add guessed configuration for Cursor, Codex, VS Code, or other MCP hosts because their exact connection details can vary and are separate from publishing the browser dashboard.
Repowise describes its core graph, risk, health, test, dead-code, and review analysis as local and deterministic, with generated prose as an optional model-backed layer. The documented --no-prose initialization is therefore suitable for establishing the local index and dashboard without inventing model-provider credentials.
Start Repowise and verify it locally
A successful package installation does not prove that the repository was indexed correctly, and a successful initialization does not prove that the dashboard is reachable. Start the server from the initialized repository and use its own runtime output to identify the endpoint.
Start the Repowise service
From the initialized repository, run the documented server command:
repowise serveKeep this terminal visible. Startup messages are the best available source for the listening scheme, address, port, and any application-specific warnings produced by your installed version.
Record the actual listening details
Look for the URL or listening information printed by Repowise. Record the scheme, host or bind address, and port exactly as shown. The official quick-start excerpt confirms that a dashboard can be opened, but it does not provide a universal port or bind address, so this guide intentionally supplies no made-up default.
Open the dashboard locally
On a machine that can reach the Repowise host, open the exact runtime URL in a browser. If the service reports a loopback address, test it from the same machine first. Confirm that the page loads and represents the repository you intended to initialize.
Perform a functional verification
Navigate through the available repository overview, documentation, graph, health, or change-intelligence views exposed by your version. The goal is not merely to receive an HTTP response. Confirm that indexed content is present, repository identity is correct, and normal dashboard navigation works before introducing Localtonet.
Keep local verification separate from remote verification. If the dashboard fails locally, adding a tunnel will not repair the Repowise installation. It will only add another network layer to troubleshoot. Resolve indexing, startup, or browser errors at the local application first.
Identify the correct local endpoint without guessing
Localtonet HTTP tunnels need a local IP address and port that the Localtonet client device can reach. For Repowise, these values must come from the running process or current official documentation. The supplied Repowise quick start does not establish a fixed port, a fixed bind host, HTTPS support at the application, dashboard authentication, or a command-line option for changing the listener.
Start by classifying the URL you successfully opened. If the URL begins with http:// and renders the dashboard in a normal browser, an HTTP tunnel is the natural match. If Repowise reports a different transport or your deployment places a supported web server in front of it, configure Localtonet according to that verified endpoint instead. Do not select a raw TCP tunnel merely because every network service ultimately uses a port. HTTP tunneling is preferable for a confirmed web application because HTTP and File Server process types can provide a public HTTPS address through Localtonet.
| Observed local behavior | What it means | Next action |
|---|---|---|
A browser opens an http:// URL successfully |
You have confirmed a web endpoint and its actual host and port. | Use those verified values as the Localtonet HTTP tunnel target. |
| The URL works only on the Repowise host | The service may be listening on a loopback address, or another device may lack a route to it. | Run the Localtonet client on the same host, or consult current Repowise documentation for supported listener configuration. Do not invent a bind flag. |
| The process starts but prints no identifiable URL | The extracted quick start is insufficient to establish the endpoint. | Inspect current Repowise help or official documentation for that installed version before configuring a tunnel. |
| The browser cannot load the printed URL locally | The application is not yet verified, regardless of whether the process remains open. | Resolve the local application, port conflict, routing, or startup error before using Localtonet. |
| The endpoint requires authentication | Repowise or a surrounding access layer is protecting the dashboard. | Verify the authentication flow locally and retain it when remote access is added. |
| The endpoint has no visible authentication | Anyone who receives a public tunnel URL may be able to view repository intelligence. | Do not expose sensitive data until an appropriate access-control layer has been confirmed. |
Ports and listener behavior can change across versions or deployment modes. A copied default can target the wrong service, expose an unrelated local application, or create confusing gateway errors. Use only the endpoint that your Repowise process reports and that you have successfully tested.
Provide remote dashboard access with Localtonet
After Repowise works locally, Localtonet can expose the confirmed web service without inbound router port forwarding, firewall changes, VPN setup, or a public IP address. Our client establishes an outbound connection from the selected device to a Localtonet relay server. The HTTP tunnel then provides a public HTTPS address that forwards requests to the local target.
Creating a tunnel does not automatically mean it is running. The tunnel must be started, and it remains available only while the selected Localtonet client is connected and the tunnel is running. Keep that lifecycle in mind when diagnosing an address that previously worked but later became unavailable.
Install and run the Localtonet client
Install our client for the operating system on the device that can reach the verified Repowise endpoint. Running the client on the Repowise host is the simplest choice when Repowise listens only on a local address. Authenticate the device with its assigned token, keeping that token private.
Select the authenticated device
In the Localtonet dashboard, select the device identified by the auth token that will run this tunnel. Confirm that it is the device from which the Repowise dashboard is reachable.
Select an available relay server
Choose an available server or region shown in the current dashboard. Availability can vary, so obtain the current value from the product rather than copying a server code from an article.
Create an HTTP tunnel for the verified target
Create an HTTP tunnel and enter the local IP address and port that you confirmed while testing Repowise. Choose the required HTTP process type from the options currently available to you: Random Sub Domain, Custom Sub Domain, or Custom Domain. These process types serve the same local content at a public HTTPS address. Do not configure custom-domain DNS from guessed records; consult the current dashboard and documentation if you choose that option.
Start the tunnel and test the assigned address
Use the Start button, then open the assigned public URL from a separate browser or network. Confirm that the expected Repowise dashboard loads and that no unrelated local service appears. Stop or delete the tunnel when remote access is no longer required.
For the current product workflow and field descriptions, consult our Localtonet HTTP tunnel documentation. The dashboard remains the authority for available device, server, subdomain, and plan-dependent choices.
If Repowise runs on the same device as the Localtonet client, use the local endpoint that works from that device. If the client runs elsewhere, the target address must be reachable from the client across your local network. A URL that works only through the Repowise host's loopback interface will not automatically work from a different machine.
Security checklist for repository-intelligence access
A codebase-intelligence dashboard can expose considerably more than a typical status page. Depending on the indexed repository and enabled views, it may reveal file names, symbols, architecture, execution relationships, git history, ownership patterns, health findings, tests, documentation, and engineering decisions. Treat the tunnel URL and the underlying dashboard as access to development data, not as a harmless public preview.
Localtonet removes the need to open an inbound router port, but that does not remove the application's authorization requirements. A public URL is still publicly routable. Before sharing it, verify whether the Repowise version you installed provides authentication for the dashboard and whether that protection applies to every relevant route. The extracted official evidence does not establish a default dashboard authentication mechanism, so this article cannot promise one.
Localtonet HTTP process types provide a public HTTPS address, but transport protection does not decide who should be allowed to view the dashboard. Confirm application authentication or an approved protective layer before exposing proprietary repository intelligence. Do not rely on an unguessable-looking URL as the only control.
Avoid sharing screenshots that include the public URL, repository internals, device tokens, credentials, private endpoints, or sensitive error output. When requesting support, redact secrets while preserving the status codes and non-sensitive error details needed to understand the problem.
Routine operation and troubleshooting
Use a two-layer verification model
Treat Repowise and Localtonet as separate operational layers. First verify the application directly at its local URL. Then verify the tunnel at its assigned public URL. This separation makes most failures easier to classify.
- If the local URL fails, investigate Repowise startup, initialization, the selected repository, and the reported listener.
- If the local URL works but the public URL fails, investigate client connectivity, tunnel status, target address, target port, and device selection.
- If both URLs load but content is missing, investigate the Repowise index rather than the tunnel.
- If the wrong application appears, stop the tunnel immediately and correct the target port.
The repowise command is not found
Confirm that pip install repowise completed successfully and that the Python environment used for installation is active in the current terminal. Multiple Python installations can place command-line entry points in different locations. Do not repeatedly install into unrelated environments. Identify the environment selected by your shell and make the installation and execution context consistent.
Initialization was run in the wrong directory
Stop before serving or exposing the result. Return to the intended repository root and inspect what the mistaken initialization created. Because the supplied evidence does not specify every generated path or an official cleanup command, do not delete files based on assumptions. Use the installed version's current documentation or command help to determine the supported cleanup and reinitialization procedure.
Initialization reports an error
Read the first actionable error rather than only the final summary. Verify that the repository is accessible to the current user and that the Python environment meets the package's actual requirements. The evidence available for this guide does not define minimum memory, disk, Python version, repository-size limits, or language-specific system packages, so any exact remediation must be based on the error and the documentation for the installed release.
The service starts, but no dashboard URL is obvious
Do not guess a common development port. Review the startup output and the current help for repowise serve. If the installed version does not print an endpoint, use current Repowise documentation to identify its supported listener configuration. This is one of the cases where the available quick-start evidence is insufficient for a safe universal command.
The dashboard works locally but not through Localtonet
Confirm that the tunnel is started, not merely created. Verify that the selected Localtonet client is connected and can reach the exact target IP and port. If the client is on another device while Repowise listens only on the host's loopback address, move the client to the Repowise host or use a listener configuration explicitly supported by Repowise. Never invent a --host or --port flag.
The public URL returns a gateway or connection error
Reopen the local endpoint from the Localtonet client device. Check whether the Repowise process is still running and whether its listener changed after a restart. Confirm that the tunnel target contains the current port rather than an earlier value. Also verify that local endpoint security software or operating-system policy is not preventing the client process from connecting.
The wrong repository appears
Stop the public tunnel while investigating. Verify the working directory from which initialization and serving were performed. A functioning dashboard is not sufficient if it contains the wrong repository. Correct the Repowise instance locally, verify its identity again, and only then restart remote access.
Stopping and restarting access
The public endpoint is available only while the selected client is connected and the tunnel is running. Use the Localtonet dashboard to stop the tunnel when it is not needed and start it again for an approved access window. Delete the tunnel when the configuration should no longer exist. Repowise must also remain available at the configured local endpoint for forwarding to succeed.
| Symptom | Most useful first check | Avoid |
|---|---|---|
repowise is not found |
Confirm the active Python environment and completed pip installation. | Installing repeatedly into several unknown environments. |
| Local dashboard does not load | Read repowise serve output and test the exact reported URL. |
Creating a tunnel before local verification. |
| Public URL does not load | Confirm client connectivity, tunnel running status, and target reachability. | Changing Repowise and tunnel settings simultaneously. |
| Unexpected application is displayed | Stop the tunnel and verify the target port. | Leaving the endpoint online while investigating. |
| Repository content is incomplete | Review Repowise initialization and indexing output. | Treating an indexing issue as a network issue. |
| Dashboard has no confirmed authentication | Review access policy and add an approved protection layer. | Using URL secrecy as the only security control. |
Frequently asked questions
What commands are required for the documented local Repowise setup?
The documented quick start installs Repowise with pip install repowise, changes into the target repository, runs repowise init --no-prose -y, and starts the service with repowise serve. Run initialization and serving from the intended repository context.
What is Repowise's default dashboard port?
The supplied official quick-start evidence does not establish a universal dashboard port. Start Repowise, read the runtime output, and test the exact URL it reports. Do not copy a port from an unrelated installation.
Does the basic Repowise setup require an AI provider API key?
No API key is required for the documented core quick start using repowise init --no-prose -y. Repowise describes core analysis as local and deterministic, while optional generated prose is the model-backed layer.
Should I use an HTTP or TCP tunnel for the Repowise dashboard?
Use an HTTP tunnel when you have verified that Repowise provides a browser-accessible HTTP endpoint. This matches the dashboard workflow and gives you a public HTTPS address through Localtonet. Do not assume that the dashboard and every MCP transport share the same endpoint.
Does Localtonet require router port forwarding for this setup?
No. Our client establishes an outbound connection to a Localtonet relay server, so this workflow does not require inbound router port forwarding, firewall changes, VPN setup, or a public IP address.
Is the public HTTPS URL enough to secure a Repowise dashboard?
No. HTTPS protects transport to the tunnel edge, but it does not determine who is authorized to view repository intelligence. Confirm dashboard authentication or place an approved access-control layer in front of the service. The supplied Repowise evidence does not establish a universal authentication default.
Can the Localtonet client run on a different machine?
Yes, provided that the client device can reach the Repowise local IP address and port. If Repowise listens only on a loopback address, running the client on the same host is the straightforward option. Use only listener changes supported by current Repowise documentation.
Will the public URL remain available after I close the Localtonet client?
No. The tunnel is available only while the selected Localtonet client is connected and the tunnel is running. Repowise must also remain available at the configured local target.
Connect your verified Repowise dashboard with Localtonet
Install and verify Repowise locally first, identify the actual browser endpoint from its runtime output, and confirm an appropriate access-control policy. Then use our HTTP tunnel workflow to provide remote access without opening an inbound router port.
Get Started Free →
