Run an observability dashboard on your own infrastructure, verify it locally, and make the web interface available through a controlled public endpoint
Monoscope is an open-source observability platform for ingesting and exploring logs, traces, and metrics stored in S3-compatible storage. This guide follows the project's documented Docker Compose quick-start workflow, explains how to verify the dashboard at its local endpoint, and covers practical startup and troubleshooting checks. After the local deployment works, we connect its web interface to a Localtonet HTTP tunnel without requiring inbound router port forwarding, firewall changes, a VPN, or a public IP address. The telemetry endpoint is treated separately because the available project evidence does not establish that it should be exposed as an ordinary HTTP web service.
📋 What's in this guide
What this Monoscope deployment looks like
Monoscope is an open-source observability platform that brings logs, traces, and metrics into a unified interface. Its documented capabilities include OpenTelemetry ingestion, live tailing, correlated telemetry views, natural-language queries, scheduled AI agents, dashboards, anomaly detection, and email reports. In a self-hosted deployment, you manage the compute environment and provide the S3-compatible storage used for telemetry data.
The official quick start uses the project's Git repository and its supplied Docker Compose definition. The documented sequence is intentionally short: clone the repository, enter the new directory, run docker-compose up, and open http://localhost:8080. The initial documented sign-in credentials are admin and changeme.
This guide keeps installation and remote access as two separate phases. First, we establish that Monoscope starts and that its web dashboard is reachable from the host itself. Only then do we introduce Localtonet. That separation matters because a tunnel cannot repair a failed application, an unavailable container, or a service listening on the wrong local address.
http://localhost:8080 after the Docker Compose stack has started successfully.
Dashboard traffic and telemetry ingestion are different
The documented browser interface uses port 8080. The Monoscope material also identifies http://localhost:4317 as an OpenTelemetry endpoint. Port numbers alone do not establish the application protocol, however, and OpenTelemetry deployments commonly distinguish between transport types and collector configurations.
The evidence available for this guide does not establish whether every supported Monoscope deployment expects ordinary HTTP, HTTP-based OTLP, or native gRPC behavior on port 4317. We therefore do not configure that endpoint as an HTTP tunnel or claim that the dashboard tunnel can carry telemetry ingestion. This tutorial exposes only the confirmed browser dashboard on port 8080.
The workflow below covers the repository's documented Docker Compose quick start and remote access to the web dashboard. It does not invent an S3 provider configuration, production orchestration model, OpenTelemetry transport, TLS setting, or Monoscope credential-change procedure that is not established by the supplied project evidence.
Prerequisites for self-hosting Monoscope
Use a machine where you are authorized to install and run containers. It must have enough storage and compute capacity for the amount of telemetry you intend to collect, although the available project evidence does not specify universal minimum CPU, memory, or disk requirements. Observability workloads can vary substantially with event volume, retention, query frequency, and the services enabled in the Compose stack, so a responsible production capacity plan must be based on your own workload rather than an invented minimum.
The documented quick start requires Git and a Docker environment that provides the hyphenated docker-compose command. Confirm that both commands are available before cloning the repository:
git --version
docker-compose --version
If either command is unavailable, install it using the instructions for your operating system and Docker distribution. Some newer Docker installations use a different Compose command form, but the Monoscope quick start supplied for this article explicitly documents docker-compose up. We retain that verified syntax rather than substituting an unverified command.
| Requirement | Why it is needed | What to verify |
|---|---|---|
| Git | Downloads the official Monoscope repository and its Compose files. | The git --version command completes successfully. |
| Docker environment | Runs the containers defined by the project. | Your Docker service or desktop application is running and authorized to start containers. |
| Docker Compose | Starts the repository's multi-container stack. | The documented docker-compose command is available. |
| Available TCP port 8080 | Provides the documented local web dashboard. | No unrelated service is already occupying the required host port. |
| S3-compatible storage planning | Monoscope uses S3-compatible buckets for telemetry storage. | You understand which storage service, credentials, retention policy, and access controls your deployment will use. |
| Localtonet client | Creates the outbound connection used for remote dashboard access. | Install it later on the Monoscope host or another device that can reach the dashboard. |
Choose where the Localtonet client will run
The simplest topology is to run our client directly on the machine where http://localhost:8080 works. In that arrangement, the tunnel's local target can use the loopback address and port 8080. The Localtonet application establishes an outbound connection to our relay, so this workflow does not require an inbound router rule, a public IP address, firewall modification, or VPN setup.
You may instead run our client on another device that can reach the Monoscope host over your local network. In that case, 127.0.0.1 would refer to the client device itself, not the Monoscope server. The tunnel target must therefore use a local network address that is reachable from the device running our client. Test that address from the client device before creating the tunnel.
Plan authentication before publishing anything
The quick start identifies admin/changeme as the default sign-in. A credential that is documented publicly should be treated as an initial bootstrap value, not a safe remote-access secret. The supplied evidence does not establish the exact supported process for changing Monoscope credentials, so this article does not invent an environment variable, configuration file, or dashboard control.
Verify the current Monoscope-supported credential and authentication configuration for the version you deploy, replace the documented default before enabling remote access, and test the new sign-in locally. If you cannot confirm and apply a supported credential change, keep the dashboard local rather than publishing it with known default credentials.
Install and start Monoscope with Docker Compose
The following steps preserve the order in the project's quick start. Run them from a terminal on the machine that will host Monoscope. Do not download similarly named repositories or compose files from unofficial locations.
Clone the official Monoscope repository
Use Git to download the project source and the supplied Docker Compose definition:
git clone https://github.com/monoscope-tech/monoscope.git
This creates a directory named monoscope in the current working directory. A failed clone must be resolved before continuing because the remaining commands depend on files from this repository.
Enter the repository directory
Change the terminal's working directory to the newly cloned project:
cd monoscopeRun the startup command from this directory so Docker Compose can find the project's configuration.
Start the Monoscope stack
Start the services using the command documented by the project:
docker-compose upDocker may need to retrieve or build components during the first startup. Keep the terminal open and watch its output. Do not proceed to remote access merely because the command was accepted. Wait until the stack has finished its initial startup and the dashboard can be tested locally.
The quick start does not document an additional mandatory command between cloning the repository and running the Compose stack. It also does not provide, in the evidence supplied for this guide, a universal production S3 configuration recipe. Do not guess bucket names, access keys, regions, endpoints, or environment variables. Review the configuration supported by the exact Monoscope version you intend to operate before sending important telemetry or treating the deployment as production-ready.
What to watch during the first startup
Terminal output is the first place to detect image download failures, build errors, missing configuration, host port conflicts, and containers that repeatedly exit. A successful invocation of Docker Compose does not guarantee that every service remains healthy. Allow the initial process to settle, then perform the browser verification described below.
If you interrupt the foreground Compose process before testing, the services may stop. Keep it running while completing the initial verification. For longer-term operation, choose a process supervision or container startup policy appropriate to your environment, but do not assume that the one foreground quick-start command alone creates a production service that automatically survives reboots.
Verify the Monoscope dashboard locally
Local verification establishes whether the application works independently of Localtonet. On the Monoscope host, open the documented address:
http://localhost:8080You should reach the Monoscope web interface. The quick-start credentials documented by the project are:
Username: admin
Password: changemeUse those credentials only for an initial local bootstrap check. Before any public tunnel is started, apply a credential change through a method supported by the exact Monoscope version you deployed. Because that method is not established in the supplied evidence, it must be confirmed rather than guessed.
A meaningful local verification checklist
Do more than confirm that a browser displays some content. Verify that the page loads from localhost:8080, that the expected sign-in interface appears, and that authentication succeeds locally. Navigate enough of the dashboard to confirm that the application is responsive rather than returning a partial static page while backend services fail.
Continue watching the Compose terminal during this test. Repeated container restarts, database exceptions, storage errors, or authentication failures require investigation even if the initial page loads. A web interface can be reachable while one of its dependent services is unavailable.
If http://localhost:8080 does not work on the host, stop here. Fix Monoscope first. Creating, deleting, or changing a Localtonet tunnel cannot make an unavailable local service healthy.
Optional test telemetry
Monoscope documents CLI commands that can populate the dashboard with sample telemetry after CLI authentication. The documented sequence first signs in through the CLI, then sends either a single event or a generated trace load:
monoscope auth login
monoscope send-event -m "Hello from Monoscope"
monoscope telemetrygen --kind=trace --rate=5 --count=50These commands require the Monoscope CLI to be installed and authenticated. CLI installation is not required merely to verify that the self-hosted web dashboard responds, and the supplied quick-start evidence does not fully document how the CLI selects a self-hosted server during authentication. Do not assume it targets your local deployment automatically. Confirm its endpoint and authentication context before sending test or production data.
Do not use port 4317 as a browser test
A failed attempt to browse to port 4317 does not prove that telemetry ingestion is broken. An ingestion endpoint can use a protocol that does not present a human-readable browser page. Conversely, the fact that port 4317 accepts a connection does not prove that a particular OpenTelemetry exporter is configured correctly.
Keep the tests distinct: use port 8080 for the confirmed Monoscope web dashboard, and validate telemetry exporters against the transport and endpoint requirements documented for the specific Monoscope and OpenTelemetry configuration you adopt.
Operate and maintain the self-hosted stack
Self-hosting means you are responsible for the compute environment, storage integration, upgrades, backups, availability, and access policy. The short quick start is suitable for reaching an initial running state, but it should not be mistaken for a complete production operations plan.
Understand the foreground startup behavior
The documented docker-compose up command attaches the terminal to the Compose application. This is helpful during installation because logs remain visible. Closing or interrupting that session can stop the stack, depending on how the process is terminated.
Before relying on Monoscope for production incident response, define how the stack starts after a host reboot, how operators inspect service failures, and how the environment is monitored. The available Monoscope evidence does not specify one mandatory production supervisor or orchestration platform, so this guide does not prescribe one.
Treat telemetry storage as a production dependency
Monoscope's self-hosted model uses S3-compatible storage. Protect the associated credentials with the same care as other infrastructure secrets. Grant only the permissions required by the deployment, avoid embedding secrets in scripts or public repositories, and restrict administrative access to the bucket.
Storage retention and recovery should be deliberate. Decide how long logs, traces, and metrics must remain available, how storage growth will be monitored, and how accidental deletion or credential loss will be handled. Validate restoration procedures rather than assuming that the existence of an object bucket automatically provides a complete backup strategy.
Pin and test upgrades deliberately
A clone of the default repository branch can change over time. Before upgrading an established environment, identify the version currently running, read the relevant release notes, preserve configuration and data needed for rollback, and test the new version away from critical telemetry where possible.
Avoid pulling arbitrary changes directly into a production deployment and immediately restarting it. Changes can affect configuration, storage schemas, authentication, dashboards, or integrations. A tunnel only forwards traffic to the service you run; it does not make an application upgrade reversible.
Stop remote access independently when needed
A Localtonet tunnel can be stopped without deleting the Monoscope deployment. This is useful during maintenance, credential rotation, upgrades, or incident response. Stopping the tunnel removes the public route while leaving you free to test the dashboard locally.
Deleting a tunnel is different from stopping it. Stop it when you expect to reuse the configuration, and delete it when it is no longer needed. Creating a tunnel also does not start it automatically. It becomes available only after you press the Start button and while the selected client device remains connected.
Expose the Monoscope web UI through Localtonet
Begin this phase only after the dashboard works locally and the documented default credential has been replaced through a supported Monoscope configuration method. Our HTTP tunnel should target the confirmed web service on port 8080, not the uncertain telemetry endpoint on port 4317.
The Localtonet client creates an outbound connection to a Localtonet relay server. The resulting tunnel supplies a public HTTPS address for the local dashboard. The tunnel remains available only while the selected client or device is connected and the tunnel is running.
Install and run the Localtonet client
Install our client on the Monoscope host or on another device that can reach the host's dashboard. Keep the client running because it establishes the outbound connection used by the tunnel. Obtain current installation instructions from the Localtonet application or documentation for your operating system rather than using an unverified command.
Authenticate and select the client device
Use the device-specific authentication token associated with the client that will run the tunnel. Treat the token as a secret. Do not paste it into documentation, screenshots, source repositories, support posts, or shell history shared with other people.
Select an available relay server or region
Choose from the currently available values shown by our platform. Server codes and regional availability can change or vary, so this guide does not hardcode a relay value.
Create an HTTP tunnel for the local dashboard
Select the HTTP tunnel family and point it to the address that the Localtonet client can use to reach Monoscope. If our client runs directly on the Monoscope host, use the loopback target 127.0.0.1 with port 8080. If it runs on another LAN device, use a reachable address for the Monoscope host instead of loopback.
Start the tunnel
Creating the tunnel does not make it active. Press the Start button, then wait for the tunnel and its selected device to show a connected state. HTTP tunnels can use a generated subdomain, a selected subdomain where supported, or a custom domain. Consult the current dashboard and documentation before configuring custom-domain DNS because exact requirements are not established here.
Test the assigned public HTTPS address
Open the public URL from a network other than the Monoscope host's local network when possible. Confirm that the sign-in page appears, authenticate using the replacement credentials, and navigate the dashboard. Stop the tunnel immediately if the default password still works, an unexpected application appears, or authorization does not behave as intended.
For current interface details, refer to the Localtonet documentation. The dashboard is the authoritative place to obtain current relay choices and options available to your account. Do not assume that every protocol, domain option, region, or capability is included in every subscription plan.
Choose the correct local target
| Client location | HTTP tunnel target | Required verification |
|---|---|---|
| Directly on the Monoscope host | 127.0.0.1:8080 |
The host can open http://localhost:8080. |
| Another device on the same LAN | Reachable Monoscope host address on port 8080 |
The client device can open that exact address before tunneling. |
| Inside a separate container | A container-reachable host or service address on port 8080 |
Test from the Localtonet client's own network namespace, not only from the host. |
A loopback address always refers to the machine or network namespace where the connecting process runs. If Monoscope works at localhost:8080 in the host browser but our client runs inside an isolated container, the client's 127.0.0.1 may point to that container rather than the host. Use a topology-specific reachable address and verify it before changing tunnel settings repeatedly.
Security practices for a remotely accessible observability dashboard
Observability data can reveal service names, request paths, error messages, infrastructure relationships, user activity, and operational failures. A dashboard should therefore be treated as an administrative system, not as a harmless public website.
admin/changeme credentials remain valid. Use only a credential-change method supported by your Monoscope version.
8080. Do not expose storage services, internal databases, container management interfaces, or the uncertain port 4317 endpoint through the same workflow.
A tunnel is not an authorization layer for Monoscope
Localtonet provides connectivity from a public endpoint to the selected local target. It does not justify leaving application credentials unchanged or granting every user administrative access. Monoscope remains responsible for its own sign-in and authorization behavior, while you remain responsible for account management and safe configuration.
Do not frame the tunnel as a way to bypass organizational controls. Obtain authorization before exposing an internal observability system, follow your network and data-handling policies, and restrict access according to the sensitivity of the telemetry.
Keep the ingestion path separate
Dashboard access and telemetry ingestion have different clients, protocols, threat models, and availability requirements. A browser uses the web interface, while an OpenTelemetry exporter sends structured telemetry using its configured transport.
If remote applications must send data to Monoscope, determine the exact transport expected by the deployed version, whether TLS is required, how clients authenticate, and whether a raw TCP, TLS, or HTTP tunnel is technically appropriate. Do not infer those answers from the port number. This guide intentionally makes no tunnel recommendation for port 4317 because the evidence does not establish enough detail.
Before starting the tunnel, confirm that default credentials no longer work, sensitive secrets are not displayed in the dashboard, storage credentials use least privilege, and only the intended web port is targeted. Stop the tunnel while investigating any uncertainty.
Troubleshoot installation and tunnel problems
The repository does not clone
Confirm that Git is installed, the host has outbound network access, and the repository URL was entered exactly. Also confirm that the current directory is writable and that a conflicting nonempty monoscope directory is not causing confusion. Do not replace the official repository with an unofficial archive simply to work around a transient network failure.
docker-compose is not recognized
The documented quick start assumes that the hyphenated command is available. Verify your Docker and Compose installation. Docker packaging differs among operating systems, and this article does not substitute a different command without project evidence. Once docker-compose --version succeeds, return to the repository directory and run the documented startup command.
Docker Compose cannot connect to Docker
Ensure that the Docker service or desktop application is running and that your user is authorized to access it. This failure occurs before Monoscope can start, so changing dashboard ports or Localtonet settings will not help.
Port 8080 is already in use
Another process may already own the host port required by the documented dashboard endpoint. Identify whether the page at localhost:8080 belongs to Monoscope before proceeding. Stop or reconfigure the conflicting service according to its own documentation.
The supplied evidence does not document a supported Monoscope port-remapping procedure, so this guide does not invent a Compose edit or environment variable. If you intentionally change the published dashboard port using current Monoscope documentation, use that resulting host port consistently for local verification and as the Localtonet target.
The browser cannot open localhost:8080
Check whether the Compose process is still running and review its terminal output for a container that exited or failed during initialization. Make sure the URL uses HTTP and port 8080. Test from the host itself first. A request from another computer introduces additional variables such as host binding, LAN routing, and firewall policy.
Do not create the tunnel until local access works. If the local service is unavailable, the public endpoint will have no healthy application to forward requests to.
The local dashboard works but the public URL does not
Confirm that the Localtonet client is connected, the correct device token was selected, and the tunnel was explicitly started. Then verify the local target from the device running our client. If the client is on the Monoscope host, test 127.0.0.1:8080. If it is elsewhere, test the Monoscope host's reachable LAN address from that client device.
Also confirm that the tunnel family is HTTP and that it targets the dashboard rather than port 4317. A created but stopped tunnel has no active public route, and a disconnected client cannot carry traffic.
The public URL displays the wrong application
Stop the tunnel immediately and check which process owns the selected local address and port. The tunnel forwards to the target you configure. If another application is listening there, that is the application the public endpoint can display.
The dashboard loads but sign-in fails
First test the same credentials locally. If local authentication also fails, troubleshoot Monoscope's account configuration rather than the tunnel. If local authentication works but remote authentication fails, compare the exact URL, browser session, and application behavior while reviewing Monoscope output for rejected requests.
Do not restore the public default password as a troubleshooting shortcut. Keep the tunnel stopped until secure authentication works consistently.
The tunnel worked and later became unavailable
Check both sides of the dependency chain. Monoscope must still be running and reachable on its local address, and the selected Localtonet device must remain connected with the tunnel running. A host reboot, stopped foreground Compose process, disconnected client, or manually stopped tunnel can interrupt access.
Test locally first, then test from the Localtonet client device, and finally test the public URL. This order identifies the boundary where connectivity fails without changing several configurations at once.
Frequently asked questions
What is the documented local URL for Monoscope?
The documented web dashboard is http://localhost:8080. Verify this address on the Monoscope host before creating a Localtonet tunnel. If the dashboard does not work locally, resolve the application or container problem first.
What are the initial Monoscope credentials?
The quick start documents admin as the username and changeme as the password. Use them only for an initial local bootstrap check. Replace the default through a method supported by your exact Monoscope version before making the dashboard remotely accessible.
Which Localtonet tunnel type should I use for the dashboard?
Use an HTTP tunnel for the documented web dashboard on port 8080. If our client runs on the Monoscope host, target 127.0.0.1:8080. If it runs on another device, target an address for the Monoscope host that is reachable from that device.
Should I expose Monoscope port 4317 with the same HTTP tunnel?
Not based on the evidence available for this guide. Port 4317 is identified as an OpenTelemetry endpoint, but the supplied documentation does not establish whether every relevant deployment expects ordinary HTTP or native gRPC behavior there. Confirm the exact transport, authentication, and TLS requirements for your Monoscope version before selecting any tunnel type.
Does creating a Localtonet tunnel make it active immediately?
No. After creating the configuration, you must start the tunnel. The selected Localtonet client must also remain connected. You can later stop the tunnel without deleting the Monoscope deployment or remove the tunnel entirely when it is no longer needed.
Do I need router port forwarding or a public IP address?
No. The Localtonet client establishes an outbound connection to our relay server. This allows the public endpoint to reach the configured local dashboard without inbound router port forwarding, firewall changes, VPN setup, or a public IP address.
Does the tunnel keep working if Docker Compose or the client stops?
No. Monoscope must remain available on the configured local address, and the selected Localtonet client must remain connected with the tunnel running. If either side stops, remote dashboard access becomes unavailable.
Is the Docker Compose quick start automatically production-ready?
No such conclusion should be drawn from the short quick start. A production deployment also needs secure authentication, an intentional S3-compatible storage configuration, secret management, capacity planning, backups, upgrade testing, host monitoring, and a reliable startup strategy. Requirements vary with telemetry volume and organizational policy.
Connect your verified Monoscope dashboard with Localtonet
After Monoscope works locally and its default credentials have been replaced, create an HTTP tunnel to the dashboard on port 8080 and access it through the assigned public HTTPS address.
Get Started Free →
