Build a working GoNavi database workspace first, then publish only a verified HTTP interface
GoNavi is a cross-platform database workbench built with Go, React, Wails, and the operating system's native WebView. This guide explains how to select an official release asset for Windows, macOS, or Linux, launch the desktop application, configure a database connection, and verify the workbench locally. We also cover the documented source-build path for developers. Finally, we show how to connect a confirmed GoNavi HTTP service to Localtonet without guessing its listening address, port, authentication mode, or startup command.
📋 What's in this guide
What GoNavi is and what this workflow accomplishes
GoNavi is a desktop-first database client designed to place connection management, querying, data inspection, editing, auditing, synchronization, and export workflows in one workbench. Its published documentation describes support for more than 30 data sources spanning relational databases, caches, message queues, vector databases, search systems, time-series platforms, and other specialized systems. Some data sources are built in, while others use optional driver agents.
The desktop application is built with Wails, using a Go backend, a React frontend, and the native WebView supplied by the operating system. That architecture matters during installation because GoNavi does not bundle the same browser runtime on every platform. Windows depends on the system-provided Microsoft Edge WebView2 Runtime, while Linux builds depend on WebKitGTK. macOS packages are distributed for both Intel and Apple Silicon systems.
GoNavi is primarily a desktop application, not a conventional web application that automatically begins listening on a predictable localhost port. The project also identifies MCP Streamable HTTP functionality and an experimental Web Server mode. Those capabilities can create a reason to use an HTTP tunnel, but the supplied project documentation does not establish a universal startup command, listening address, port, TLS setting, or authentication configuration for either mode.
For that reason, this guide separates the workflow into two deliberate phases. First, we install and verify GoNavi as a local database workbench. Second, if you intentionally enable a documented GoNavi mode that provides an HTTP endpoint, we verify that endpoint locally and then expose it with Localtonet. We do not assume that launching the desktop interface creates a remotely accessible service.
Prerequisites and decisions to make before installing
Start by identifying your operating system, processor architecture, and database target. You also need permission to install desktop software and any operating-system component that the selected build requires. If you are working on a managed device, confirm that the installation is allowed by your organization before downloading or running the application.
Choose the operating-system build
| Platform | Official release choice | Important dependency or limitation |
|---|---|---|
| Windows | Select the AMD64 .exe installer from the official release assets. |
GoNavi depends on the system-provided Microsoft Edge WebView2 Runtime. A missing runtime can cause a blank window or an immediate exit. |
| macOS on Intel | Select the AMD64 .dmg package. |
Published builds may not be Apple-notarized. Gatekeeper can block the first launch even when the package came from the official release page. |
| macOS on Apple Silicon | Select the ARM64 .dmg package. |
As with the Intel package, the first launch may require explicit approval through Finder if Gatekeeper blocks it. |
| Linux | Select a WebKitGTK build matching the distribution's available WebKitGTK generation. | Official releases include WebKitGTK 4.0 and 4.1 variants. The supplied evidence does not provide a universal package command or dependency command for every distribution. |
On macOS, you can check whether the machine uses Apple Silicon or an Intel processor from the system information shown by macOS. On Linux, check which WebKitGTK generation your distribution provides before choosing between the 4.0 and 4.1 release variants. Do not assume that the newest-looking filename is compatible with an older distribution.
Prepare a safe database target
For an initial test, use a local database, a development environment, or an approved staging system. GoNavi's quick-start guidance recommends starting with a local or staging database rather than using production as the first connection. Gather the database type, hostname or URI, port, authentication details, and any approved SSH or proxy settings.
Create a database account with only the permissions needed for the intended test. A read-only account is preferable when your immediate goal is to inspect schemas and run a harmless verification query. Do not reuse an unrestricted production administrator account merely to confirm that the workbench opens.
Use only the official project location
Download the application from the official GoNavi GitHub Releases page or begin from the project's official download page. Similar repository names, forks, search results, or repackaged installers are not equivalent to an official release asset. Review the release notes before upgrading or installing a newly published version.
Database passwords, SSH keys, API keys, connection export files, Localtonet device tokens, and private endpoint details are sensitive. Do not paste them into screenshots, terminal transcripts, support requests, public issue reports, or tunnel configuration examples. Use placeholders when documenting your setup.
Install GoNavi from official release assets
The normal end-user installation path is a platform-specific asset from GitHub Releases. The project does mention Docker, Kubernetes, Helm, and Podman-related packaging, but the supplied installation evidence does not provide enough verified commands and configuration details to teach those paths safely. This section therefore focuses on the documented desktop installation route.
Open the official release list
Visit the official GoNavi Releases page and open the release you intend to install. Prefer a current stable release unless your organization has standardized on a tested version. Read its notes for platform-specific warnings and upgrade considerations before downloading anything.
Select the asset that matches the platform
Choose the Windows AMD64 installer, the macOS AMD64 or ARM64 disk image matching the Mac's processor, or the Linux WebKitGTK 4.0 or 4.1 variant compatible with the distribution. Asset names can change between releases, so identify the file by platform, architecture, and WebKitGTK requirement rather than relying on a filename copied from an older guide.
Run the platform package
On Windows, run the downloaded .exe installer using your normal approved installation process. On macOS, open the .dmg and install the application through the standard Finder workflow presented by the disk image. On Linux, install or launch the downloaded release asset according to its package format and your distribution's normal package procedure. No single Linux command is given here because the available format and dependency handling can differ by release and distribution.
Resolve the documented runtime requirement if necessary
If Windows displays a blank window or GoNavi exits immediately, verify that Microsoft Edge WebView2 Runtime is installed. On Linux, confirm that the WebKitGTK generation required by the selected build is present. If macOS Gatekeeper blocks a trusted official package, verify the download source, then Control-click the application in Finder and select Open as documented for the release.
Launch GoNavi and confirm that the interface renders
Open the application and wait for the workbench to appear. Confirm that navigation, settings, and connection controls are visible and responsive. A correctly rendered interface establishes that the basic desktop package and native WebView dependency are functioning, but it does not yet prove database connectivity.
Windows installation notes
The Windows desktop build uses the Microsoft Edge WebView2 Runtime supplied by the system. Many current Windows installations already include it, but restricted intranet images or heavily customized systems may not. If GoNavi starts without a usable interface, verify this dependency before changing database settings or repeatedly reinstalling the application.
A WebView problem occurs before GoNavi can meaningfully test a database connection. Treat a blank application window and a database connection error as separate classes of failure. The former points toward the desktop runtime, while the latter usually concerns the database address, credentials, driver, network route, SSH configuration, proxy configuration, or server permissions.
macOS installation notes
GoNavi publishes separate AMD64 and ARM64 disk images. Selecting the native architecture avoids unnecessary compatibility assumptions. The release notes state that a macOS DMG can use an ad-hoc signature without Apple notarization, which means Gatekeeper may block the first launch.
Do not disable operating-system protections globally. First confirm that the package came from the official project release page. Then use the documented Finder action: hold Control, click the application, and choose Open. This provides an explicit approval path for the selected application without treating every downloaded application as trusted.
Linux installation notes
GoNavi's Linux builds are based on WebKitGTK, with separate 4.0 and 4.1 variants for different distributions. The correct selection depends on the libraries available on the target system. If the application does not launch, inspect the error output and verify that the release variant matches the installed WebKitGTK generation.
The supplied project material does not define a universal Debian, Ubuntu, Fedora, Arch, or other distribution-specific installation command. It would be unsafe to invent one because package names and dependency resolution vary. Use the package format supplied in the chosen release and your distribution's supported package tooling.
GoNavi describes its release installers as being around the 20 to 30 MB class, depending on the version and platform. That download size should not be interpreted as the application's memory footprint. Native WebView helper processes and the active workload affect runtime memory consumption.
Configure your first GoNavi database workbench
Once the application launches, the next task is to prove that it can reach an approved data source and provide a usable query or browsing workflow. GoNavi's quick-start path is to create a connection, select the database type, provide the required connection details, save the connection, and then open the query workspace or object tree.
Create a new connection
Open the connection creation interface in GoNavi. Choose the exact data-source type you plan to test. Do not substitute a merely similar protocol or database family unless the project documentation explicitly identifies it as compatible.
Enter the database address and authentication details
Supply the host or URI, port, and credentials expected by the database. Use the values issued by the database administrator or deployment configuration. Ports and authentication defaults differ among databases and installations, so this guide does not guess them.
Configure SSH or proxy settings only when required
GoNavi documents optional SSH and proxy connection settings. Use them only when they are part of the approved route to the database. Confirm the jump host, proxy address, credentials, and host-key expectations through your own infrastructure documentation.
Save and open the connection
Give the connection a clear environment-specific name, such as one that distinguishes local, development, staging, and production systems. Save it, then connect. If an optional driver agent is required for the selected data source, complete that documented driver setup before treating the connection as defective.
Browse objects or open the query workspace
Expand the available object tree or open the appropriate query interface. Confirm that the expected database, schema, tables, keys, topics, collections, or other source-specific objects appear. The available objects depend on both the data-source type and the permissions granted to the account.
Perform a low-risk verification operation
Run a read-only query or browse an object that is safe for the selected environment. Use syntax appropriate to your actual database rather than copying an unrelated SQL example. Verify that results are displayed and that no unexpected write operation, schema change, or long-running workload is introduced.
Teams should agree on connection naming, export handling, review conventions, and version alignment before sharing workflows. GoNavi includes an update checker, and new versions are distributed through GitHub Releases. When a team member reports different behavior, compare the installed GoNavi version, driver state, connection settings, and database permissions before assuming that the underlying database behaves differently.
A successful application launch does not validate query safety, transaction behavior, driver compatibility, or account permissions. Start with a local or staging data source and use a least-privilege account. Production access should follow your organization's normal approval, auditing, and change-control process.
Verify the installation before enabling remote access
Verification should proceed in layers. This makes troubleshooting faster and prevents a Localtonet tunnel from obscuring an underlying application problem. A tunnel can carry traffic to a working local endpoint, but it cannot repair a failed database connection, an incompatible WebView runtime, or a GoNavi service that was never started.
Layer 1: Verify the desktop application
Confirm that GoNavi launches repeatedly, renders its interface, accepts navigation input, and can open its settings or connection management screens. Restart it once to make sure the first successful launch was not a one-time installer action.
Layer 2: Verify database connectivity
Open the saved connection and confirm that GoNavi can authenticate. Browse the object tree or run a low-risk read-only operation. If authentication fails, compare the configured host, port, username, database name, SSH route, proxy route, and account permissions with the known-good database configuration.
Layer 3: Verify routine workbench behavior
Open a query workspace, inspect a result, and confirm that the output matches the selected data source. If your workflow involves exports, editing, synchronization, or optional driver agents, test those functions in a non-production environment before relying on them. Installation success alone does not validate every feature.
Layer 4: Verify an HTTP service separately
Remote browser or agent access requires a network service, not merely a visible desktop window. If you enable GoNavi's MCP Streamable HTTP interface or experimental Web Server mode, obtain the startup procedure, bind address, port, path, authentication behavior, and TLS expectations from the documentation for the exact installed version.
After starting that mode, use a local client appropriate to the service to connect through its loopback or local-network address. Confirm that the endpoint returns the expected response and that authentication is enforced where configured. Record the exact local IP address and port only in a protected configuration record.
The supplied project evidence does not establish a universal port, bind address, endpoint path, startup command, or default credential for GoNavi's MCP HTTP or experimental web mode. Do not select a familiar development port and assume that GoNavi uses it. Continue to Localtonet only after the installed GoNavi version displays or documents the actual listener details.
Optional developer path: build GoNavi from source
Most readers should use official release assets. Building from source is appropriate when you are developing GoNavi, reviewing changes, testing a branch, or producing an internal build under your own software supply-chain controls.
The documented development prerequisites are Go 1.21 or newer, Node.js 18 or newer, and the Wails CLI. The project pins the shown Wails installation command to version 2.11.0. You also need Git and the platform development dependencies required by Wails and the native WebView on your operating system.
go install github.com/wailsapp/wails/v2/cmd/wails@v2.11.0
git clone https://github.com/Syngnat/GoNavi.git
cd GoNavi
wails dev
The wails dev command starts the documented full hot-reload development workflow. When Go exports have not changed, the project also documents a faster development command:
node tools/wails-fast-dev.mjsFor a build, the documented commands are:
wails build
wails build -clean
Build artifacts are placed under build/bin. The project recommends a clean build before a release. Run the commands from the cloned GoNavi repository and review build output rather than assuming that an absent graphical window means the compilation succeeded.
Source builds introduce additional variables that release-asset users do not encounter, including compiler versions, Node.js dependencies, Wails tooling, platform SDKs, branch state, and uncommitted changes. If the objective is simply to use the database client, the official release package is the shorter and more reproducible route.
The repository contains files related to Docker, web-server, MCP-server, CLI, and deployment workflows. However, the supplied evidence does not establish the complete commands, environment variables, secrets, volume mappings, listening ports, or production requirements for those modes. This guide does not reconstruct a container deployment from filenames alone.
Expose a confirmed GoNavi HTTP endpoint with Localtonet
Use this section only after GoNavi is running an HTTP-based service and you have verified it locally. The regular desktop interface is not itself evidence of an HTTP listener. A Localtonet HTTP tunnel needs a local IP address and port reachable from the device running our client.
With Localtonet, our client establishes an outbound connection to a Localtonet relay server. This lets you expose the selected local service without configuring inbound router port forwarding, changing the router firewall, setting up a VPN, or requiring a public IP address. The public endpoint remains available only while the selected device is connected and the tunnel is running.
Confirm that HTTP is the correct tunnel family
| Local service | Appropriate Localtonet direction | Decision rule |
|---|---|---|
| GoNavi experimental Web Server using HTTP | HTTP tunnel | Use HTTP only after confirming the local listener, port, path, and access controls. |
| GoNavi MCP Streamable HTTP interface | HTTP tunnel | Confirm that the client consuming the MCP endpoint supports the resulting public HTTPS address and the configured authentication behavior. |
| GoNavi desktop window only | No HTTP tunnel target | A graphical desktop application is not automatically a web service. Enable a documented server mode first if one is required. |
| Direct database protocol | Potentially a raw port tunnel, not the GoNavi HTTP workflow | Exposing a database directly has different security and protocol requirements. Do not treat it as equivalent to publishing GoNavi's HTTP interface. |
The following sequence reflects the documented Localtonet workflow. Current relay choices, dashboard options, and availability can vary, so select values shown in your account rather than copying a hardcoded region or server code.
Install and run the Localtonet client
Install our client on the computer that can reach the verified GoNavi HTTP service. In a normal same-device setup, this is the computer running GoNavi. If the service runs on another machine, the Localtonet client device must be able to reach that machine over the local network.
Authenticate or select the client device
Use the device-specific authentication token associated with the intended Localtonet client. Treat the token as a secret. Do not place it in documentation, screenshots, shared scripts, public repositories, or support messages.
Select an available relay server
Choose an available server or region from the current Localtonet dashboard. Do not use a server code copied from an old tutorial because availability can depend on the current product configuration, client version, deployment, or plan.
Create an HTTP tunnel to the verified local target
Create an HTTP tunnel and enter the local IP address and port reported by the GoNavi server mode you already tested. For HTTP tunnels, select the available process type appropriate to your setup, such as Random Sub Domain, Custom Sub Domain, or Custom Domain. These process types serve the content at a public HTTPS address. Custom-domain DNS requirements must be checked against current Localtonet documentation before configuration.
Start the tunnel and test the assigned public URL
Creating the tunnel does not make it active. Press Start, then use the assigned public URL with the browser, MCP client, or other HTTP client appropriate to the GoNavi service. Confirm both expected success and expected authentication failure behavior.
Stop or delete the tunnel when access is no longer needed
Stop the tunnel after the remote session or integration test. Delete it if the endpoint is no longer required. The public endpoint works only while the selected client device is connected and the tunnel is running.
For current dashboard guidance, consult our Localtonet HTTP tunnel documentation. Use it to confirm fields and options presented by the current interface, especially if you plan to use a custom domain.
Test the tunnel in the correct order
Keep the local GoNavi endpoint open while starting the tunnel. First repeat the local test from the Localtonet client device. Next, start the tunnel and test its public address from a separate network or client. Finally, stop the tunnel and confirm that the public endpoint is no longer available.
If the public request fails while the local request succeeds, inspect the Localtonet device connection, tunnel state, local IP, local port, and selected protocol. If both requests fail, return to GoNavi and verify that its server mode is still running. Changing tunnel settings cannot make an inactive local listener respond.
Security practices for database and agent access
A GoNavi HTTP interface may sit close to database connections, schema information, query workflows, or AI-agent operations. Publishing it therefore requires more care than exposing a static demonstration page. Localtonet provides the public route to the selected local endpoint, but application authentication and database authorization remain separate responsibilities.
Review what a remote client can do after authentication. A connection that can draft or execute queries, inspect schema context, edit rows, export records, or invoke agent tools may have a much larger impact than a read-only status endpoint. Test denial cases as well as successful requests.
Do not expose the database itself merely because GoNavi cannot be reached in the expected way. Direct database tunneling changes the threat model and can make a privileged protocol publicly reachable. Keep the scope aligned with the intended HTTP service and follow your organization's access-control policies.
Localtonet provides connectivity to the configured target. It should not be described or used as a way to bypass network policy, identity controls, or database permissions. Keep application authentication enabled, apply least privilege, restrict access where supported, and stop unnecessary tunnels.
Troubleshooting installation, database, and tunnel failures
GoNavi opens to a blank window on Windows
Verify that Microsoft Edge WebView2 Runtime is installed and usable. This is especially relevant on managed intranet images. Restart GoNavi after resolving the runtime dependency. Do not begin changing database credentials until the application interface renders correctly.
macOS blocks the application
Confirm that the disk image was downloaded from the official release page and that its architecture matches the Mac. Because the package may not be Apple-notarized, Gatekeeper can block the first launch. Use Finder to Control-click the verified application and select Open. Avoid globally disabling Gatekeeper.
The Linux build does not start
Check whether the downloaded asset expects WebKitGTK 4.0 or 4.1 and compare that requirement with the libraries available on the distribution. Review terminal output or system logs for missing shared-library messages. Select the matching release variant rather than installing random compatibility packages without understanding the error.
GoNavi launches but the database connection fails
Recheck the database type, host or URI, port, account, password, database name, and any optional SSH or proxy settings. Verify that the database is reachable from the GoNavi machine through an approved network route. Confirm that the account is active and authorized for the requested database objects.
If the data source uses an optional driver agent, verify the driver state and compatibility. After an upgrade, compare drivers and connection settings before rolling back the entire application. A successful connection from a different tool does not prove that both tools are using the same route, TLS settings, proxy, or credentials.
The workbench connects but expected objects are missing
Confirm that you opened the intended database and schema. Missing objects may reflect account permissions rather than a rendering problem. Compare the account's grants with the expected scope and reconnect after an authorized administrator changes permissions.
There is no local HTTP port after launching GoNavi
This is expected if only the desktop application was launched. The standard desktop workbench should not be treated as an automatically available web server. Follow the exact documentation for the installed version's MCP Streamable HTTP interface or experimental Web Server mode. If that documentation does not specify a supported startup procedure, do not guess one.
The local HTTP endpoint does not respond
Confirm that the relevant GoNavi server mode is still running. Verify its reported listening address, port, and path. If it binds only to a particular interface, test from the same machine first. Review application output for startup, authentication, configuration, or bind errors before involving Localtonet.
The endpoint works locally but not through Localtonet
Check that the Localtonet client is connected on the correct device, the HTTP tunnel uses the exact verified local IP and port, and the tunnel has been started. Creating it is not enough. Confirm that the assigned public URL is the one being tested and that the GoNavi process remains active.
Also distinguish an application response from a network failure. An HTTP authentication rejection means traffic probably reached the service but the credentials or access policy were not accepted. A connection failure can indicate an inactive tunnel, disconnected client, incorrect target, stopped local service, or unreachable local-network host.
The tunnel stops working after a restart
Verify both sides of the lifecycle. The GoNavi HTTP service must be running, and the selected Localtonet client must be connected with the tunnel started. If either component is stopped, the public URL cannot reach the intended service. Do not assume that creating a tunnel permanently starts every local dependency.
An upgrade changes behavior
Record the previous and current GoNavi versions, then compare release notes, driver state, connection settings, and server-mode configuration. Teams should align on a common version before sharing workflows. If a rollback is considered, protect connection information and validate the result against a non-production database first.
Frequently asked questions
Does launching the GoNavi desktop app create an HTTP service automatically?
Not according to the evidence used for this guide. GoNavi is desktop-first. Its project materials separately identify an MCP Streamable HTTP interface and an experimental Web Server mode, but the normal desktop launch should not be assumed to open a network listener. Enable and verify a documented server mode before creating an HTTP tunnel.
What port does GoNavi use for MCP HTTP or Web Server mode?
A universal port is not established by the supplied documentation. Check the instructions and runtime output for the exact installed version. Use only the listening address and port that GoNavi explicitly reports or that you intentionally configure and verify locally.
Which GoNavi package should I install on macOS?
Choose the ARM64 .dmg for Apple Silicon or the AMD64 .dmg for an Intel Mac. Verify the processor architecture through macOS system information. If Gatekeeper blocks a package downloaded from the official release page, use the documented Control-click and Open workflow rather than disabling protections globally.
Why does GoNavi show a blank window on Windows?
A missing Microsoft Edge WebView2 Runtime is a documented cause, especially on restricted or customized Windows images. Verify that runtime first. A blank application window is a desktop runtime issue and should be resolved before troubleshooting database connectivity.
Which Linux GoNavi build should I choose?
Select the release variant matching the WebKitGTK generation available on the distribution. Official releases provide WebKitGTK 4.0 and 4.1 variants. Package formats and dependency commands can differ, so use the selected release's asset details and the distribution's normal package tooling.
Can I install GoNavi with Docker, Kubernetes, Helm, or Podman?
The project references additional packaging and deployment approaches, and the repository contains deployment-related files. However, the evidence available for this guide does not provide a complete verified procedure covering commands, environment variables, secrets, ports, storage, and production operation. We therefore document the official desktop release path and do not invent container instructions.
Should I use an HTTP or TCP tunnel for GoNavi?
Use an HTTP tunnel when the intentionally enabled GoNavi service speaks HTTP, such as a confirmed MCP Streamable HTTP or web interface. Do not choose raw TCP merely because an HTTP setup is incomplete. Direct database protocols are a separate use case with a different security model.
Does creating a Localtonet tunnel start it automatically?
No. Creating a tunnel and running it are separate lifecycle states. After configuring the HTTP target, press Start. The tunnel is available only while the selected Localtonet client device is connected and the tunnel is running.
Does Localtonet secure my GoNavi database permissions?
Localtonet provides connectivity to the local target you configure. Database authorization, GoNavi service authentication, query permissions, and organizational access policy remain separate controls. Use least-privilege database accounts, verify service authentication, and stop the tunnel when remote access is no longer required.
Connect your verified GoNavi HTTP service with Localtonet
Install and test GoNavi locally first. When its documented MCP HTTP or web mode is running on a confirmed local address and port, use our outbound tunnel workflow to provide a public HTTPS endpoint without inbound router port forwarding.
Get Started Free →
