Install Glance on Linux and Access It with Localtonet

What Glance is and how this installation works

Glance is a lightweight, highly customizable dashboard designed to display multiple information sources in a streamlined web interface. Its widgets can cover RSS feeds, subreddit posts, Hacker News, weather forecasts, YouTube uploads, Twitch channels, market prices, Docker container status, server statistics, releases, and custom data. Pages, columns, widgets, themes, and many widget-specific options are defined in YAML configuration files.

The project distributes precompiled binaries for Linux, Windows, and macOS across x86, x86_64, ARM, and ARM64 architectures. This tutorial uses the Linux binary instead of the project's recommended Docker Compose template. A binary installation is useful when you want a small deployment, already manage host processes directly, or do not want Docker solely for a dashboard.

The installation has two distinct networking stages. First, Glance runs as a local web service on the Linux machine. You must confirm that the process starts, accepts its configuration, and responds on the expected local endpoint. Second, the Localtonet client on that machine establishes an outbound connection to one of our relay servers. An HTTP tunnel then provides a public HTTPS address for the local Glance service without requiring inbound router port forwarding, firewall changes, a public IP address, or VPN setup.

Prerequisites and deployment decisions

Before downloading anything, confirm that the Linux machine can remain online whenever you expect the dashboard to be available. Both Glance and the Localtonet client must be running for remote access to work. Creating a tunnel configuration alone does not make the service permanently available.

You will need a Linux account that can run commands and write to the intended installation directory. The project suggests placing the binary in /opt/glance/. Creating or modifying that directory normally requires administrative privileges. The examples below use sudo where elevated access is likely to be required, but your distribution and account policy may differ.

You also need a download utility such as wget for the configuration template, an archive utility appropriate for the release format you download, and a browser or HTTP client for verification. For remote access, install and run the Localtonet client on the Glance host or on another device that can reach the Glance service over the local network.

Identify the Linux processor architecture

Glance release assets are architecture-specific. Do not choose an asset solely because it contains the word Linux. Check the architecture reported by the target machine:

uname -m

Common outputs include x86_64, aarch64, and ARM variants. Match that output to the architecture identified by the current Glance release. Asset names and packaging can change between releases, so this guide does not invent a permanent filename. Visit the current Glance release page and select the Linux archive that matches the machine on which the executable will run.

Choose where configuration will live

By default, the Glance binary looks for a file named glance.yml in the directory where the binary is placed. If the executable is stored at /opt/glance/glance, the simplest arrangement is therefore:

/opt/glance/
├── glance
└── glance.yml

Glance also supports an explicit configuration path through the --config option. The project documents this form:

/opt/glance/glance --config /etc/glance.yml

Either arrangement is valid for this workflow. Keeping the executable and configuration together is easier for a first installation. Using /etc/glance.yml can fit a host where configuration files are managed centrally. Choose one layout and use it consistently.

Install the Glance Linux binary

The exact release archive name is deliberately not hardcoded here. Glance supports multiple architectures, and the latest release can change after publication. Use the current release page, select the Linux asset matching the output from uname -m, and download it to the Linux machine.

The directory creation and installation can be performed with standard Linux tools. Run these commands from the directory containing the extracted executable named glance:

sudo mkdir -p /opt/glance
sudo install -m 0755 ./glance /opt/glance/glance

Confirm that the resulting file exists and has executable permissions:

ls -l /opt/glance/glance

Download and configure glance.yml

Glance reads its pages and widgets from YAML. The project provides a starting configuration that can be downloaded directly. To use the default same-directory behavior, save it beside the executable:

sudo wget -O /opt/glance/glance.yml https://raw.githubusercontent.com/glanceapp/glance/refs/heads/main/docs/glance.yml

If you chose the separate configuration layout, save the template to /etc/glance.yml instead and remember to launch the process with --config /etc/glance.yml.

YAML is indentation-sensitive. Use spaces consistently, preserve the parent-child structure, and avoid tab characters. A page contains columns, and each column contains one or more widgets. The following compact example uses the structure documented by the project:

pages:
  - name: Home
    columns:
      - size: small
        widgets:
          - type: calendar
            first-day-of-week: monday

      - size: full
        widgets:
          - type: hacker-news

      - size: small
        widgets:
          - type: weather
            location: London, United Kingdom
            units: metric
            hour-format: 12h

Replace the example location and widget choices with information appropriate for your dashboard. The project supports numerous widget-specific settings, so keep the downloaded template available as a practical starting point. For an initial test, resist the temptation to configure every feed at once. A smaller configuration makes syntax mistakes and upstream network failures easier to isolate.

Understand configuration-backed network activity

Many Glance widgets retrieve data from external services. The web interface can therefore start successfully even when an individual feed, DNS lookup, or upstream API fails. Separate dashboard availability from widget availability during troubleshooting. First confirm that the page itself loads. Then investigate any widget-specific errors.

Ad-blocking DNS services such as Pi-hole or AdGuard Home can also affect a widget-heavy dashboard. The Glance project identifies low DNS rate limits as a common cause of request timeouts because a page with many widgets can generate numerous lookups. If the dashboard opens but several external widgets time out, review the rate-limit settings of the DNS resolver used by the Glance host.

Start Glance and verify the local dashboard

Start Glance in the foreground for the first test. Foreground execution keeps startup and configuration messages visible, which is more useful than immediately hiding the process behind a service manager.

If glance.yml is stored beside the executable, run:

/opt/glance/glance

If the file is stored at /etc/glance.yml, run the documented explicit configuration form:

/opt/glance/glance --config /etc/glance.yml

Leave that terminal open. From a browser on the Linux machine, visit:

http://localhost:8080

For a command-line response check from the same host, use:

curl -I http://127.0.0.1:8080

A response confirms that an HTTP service is reachable at the address, but it does not prove that every widget is healthy. Open the full page in a browser and inspect the layout. Check that the expected page name appears, widgets render, and there are no obvious configuration errors in the Glance terminal.

If you want to test from another computer on the same LAN, use the Glance host's LAN address with port 8080, but only if Glance is listening on an interface reachable from that computer and the host firewall permits the connection. The supplied evidence does not establish a universal Glance bind-address setting for every release, so we do not guess one here. A successful loopback test is sufficient when the Localtonet client will run on the same Linux host.

Use a deliberate verification sequence

Connect the working Glance dashboard through Localtonet

Once Glance responds locally, an HTTP tunnel can make it reachable outside the LAN. The Localtonet client establishes an outbound connection to our relay infrastructure, so this workflow does not require inbound router port forwarding, firewall changes, a public IP address, or a VPN.

HTTP tunnels point to a local IP address and port that the selected Localtonet client device can reach. If the client runs on the Glance host, use the verified loopback target. If it runs on another machine, use a LAN address that is demonstrably reachable from that machine rather than copying 127.0.0.1. Loopback always refers to the device on which the client is running.

You can manage the tunnel from the Localtonet dashboard or REST API. For general product setup information, consult our Localtonet documentation. Exact custom-domain DNS instructions are intentionally not included because they must be checked against current documentation and the domain configuration shown in the dashboard.

Secure the Glance remote-access workflow

Remote access should be treated as an intentional publication decision, not merely a connectivity test. A dashboard can reveal server names, container information, private feed titles, release activity, market watchlists, custom API output, or other operational details. Examine the complete page from the perspective of an unauthenticated visitor before leaving a public tunnel running.

Keep credentials out of the dashboard and YAML

Never place a Localtonet device token in glance.yml. The Glance configuration and the Localtonet client identity serve different purposes and should remain separate. Likewise, avoid embedding sensitive upstream credentials directly in widgets unless the project's documented configuration method requires them and you can protect the resulting file appropriately.

Restrict filesystem access to configuration files containing sensitive values. Avoid committing them to a public version-control repository. When troubleshooting, redact tokens, passwords, private URLs, hostnames, and identifying dashboard content before sharing logs or screenshots.

Use the smallest necessary exposure window

For temporary access, start the tunnel only when needed and stop it afterward. Deleting a tunnel is appropriate when you do not intend to reuse it. Remember that stopping Glance while leaving the tunnel active does not create a working dashboard, but it can leave a public endpoint configured for a service that may later restart.

Understand HTTPS termination and the local hop

HTTP and File Server Process Types on our platform provide a public HTTPS address. The configured local target in this workflow remains the Glance HTTP listener at 127.0.0.1:8080. Running the Localtonet client on the same host keeps that local target on loopback. If the client runs on another LAN device, traffic to Glance crosses the local network, and you should account for the security of that network path.

Routine operation, startup, configuration changes, and updates

Run Glance under appropriate process supervision

Foreground execution is ideal for the first test but not usually sufficient for an unattended server. The Glance project notes that the binary can be placed in /opt/glance/ and started with the server through a systemd service. However, the supplied project evidence does not provide an authoritative unit-file definition, service user, restart policy, or hardening options. Those details affect security and reliability, so this guide does not invent a generic systemd unit and present it as an official Glance configuration.

If you create a service, base it on current Glance documentation and your distribution's service-management policy. Use the same command that already passed foreground testing, set an explicit configuration path where practical, choose a dedicated service identity if supported by your deployment, and verify restart behavior before relying on it.

Change the dashboard incrementally

Keep a known-good copy of glance.yml before significant edits. Add or change a small number of widgets at a time, restart or reload Glance according to the behavior of your installed release, and verify the result. If a change breaks startup, compare indentation and restore the last working file rather than debugging several unrelated modifications simultaneously.

Configuration changes do not require a Localtonet tunnel change when Glance continues to use the same reachable IP address and port. The HTTP tunnel forwards requests to the local service without interpreting the dashboard's widget layout.

Update the binary carefully

Before updating, read the release notes for the version you intend to install. Download the Linux asset for the same verified architecture, retain the current binary and configuration as a rollback copy, stop the running Glance process, replace the executable, and run the new version in the foreground first. Confirm local HTTP access and widget behavior before returning it to unattended operation.

Do not infer compatibility solely from the archive name. A project update can include runtime, dependency, configuration, or widget behavior changes. For example, release v0.8.5 included a change intended to bypass Reddit API restrictions and also updated Go and Alpine versions. That does not guarantee permanent Reddit widget behavior because upstream restrictions can change independently.

Coordinate Glance and tunnel availability

Troubleshooting Glance and Localtonet access

The binary does not execute

First inspect the exact error. A permission-denied message commonly indicates that the executable bit is missing or that filesystem policy prevents execution. Confirm permissions with:

ls -l /opt/glance/glance

An execution-format error commonly points to an architecture mismatch. Run uname -m again and compare it with the asset selected from the release. Re-download the correct Linux build rather than trying to modify an incompatible binary.

Glance cannot find glance.yml

When no explicit option is supplied, the binary looks for glance.yml in the directory where it is placed. Confirm that the file is really named glance.yml, not glance.yml.txt, and that it is readable. If you store it elsewhere, use:

/opt/glance/glance --config /etc/glance.yml

Avoid relying on an uncertain working directory. An absolute binary path and explicit configuration path make troubleshooting clearer.

Glance reports a YAML or configuration error

Check indentation first. YAML hierarchy is represented with spaces, and a widget must remain nested beneath the appropriate widgets, column, and page entries. Remove the most recent edits or temporarily return to the downloaded template. Once the process starts, reintroduce customizations in small groups.

Port 8080 does not respond

Confirm that Glance remains running in the terminal. If it exited, use the startup output to diagnose the failure. Check whether another program is already using the port:

ss -ltn | grep ':8080'

A matching listener does not prove that Glance owns the port. If another application is already using it, consult the current Glance configuration documentation before changing the listening port. The supplied evidence establishes the documented port-8080 examples but does not establish a specific port-setting key for the binary, so no guessed YAML option is provided here.

The page loads but widgets time out

Treat this as a widget data problem rather than a basic web-server failure. Verify outbound connectivity and DNS resolution from the Linux host. If the network uses Pi-hole, AdGuard Home, or another ad-blocking DNS service, inspect its rate limiting. A page containing many widgets can exceed a low default DNS request limit. Also consider upstream service outages or API restrictions that Glance cannot control.

Glance works locally but the public URL does not

Confirm each layer separately:

1. Glance still responds at http://127.0.0.1:8080 from the host.
2. The Localtonet client is connected.
3. The tunnel is assigned to that same client device.
4. The tunnel target contains the correct local IP address and port.
5. The tunnel has been started, not merely created.
6. You are testing the currently assigned public URL or host.

If the Localtonet client is on a different device, do not use 127.0.0.1 as the target. From that device, loopback refers to the client device itself, not the Glance server. Verify Glance through its reachable LAN address before placing that address in the tunnel configuration.

The public page opens but looks incomplete

Compare it with the local page. If the same widgets fail locally, troubleshoot Glance, DNS, or the upstream source. If only the remote browser has a problem, inspect browser behavior and verify that the page is being opened through the assigned HTTPS address. Avoid changing several tunnel and Glance settings at once because that makes it harder to identify the failing layer.

Frequently asked questions