Run your monitoring dashboard locally, protect its data, and provide controlled remote access
Uptime Kuma is a self-hosted monitoring application with a browser-based dashboard, configurable monitors, notifications, and status pages. This guide installs Uptime Kuma 2 with Docker, stores its application data in a persistent named volume, verifies the deployment locally, and provides a tested backup and update workflow. We then connect the localhost service to a Localtonet HTTP tunnel so you can reach the dashboard without inbound router port forwarding, firewall changes, VPN setup, or a public IP address.
📋 What's in this guide
How this Uptime Kuma and Localtonet setup works
Uptime Kuma is an open-source, self-hosted monitoring tool. It can monitor HTTP and HTTPS services, raw TCP endpoints, keywords and JSON queries in HTTP responses, WebSocket services, ping targets, DNS records, push monitors, supported game servers, and Docker containers. It also provides notification integrations, multiple status pages, certificate information, proxy support, two-factor authentication, and monitoring intervals as short as 20 seconds.
The application presents its management interface through an HTTP service on container port 3001. A standard Docker deployment can publish that port on every host network interface, making the dashboard available through both http://localhost:3001 and an address such as http://your-ip:3001. This guide uses the narrower mapping 127.0.0.1:3001:3001.
On current Docker releases, that mapping publishes the host port on the IPv4 loopback interface instead of all ordinary LAN interfaces. A Localtonet client running directly on the same host can connect to 127.0.0.1:3001 and relay the application through an HTTP tunnel. Remote users then open the public HTTPS address assigned to that tunnel.
Docker documents that on releases older than 28.0.0, hosts on the same Layer 2 network segment may be able to reach ports published to localhost. Do not treat 127.0.0.1 publication as categorical LAN isolation on an older Docker installation. Check docker version, update Docker where appropriate, and retain host firewall and network controls that match your security requirements.
louislam/uptime-kuma:2 image while a named volume preserves application data outside the container's writable layer.
127.0.0.1:3001:3001 limits normal host publication to IPv4 loopback on current Docker releases and fits a same-host tunnel deployment.
Understand the request path
During local testing, the request path is your browser to http://localhost:3001. After the tunnel starts, a remote browser uses the public HTTPS address assigned to the HTTP tunnel. The Localtonet relay passes the connection to our client on the Uptime Kuma host, and the client connects to the local target at 127.0.0.1:3001.
The Docker container, Uptime Kuma service, Localtonet client, and HTTP tunnel have independent lifecycles. Creating a tunnel does not start Uptime Kuma, and saving a tunnel configuration does not mean the tunnel is running. The container must be healthy, the client must be connected, and the tunnel must be started.
The target 127.0.0.1:3001 works when the Localtonet client runs directly on the host where Docker publishes Uptime Kuma. If our client runs on another computer or inside an isolated container, its loopback address refers to that environment instead. A separate-host design requires a target address that is reachable from the client, plus appropriate firewall and network controls.
Prerequisites and deployment decisions
Complete these checks before starting. They prevent common failures involving unavailable ports, unsupported storage, excessive network exposure, or a tunnel pointing at the wrong device.
Docker requirements
Install a current Docker environment appropriate for your operating system. The direct deployment in this guide requires a functioning Docker Engine and permission to create images, containers, ports, and volumes. Use the privilege model recommended for your operating system rather than weakening Docker socket or filesystem permissions.
Confirm that the Docker client can communicate with the server:
docker versionReview both the client and server information. If the command cannot connect to the daemon, start Docker and resolve that problem before launching Uptime Kuma. Also note the server version because the localhost publication behavior discussed above is version-sensitive for Docker releases older than 28.0.0.
Port and storage requirements
This deployment uses host port 3001. It must be available on 127.0.0.1. The installation command creates a named Docker volume called uptime-kuma and mounts it at /app/data, which is Uptime Kuma's persistent application-data location.
Uptime Kuma's installation guidance warns that NFS file systems are not supported for application data. Use a local directory or a Docker volume backed by supported local storage. A container starting successfully does not establish that an unsupported network filesystem is safe for its database.
Localtonet requirements
Create a Localtonet account and plan to install our client on the Docker host. The device needs a device-specific authentication token, and the tunnel configuration needs an available relay server or region selected from the current dashboard. Keep authentication tokens private and obtain current relay choices from the product rather than copying a server code from an older tutorial.
Complete the Uptime Kuma installation and local verification before creating the public route. This order gives you a known-good local service. If the dashboard does not work on the host, a tunnel only adds another diagnostic layer.
| Installation path | Requirements | When to choose it | Network behavior |
|---|---|---|---|
| Direct Docker command | Docker Engine | You want an explicit container, volume, restart policy, and port mapping | Can publish port 3001 specifically on 127.0.0.1 |
| Docker Compose | Docker with Compose support and curl for the documented download command |
You want a retained, file-based service definition | The upstream documented Compose configuration exposes Uptime Kuma on all interfaces |
| Non-Docker | Node.js 20.4 or newer, Git, npm, and optionally PM2 | You prefer to run the project directly on a supported host | The documented startup listens on all interfaces |
This tutorial uses the direct Docker command because it explicitly expresses the localhost-only host mapping. You can review the current upstream requirements in the official Uptime Kuma installation documentation.
Install Uptime Kuma with Docker
The following deployment uses the official major-version image tag, configures Docker's always-restart policy, publishes the dashboard on IPv4 localhost, and creates persistent storage.
Confirm Docker is available
Run docker version and verify that the client can communicate with the Docker server. Resolve daemon, service, or permission errors first.
Start the Uptime Kuma container
Run the Uptime Kuma 2 image with the named data volume and bind its published host port to 127.0.0.1. Docker downloads the image if necessary.
Check the container state
Confirm that the container named uptime-kuma remains running. Inspect its logs if it exits or repeatedly restarts.
Open the local dashboard
On the Docker host, open http://localhost:3001, complete the on-screen setup, and keep the management credentials private.
Start the container:
docker run -d --restart=always -p 127.0.0.1:3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:2The options perform these jobs:
-druns the container in detached mode.--restart=alwaysapplies Docker's always-restart policy.-p 127.0.0.1:3001:3001maps host loopback port 3001 to container port 3001.-v uptime-kuma:/app/datamounts the named volume at Uptime Kuma's persistent data directory.--name uptime-kumaassigns a predictable container name.louislam/uptime-kuma:2selects the official image's major version 2 tag.
Confirm that the container is running:
docker ps --filter name=uptime-kumaIf it is not listed, include stopped containers and inspect the logs:
docker ps -a --filter name=uptime-kuma
docker logs uptime-kuma
Removing a container is different from removing its named volume. The uptime-kuma volume contains the persistent configuration and application data. Do not run a volume-removal command unless you intend to delete that data or have completed and tested a suitable backup.
Docker Compose alternative
Uptime Kuma also documents this Compose installation sequence:
mkdir uptime-kuma
cd uptime-kuma
curl -o compose.yaml https://raw.githubusercontent.com/louislam/uptime-kuma/master/compose.yaml
docker compose up -d
The documented upstream configuration makes Uptime Kuma available on all network interfaces, including http://localhost:3001 and http://your-ip:3001. Inspect the downloaded file and its current port publication before using it on an untrusted network. The upstream file can change, so do not assume that a previously reviewed copy and the current download are identical.
Non-Docker alternative
The project also supports direct installation on major Linux distributions and supported 64-bit Windows versions. Its documented prerequisites are Node.js 20.4 or newer, Git, npm, and PM2 when the service should run in the background. FreeBSD, OpenBSD, NetBSD, Replit, and Heroku are listed as unsupported for this path.
git clone https://github.com/louislam/uptime-kuma.git
cd uptime-kuma
npm run setup
node server/server.jsThe documented PM2 setup for background operation is:
npm install pm2 -g && pm2 install pm2-logrotate
pm2 start server/server.js --name uptime-kuma
pm2 startup && pm2 saveThe remainder of this guide assumes the Docker container and named volume created by the direct command.
Complete the initial Uptime Kuma configuration
Open http://localhost:3001 in a browser on the Docker host. On a headless server, use an approved local administration path rather than broadening the Docker port publication simply to reach the setup screen. Interface labels can change between releases, so follow the screens shown by your installed version.
Complete initialization and create strong, unique management credentials. Uptime Kuma supports two-factor authentication, which should be enabled before routine internet access. Store any recovery information through your normal credential-management process.
Create a first monitor
A visible login page confirms that the web application responded, but it does not prove that monitoring works. Create at least one monitor for a target the Uptime Kuma container can reach. Choose the appropriate monitor type, enter the target information, and review the resulting state and response history.
Docker gives the container its own network context. Inside the Uptime Kuma container, localhost refers to that container. It does not automatically refer to another service on the Docker host or to another container. If a target works in a browser on the host but fails as a monitor, verify that its address is meaningful and reachable from Uptime Kuma's container network.
Configure and test notifications
Uptime Kuma supports services including Telegram, Discord, Gotify, Slack, Pushover, and email through SMTP, along with many other notification integrations. These configurations can contain webhook URLs, credentials, tokens, or account information. Treat them as secrets.
Use the installed version's notification test control before relying on an integration. Monitoring and notification delivery are separate paths. A monitor can detect a failure correctly while notification delivery fails because of DNS, authentication, provider, or outbound network problems.
Separate administration from public status information
Uptime Kuma supports multiple status pages and can map status pages to specific domains. A status page and the administrative dashboard have different audiences. Decide whether remote users need full administration, a read-only status view, or both. Do not expose the management interface merely to distribute service-health information when a carefully reviewed status page meets the requirement.
Localhost publication reduces ordinary direct network exposure, subject to the Docker version caveat, but starting the HTTP tunnel creates a public route to Uptime Kuma. Complete account setup, use a unique password, enable two-factor authentication, and review what the interface reveals before sharing the public address.
Verify Uptime Kuma locally before tunneling it
Local verification should cover the container lifecycle, host port mapping, application interface, persistent volume, and at least one monitor. This creates a baseline for distinguishing Uptime Kuma problems from tunnel problems.
Verify the browser endpoint
From the Docker host, visit:
http://localhost:3001Sign in and confirm that dashboard navigation works. If the interface does not load, inspect the container state and logs before configuring Localtonet.
Verify the host publication
docker ps --filter name=uptime-kuma
Review the port information and confirm that it reports 127.0.0.1:3001 on the host side rather than an all-interface publication. Output formatting can vary between Docker versions.
With Docker 28.0.0 or newer and the intended host networking configuration, a direct request from another LAN computer to http://docker-host-ip:3001 should not be served through this loopback mapping. On older Docker releases, do not rely on that test as proof of isolation because same-segment Layer 2 access may still be possible. Use a current Docker release and verify the host firewall and network policy independently.
Verify persistence
Confirm that the named volume exists:
docker volume inspect uptime-kumaRestart the existing container:
docker restart uptime-kuma
Wait for http://localhost:3001 to return, then verify that the account and monitor remain present. This tests normal restart persistence. It does not replace the backup and isolated restore test covered later.
Local verification checklist
- The container appears in
docker psand remains running. docker logs uptime-kumadoes not show a repeating fatal startup failure.- The dashboard loads at
http://localhost:3001on the Docker host. - The host publication reports
127.0.0.1:3001. - The Docker server version and localhost-publication caveat have been reviewed.
- The initial account configuration is complete.
- At least one known target produces an understandable monitor result.
- The
uptime-kumavolume exists. - Configuration remains available after a normal container restart.
Provide remote HTTP access with Localtonet
After local verification succeeds, install our client on the Docker host and configure an HTTP tunnel to 127.0.0.1:3001. The client establishes an outbound connection to a Localtonet relay, so this workflow does not require forwarding port 3001 on the router or assigning the host a public IP address.
Use the current Localtonet HTTP tunnel documentation to obtain the client for your operating system and confirm the labels presented by the current dashboard. Installation packages and interface details can vary by operating system and client version, so this tutorial does not invent a universal shell command.
HTTP tunnels support Random Sub Domain, Custom Sub Domain, and Custom Domain process types. They serve the selected local HTTP content through a public HTTPS address. Use an option currently available to your account. If you choose a custom domain, follow the current dashboard and documentation for its DNS values rather than copying records from another account or an older article.
Install and launch the Localtonet client
From the HTTP tunnel documentation, select the installation path for the Docker host's operating system, install the client, and launch it on that host. Verify from the host that http://127.0.0.1:3001 works before continuing.
Authenticate the device
Associate the running client with its device-specific authentication token. Keep that token out of screenshots, command examples, support posts, repositories, and shell history wherever possible.
Create an HTTP tunnel
Open the HTTP tunnel page and select a process type. A generated random subdomain is the simplest starting point because it lets you verify connectivity before adding custom-domain DNS.
Select the AuthToken and relay server
Select the AuthToken for the client running on the Docker host, then choose an available server or region from the current dashboard. Available values must come from the product rather than a hardcoded example.
Enter the local IP address and port
Set the local IP address to 127.0.0.1 and the local port to 3001. These values describe Uptime Kuma from the perspective of the selected Localtonet client device.
Start the tunnel
Save or create the configuration as presented by the dashboard, then use the Start control. Creating a tunnel does not start it automatically.
Test the public HTTPS address
Open the assigned address from a remote device or separate network. Confirm that the expected Uptime Kuma interface loads, authentication is still required, and live dashboard behavior works after sign-in.
The public endpoint remains available only while the selected client is connected and the tunnel is running. Stopping Uptime Kuma leaves the tunnel without a working local application. Stopping the tunnel disables the public route without stopping Uptime Kuma's local monitoring process.
| Layer | Expected state | Failure result |
|---|---|---|
| Uptime Kuma container | Running as uptime-kuma |
No dashboard is available locally or remotely |
| Local HTTP endpoint | 127.0.0.1:3001 |
The client has no working local target |
| Localtonet client | Connected on the Docker host | The relay cannot reach the local endpoint |
| HTTP tunnel | Created and started | The public address is inactive |
| Remote browser | Using the assigned HTTPS address | Using localhost points to the remote device instead |
Verify the complete remote route
Test from another network, such as a mobile device with local Wi-Fi disabled. Sign in, navigate through the dashboard, and confirm that monitor information updates. Uptime Kuma uses a reactive web interface and WebSocket functionality, so loading only the initial page is not a complete test.
Keep authentication enabled. Do not treat an unlisted or generated public address as an authorization control because URLs can be copied, logged, stored in browser history, or shared unintentionally.
Back up, restore, update, and roll back safely
Operational maintenance should preserve both the Uptime Kuma data and a known way back to the previous application image. The commands below apply to the named-volume deployment created in this article. Run them from a directory with enough free space for the backup archive.
Normal lifecycle and logs
docker stop uptime-kuma
docker start uptime-kuma
docker restart uptime-kumaView accumulated logs or follow new output:
docker logs uptime-kuma
docker logs -f uptime-kumaThe restart policy helps Docker restart the container according to that policy. It does not protect against storage failure, host failure, data corruption, invalid configuration, or an incompatible application update.
Create a consistent named-volume backup
Stop Uptime Kuma before copying /app/data. This avoids taking an arbitrary copy while the application may be writing its database. The brief outage is intentional.
docker stop uptime-kuma
docker run --rm -v uptime-kuma:/source:ro -v "$PWD":/backup alpine sh -c 'cd /source && tar -czf /backup/uptime-kuma-backup.tar.gz .'
docker start uptime-kuma
The temporary Alpine container mounts the Uptime Kuma volume read-only at /source and writes the archive into the current host directory. Docker may download the Alpine image the first time. Confirm that the command completed successfully and that uptime-kuma-backup.tar.gz exists before treating the backup as usable.
Move the archive to protected storage outside the Docker host's failure domain. It can contain monitor details, notification configuration, and integration secrets. Apply suitable access controls, retention, and encryption through your normal backup system.
Test restoration into an isolated volume
A backup is not verified until it can be restored. Create a separate volume and extract the archive into it:
docker volume create uptime-kuma-restore
docker run --rm -v uptime-kuma-restore:/target -v "$PWD":/backup alpine sh -c 'cd /target && tar -xzf /backup/uptime-kuma-backup.tar.gz'Start an isolated test container on a different loopback port:
docker run -d --restart=no -p 127.0.0.1:3002:3001 -v uptime-kuma-restore:/app/data --name uptime-kuma-restore louislam/uptime-kuma:2
Open http://localhost:3002 and confirm that the expected account, monitors, and settings are present. Do not point the production Localtonet tunnel at this test container. When testing is complete, remove the test container:
docker stop uptime-kuma-restore
docker rm uptime-kuma-restore
Keep or remove the restored test volume according to your recovery-testing policy. Do not confuse it with the production uptime-kuma volume.
Prepare for an update
Review Uptime Kuma's official update documentation and the release notes for the version you intend to deploy. Application-specific migration warnings take precedence over a generic container replacement procedure.
Before pulling a newer image, record and tag the image currently used by the running container:
OLD_IMAGE=$(docker inspect --format='{{.Image}}' uptime-kuma)
docker image tag "$OLD_IMAGE" uptime-kuma:pre-update
Create and test a fresh backup using the preceding workflow. Because the :2 tag follows major version 2 instead of pinning one exact patch release, pulling it can retrieve a newer image than the one currently stored on the host.
Replace the container with the updated image
Pull the current major-version image:
docker pull louislam/uptime-kuma:2Stop and remove only the container. Do not remove the named volume:
docker stop uptime-kuma
docker rm uptime-kumaRecreate the container with the same name, loopback publication, restart policy, and persistent volume:
docker run -d --restart=always -p 127.0.0.1:3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:2Restarting an existing container alone does not download a new image. The explicit pull and container replacement are what place the deployment on the newly downloaded image.
Verify the update
Check the container and review its startup output:
docker ps --filter name=uptime-kuma
docker logs uptime-kumaThen complete these checks:
- Open
http://localhost:3001and sign in. - Confirm that expected monitors, status pages, and notification configurations remain present.
- Review several monitor states and recent history.
- Run an appropriate notification test.
- Confirm that the Docker port remains published at
127.0.0.1:3001. - Open the Localtonet public HTTPS address and verify sign-in and live dashboard behavior.
- Review logs again after normal traffic has reached the updated application.
Roll back without reusing potentially migrated data
An application update may change persistent data. Simply starting the old image against a volume already opened or migrated by the new version may be unsafe. A conservative rollback uses the pre-update image together with a separately restored copy of the pre-update backup.
Stop and retain the failed or suspect container for investigation:
docker stop uptime-kuma
docker rename uptime-kuma uptime-kuma-failed-updateRestore the pre-update archive into a new rollback volume:
docker volume create uptime-kuma-rollback
docker run --rm -v uptime-kuma-rollback:/target -v "$PWD":/backup alpine sh -c 'cd /target && tar -xzf /backup/uptime-kuma-backup.tar.gz'Start the tagged pre-update image with the restored data:
docker run -d --restart=always -p 127.0.0.1:3001:3001 -v uptime-kuma-rollback:/app/data --name uptime-kuma uptime-kuma:pre-updateRepeat the local, monitor, notification, and public-tunnel checks. Retain the failed-update container and original volume until you have diagnosed the problem and confirmed recovery. Do not delete either copy merely to reclaim space during an active incident.
Stop remote access when it is unnecessary
Stop the Localtonet tunnel when remote administration is not required. Uptime Kuma can continue monitoring locally while the public route is inactive. Starting or stopping the tunnel does not start or stop the Docker container.
Troubleshooting the container and remote connection
The container name is already in use
docker ps -a --filter name=uptime-kuma
Docker container names must be unique. The existing object may be a stopped deployment containing the configuration you intend to retain. If it is the correct container, use docker start uptime-kuma. Do not remove it until you understand which volume it uses.
Port 3001 is already allocated
Another process or container is using the host port. Identify it using the networking tools appropriate for your operating system. Either stop the conflicting service or select a different unused host port.
If you change only the host side, such as publishing 127.0.0.1:3002:3001, update the local browser URL and Localtonet target port to 3002. Uptime Kuma still listens on container port 3001.
The container starts and exits
docker ps -a --filter name=uptime-kuma
docker logs uptime-kumaAddress the specific startup error. Preserve the volume during diagnosis unless an official recovery procedure explicitly requires destructive action and you have a verified backup.
The browser cannot open localhost:3001
Confirm that the browser is running on the Docker host. If Docker runs on a server while you enter localhost on a laptop, the laptop tries to contact itself. Then verify the container state, logs, and port mapping. Diagnose operating-system security controls with platform-specific tools rather than disabling the firewall broadly.
Another LAN device can reach the supposedly local port
Check the Docker server version. Docker documents that releases older than 28.0.0 can allow hosts on the same Layer 2 segment to reach ports published to localhost. Upgrade Docker where appropriate and review host firewall and network segmentation. Also inspect the actual container mapping to ensure it is not published as 0.0.0.0:3001 or :::3001.
Local access works, but the public address does not
- Confirm that
http://127.0.0.1:3001still works on the Docker host. - Confirm that the Localtonet client is running and connected.
- Confirm that the selected AuthToken identifies that host.
- Confirm that the tunnel targets local IP
127.0.0.1and port3001. - Confirm that an available relay server is selected.
- Confirm that the tunnel was started after creation.
- Use the assigned public HTTPS address rather than the local HTTP URL.
If the client runs in another container or on another machine, 127.0.0.1 is the wrong target because it refers to that separate environment.
The page loads, but interactive functions fail
Verify the same functions locally first. Then reproduce the problem through the public address while reviewing docker logs -f uptime-kuma. Uptime Kuma uses WebSocket functionality, so a successful static page response does not prove that the complete application path works.
Avoid adding an unrelated reverse proxy until the direct Localtonet HTTP tunnel works. Additional proxies introduce more header, timeout, redirect, and connection-upgrade behavior to diagnose.
A monitor cannot reach a service on the Docker host
Monitoring requests originate from Uptime Kuma's container network context. Inside that container, 127.0.0.1 points to Uptime Kuma itself. Use a target address and network design that make the monitored service reachable from the container while retaining suitable authentication and firewall policy.
Localtonet provides remote access to the Uptime Kuma web interface in this workflow. It does not automatically change the container's ability to reach private monitoring targets.
The dashboard disappeared after a host restart
Confirm that Docker started, then inspect the container:
docker ps -a --filter name=uptime-kumaThe restart policy depends on Docker itself being operational. For public access, also confirm that the Localtonet client is connected and that the HTTP tunnel is running.
Security checklist for an internet-reachable dashboard
Tunneling avoids direct inbound router configuration, but it does not replace application authorization. The public URL is an intentional route to a management application that may reveal infrastructure names, internal URLs, status history, notification configuration, and operational patterns.
Do not confuse a public URL with authorization
Localtonet carries requests to the configured local HTTP endpoint. Uptime Kuma remains responsible for dashboard authentication and authorization. Confirm in a private browser session that unauthenticated visitors cannot reach administrative information.
Review public status-page contents
Status pages should disclose only what their intended audience needs. Monitor names, endpoint labels, incident details, and group names can reveal architecture. Use public-facing descriptions instead of internal operational naming where appropriate.
Protect notification and integration secrets
Notification settings can contain webhook URLs, SMTP credentials, tokens, or account identifiers. Restrict administrative access, omit secrets from screenshots, and rotate any credential that is accidentally disclosed. Never place Localtonet device tokens in monitor descriptions or status-page content.
Preserve organizational network policy
Deploy the tunnel only where you are authorized to expose the application. Localtonet removes the need for inbound port forwarding in this workflow, but it must not be used to evade access rules. Follow your environment's approval, least-privilege, authentication, and data-handling requirements.
Frequently asked questions
What URL does Uptime Kuma use after installation?
With this Docker mapping, open http://localhost:3001 or http://127.0.0.1:3001 on the Docker host. Remote users use the public HTTPS address assigned to the running Localtonet HTTP tunnel.
Does binding port 3001 to 127.0.0.1 always prevent LAN access?
Not categorically on every Docker release. Docker documents that releases older than 28.0.0 may allow hosts on the same Layer 2 segment to reach ports published to localhost. Use a current Docker release and retain appropriate host firewall and network controls.
Can the Localtonet client run on another computer?
Yes, if that computer can reach Uptime Kuma. It cannot use 127.0.0.1:3001 to reach another host because loopback refers to the client device itself. You must provide an appropriately reachable target and enforce suitable firewall and network policy.
Does creating a Localtonet tunnel start it automatically?
No. Creating and starting a tunnel are separate lifecycle actions. Use the Start control after reviewing the device, relay, local IP address, and port. The endpoint works only while the selected client is connected and the tunnel is running.
Do I need router port forwarding or a public IP address?
No. Our client establishes an outbound connection to a Localtonet relay. This workflow does not require inbound router port forwarding, firewall changes, VPN setup, or a public IP address.
Where is Uptime Kuma data stored?
The named volume uptime-kuma is mounted at /app/data inside the container. Uptime Kuma warns that NFS is unsupported for this application data, so use a local directory or Docker volume backed by supported local storage.
Can I back up the Docker volume while Uptime Kuma is running?
This guide stops the container before archiving the volume so the application is not actively changing its database during the copy. Start the container again after the archive completes, store the backup outside the host, and test restoration into a separate volume.
Why is a backup needed before updating the container?
The :2 tag can move to a newer version 2 image, and an update may alter persistent data. A pre-update backup and retained previous image let you recover using a separate restored volume instead of attaching an older application to potentially migrated data.
Will Uptime Kuma keep monitoring if I stop the tunnel?
Yes, provided the Uptime Kuma container and its required network connections remain operational. The tunnel controls remote access to the web interface, not the container's monitoring lifecycle.
Does Localtonet perform the service checks for Uptime Kuma?
No. Uptime Kuma performs monitoring from its own container and network context. Localtonet provides remote HTTP access to the Uptime Kuma interface in this deployment. The tunnel does not change which monitoring targets the container can reach.
Access your self-hosted Uptime Kuma dashboard with Localtonet
Deploy Uptime Kuma with persistent storage, verify it locally, establish a tested recovery process, and then create an HTTP tunnel to 127.0.0.1:3001. Our outbound connection provides a public HTTPS address without inbound router port forwarding or a public IP.
