Run privacy-focused web analytics on your own infrastructure and make the verified HTTP service remotely reachable
Plausible Community Edition is the official self-hosted edition of Plausible Analytics. This guide explains how to plan the deployment, follow the official CE installation workflow without confusing it with the main application source repository, verify the service locally, and operate it safely. Once the local browser interface is working, we show how to publish that exact HTTP endpoint with Localtonet without inbound router port forwarding, firewall changes, a VPN, or a public IP address. Because the available project evidence does not establish universal installation commands, ports, paths, hostnames, or environment variables, we explain how to obtain those values from the CE instructions and your deployed configuration instead of guessing them.
📋 What's in this guide
Understand the Plausible CE and Localtonet architecture
Plausible Analytics is an open-source, privacy-focused web analytics application. The project describes its analytics experience as a simple dashboard backed by a lightweight, cookie-free tracking approach. It can receive analytics events, display reports in a browser, and support integrations through its Events API and Stats API. Plausible Community Edition, usually abbreviated as Plausible CE, is the project's official self-hosted edition.
Self-hosting changes the operational responsibility. With Plausible CE, you provide and manage the host, application configuration, storage, updates, security, uptime, backups, capacity, and recovery process. Those duties remain yours whether the service is available only on a private network or published to the internet.
The main plausible/analytics source repository is not, by itself, the complete installation guide for the packaged Community Edition. The project's own material directs self-hosting users to the separate official plausible/community-edition repository for installation instructions. That distinction matters because commands or files intended for application development are not necessarily the supported CE deployment procedure.
Localtonet enters the architecture only after Plausible CE is running. The Localtonet client runs on the Plausible host, or on another device that can reach it, and establishes an outbound connection to one of our relay servers. An HTTP tunnel then maps a public HTTPS address to the confirmed local Plausible HTTP address and port. The tunnel is available only while the selected Localtonet client is connected and the tunnel is running.
Why HTTP is the appropriate tunnel family
Plausible exposes a browser-based web application and HTTP APIs, so an HTTP tunnel matches this workflow. A raw TCP tunnel can forward a port, but it gives up the HTTP-oriented public address workflow that is appropriate for a web dashboard. VPN Manager serves a different purpose and should not be confused with ordinary HTTP tunneling.
The public address may need to serve more than an administrator opening the dashboard. Depending on how you configure Plausible, websites may also request a tracking script or send analytics events to the deployment. Before publishing anything, identify which Plausible functions must be public and which should remain restricted. Do not assume that an administrator-only tunnel automatically forms a complete production analytics endpoint.
A Localtonet tunnel cannot repair an incomplete Plausible installation. First make Plausible respond correctly from the host or private network. Only then point the tunnel at that tested endpoint.
Prepare the host and deployment information
Start with the prerequisites listed by the current official Plausible Community Edition instructions. The supplied project evidence confirms that CE has its own installation repository, but it does not establish a universal operating system list, container runtime version, CPU requirement, memory requirement, storage requirement, port, hostname, file path, or environment-variable set. Those details can change between CE releases, so this article does not invent them.
Read the CE instructions for the version you plan to deploy and record the required software and configuration before making the service public. At minimum, your deployment plan should answer the following questions:
- Which operating systems and processor architectures does the current CE release support?
- Which runtime, container engine, orchestration component, or other dependency does the documented installation method require?
- Which application release or container image tag will you deploy?
- Which persistent directories or storage volumes contain application and analytics data?
- Which secrets, account settings, or application configuration values must be generated?
- Which local interface and port will accept HTTP requests?
- How does the documented setup expect its public-facing URL or hostname to be configured?
- How will you back up and restore every persistent component?
Reserve enough storage for both current data and growth, and keep backups on a separate failure boundary from the live host. An untested backup is not a recovery plan. Before production use, document how you would restore the deployment onto a clean host and how you would verify that the restored dashboard and event flow work.
Choose where the Localtonet client will run
The simplest topology places the Localtonet client on the same machine as Plausible CE. In that arrangement, the tunnel can target the application's local listener if that listener is reachable from the host. Another supported topology places the client on a different machine that can reach Plausible over the local network. In both cases, the target address must be reachable from the Localtonet client device itself.
Do not copy an address observed from an unrelated machine without testing it from the client host. Names such as localhost always refer to the machine on which the relevant process runs. If Localtonet and Plausible are on different machines, a loopback address on the Localtonet device will not reach Plausible.
Prepare a verification record
Keep a short deployment record containing the installed CE version, installation method, local URL, local IP address, local port, persistent-data locations, backup procedure, and date of the most recent successful restore test. Do not put passwords, Localtonet authentication tokens, private keys, or application secrets into ordinary notes or source control.
| Value to record | Where it must come from | Why it matters |
|---|---|---|
| CE release or image tag | Official CE release instructions and deployed configuration | Supports vulnerability checks, upgrades, and rollback planning. |
| Local HTTP address | The running service and its documented configuration | Identifies the address the Localtonet client must be able to reach. |
| Local HTTP port | The running service and its documented configuration | Becomes the local target port for the HTTP tunnel. |
| Persistent storage | Official CE deployment definition | Determines what must be backed up and restored together. |
| Public URL expectations | Current CE configuration guidance | Helps avoid incorrect generated links, redirects, or callback behavior. |
| Localtonet device token | Your Localtonet account and selected device | Identifies the client device, but must never be published or shared. |
Install and configure Plausible Community Edition
Use the installation workflow in the official plausible/community-edition repository for your chosen CE release. Do not substitute commands from the main application development repository unless the CE instructions explicitly direct you to do so. The main repository contains application source and developer-oriented material, while the CE repository is the documented starting point for self-hosting.
The evidence available for this article does not state the current CE installation commands, dependency versions, filenames, default port, environment variables, or startup command. Reproducing guessed values would create an unsafe and potentially broken deployment. Follow the current official CE instructions exactly, then use the verification process below to discover and confirm the resulting endpoint.
Select a supported Plausible CE release
Review the current CE release information and security notices. Choose an explicit supported release rather than an old image tag copied from a historical tutorial. Record the exact version you deploy so that you can later determine whether a security advisory affects it.
Meet the documented host prerequisites
Install only the runtime and supporting software required by the official CE instructions. Confirm that the host has suitable storage, memory, networking, time synchronization, and a restart strategy. Use the versions supported by the selected CE release rather than assuming that any installed version is compatible.
Create the documented CE configuration
Follow the CE instructions to create or edit the required deployment files and application settings. Generate unique secrets by the documented method. Never copy example credentials into production, commit secrets to source control, or reuse a Localtonet device token as an application secret.
Configure persistent storage and backups
Identify every persistent component in the official deployment definition. Ensure that it survives application restarts and upgrades. Create a backup plan that captures a consistent state, and document the restore order before analytics data becomes important.
Start the CE deployment using the documented procedure
Run the startup procedure supplied for the selected CE version. Observe the application and supporting-service status instead of assuming that a successful command exit means the entire stack is ready. Resolve startup, storage, or configuration errors before adding remote access.
Record the actual local HTTP endpoint
Determine the address and port on which the deployed service is listening. Obtain these values from the active CE configuration, runtime status, and documented local access instructions. This verified endpoint, not a port copied from another guide, will become the Localtonet HTTP target.
Complete the application setup locally
Open the local Plausible interface and complete the setup requested by the application. Use unique administrator credentials and store them in an appropriate password manager. If the application requires its public URL to be configured, use the exact mechanism documented for the installed CE version. The supplied evidence does not establish that setting's current name or format, so it should not be guessed.
Add a test site only after the administrative interface works reliably. When you later configure a real website, use the tracking instructions generated or documented for your CE version. Script paths and integration details can evolve, and a tracking snippet from a different release or from the managed service may not represent your self-hosted configuration.
Verify Plausible locally before creating a tunnel
Local verification separates application problems from tunnel problems. If Plausible does not work from the Localtonet client device, publishing it will not make it work. Perform the following checks while the service is still private.
Confirm the browser interface
Open the exact local URL from a browser on the host or from another authorized machine that can reach it. Confirm that the expected Plausible page loads, that authentication succeeds, and that navigation does not lead to an unexpected hostname or an unreachable address.
A browser page that appears once is not enough. Refresh it, sign out and back in, and revisit it after restarting the deployment through its documented process. If it only works immediately after manual intervention, fix lifecycle management before exposing it.
Confirm reachability from the Localtonet client
If the Localtonet client runs on the same host, test the endpoint from that host. If it runs elsewhere, perform the test on the client device. This catches host firewall rules, incorrect bind addresses, container networking boundaries, DNS differences, and routing problems before they are mistaken for Localtonet issues.
Record the successful target as an IP address or hostname plus port. Keep the local scheme in mind as well. The workflow in this article assumes the confirmed target is an HTTP service suitable for an HTTP tunnel. Do not label an unverified encrypted or non-HTTP listener as HTTP.
Check the application functions you intend to publish
Verify more than the sign-in page. Open a dashboard, confirm that the expected site configuration appears, and test the relevant analytics workflow. If your intended deployment will receive events from a website, use the CE documentation for your installed version to configure the site and confirm that a controlled test visit or event appears as expected. If you plan to use an API, test authentication and the relevant endpoint locally before involving the tunnel.
A successful dashboard response does not automatically prove that tracking ingestion, scripts, APIs, reports, and generated links all use the correct externally reachable URL. Test every externally required function after publishing as well.
Publish the verified Plausible HTTP service with Localtonet
Once local verification succeeds, create an HTTP tunnel that targets the tested address. With Localtonet, the client establishes an outbound connection to our relay server, so you do not need to expose an inbound router port, change an edge firewall to accept unsolicited traffic, configure a VPN, or obtain a public IP address.
The current dashboard is the authoritative place to obtain available relay servers, regions, process types, and plan-dependent options. Do not hardcode a server code from another deployment. HTTP process types can include Random Sub Domain, Custom Sub Domain, or Custom Domain, and each serves the same local content at a public HTTPS address. Availability can vary, and exact custom-domain DNS instructions must be checked against current Localtonet documentation before making DNS changes.
Install and run the Localtonet client
Install our client on the Plausible host or on another device that has already passed the local reachability test. Keep the client running whenever the public analytics endpoint must remain available.
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, public issue reports, website source, or application configuration.
Select an available relay server
Choose an available server or region from the current Localtonet dashboard. Available values can vary, so use the choices shown for your account instead of copying a server code from an article.
Create an HTTP tunnel to the verified target
Select the HTTP tunnel family and enter the local IP address and port recorded during verification. Choose the appropriate HTTP process type from the options available to you. Do not enter an assumed Plausible port or use a loopback address when the client runs on another machine.
Start the tunnel
Creating a tunnel does not start it. Use the Start button, confirm that the selected client is connected, and wait for the tunnel to report its running state.
Test the assigned public address
Open the assigned public HTTPS URL from a network that is not relying on the local-only address. Test authentication, dashboard navigation, event delivery, tracking-script retrieval, or API behavior according to the functions you intend to expose. Stop or delete the tunnel if the target is incorrect or the service should no longer be public.
For the current dashboard sequence and available options, consult our Localtonet HTTP tunnel documentation. The documentation supplements the verified target information from your own Plausible deployment. It cannot determine your Plausible port or application configuration for you.
Treat the assigned address as internet-facing even if you only share it with a small team. Keep Plausible updated, preserve application authentication, avoid public dashboard-sharing features unless intentionally configured, and expose only the functions required for your analytics workflow.
Secure the public analytics deployment
Tunneling removes the need for inbound router configuration, but it does not remove application-security responsibilities. Requests reaching the public URL are forwarded to the local target. Plausible CE must therefore be configured and maintained as an internet-facing service whenever the tunnel is running.
Update affected Plausible CE releases
Plausible CE release v3.2.1 is a security-related patch that removes the HTTP /storybook endpoint. The release notice identifies CVE-2026-8467 and GHSA-55hg-8qxv-qj4p, describing conditions under which the endpoint could allow remote code execution with the privileges of the system user running the application.
The notice lists affected tags across the v3.0, v3.1, and v3.2 lines, including release candidates and broad tags such as v3. It recommends updating affected Plausible CE deployments to v3.2.1 as soon as possible. Its immediate mitigation is to block access to /storybook through the reverse proxy or another applicable control.
Before exposing any existing CE deployment, identify its exact version and compare it with current Plausible security information. If it is among the affected releases, updating is the preferred corrective action described by the release. Blocking the endpoint is an immediate mitigation, not a reason to leave an affected version indefinitely exposed.
If your deployment uses one of the versions identified by the Plausible v3.2.1 security notice, update it before starting a public tunnel. If an immediate update is temporarily impossible, apply the project's documented mitigation to block /storybook and verify from an untrusted network that the path is not reachable.
Use least privilege on the host
The security notice specifically refers to code execution with the privileges of the system user running the application. This illustrates why the Plausible process and its supporting services should not receive unnecessary host privileges. Follow the official CE deployment model and your platform's hardening guidance. Restrict access to persistent data, configuration files, secrets, and administrative interfaces to the identities that need them.
Protect every credential separately
Plausible administrator credentials, application secrets, API credentials, database credentials, and Localtonet device tokens serve different purposes. Do not reuse them. Rotate a credential when disclosure is suspected, and remove secrets from logs, screenshots, shell history, support attachments, and repositories before sharing diagnostic information.
Decide what truly needs public access
A functional analytics deployment may need selected public HTTP functions so websites can load a script or submit events. That does not mean every administrative capability should be available without authentication. Keep dashboard authentication enabled and review Plausible's own sharing controls before making a dashboard public.
If remote administrators are the only users, consider whether the public tunnel needs to run continuously. Localtonet tunnels can be stopped when access is no longer required. Remember that stopping the tunnel also interrupts any tracking scripts, event requests, or APIs that depend on its public URL.
Understand URL stability requirements
A temporary generated address can be useful for testing. A production analytics integration may require a stable address because website code, API clients, or application configuration can reference it. Localtonet HTTP process types include random subdomain, custom subdomain, and custom domain options, but availability and exact setup requirements can vary. Confirm the current dashboard options and custom-domain documentation before committing a production site to a URL.
Operate, update, and back up the service
Production self-hosting is an ongoing process rather than a one-time installation. Establish simple routines for health checks, updates, backups, recovery tests, capacity review, and tunnel lifecycle management.
| Operational task | What to verify | Why it matters |
|---|---|---|
| Application health | Dashboard, authentication, event flow, and required APIs respond correctly. | A running process does not guarantee that the complete analytics workflow works. |
| Version review | Installed CE release against current releases and security advisories. | Internet exposure increases the importance of timely security updates. |
| Backup verification | All persistent components are captured and can be restored consistently. | Self-hosted data recovery is your responsibility. |
| Capacity review | Available storage, memory, processing capacity, and data growth. | Analytics workloads can grow as traffic and retention increase. |
| Tunnel health | Localtonet client is connected and the intended tunnel is running. | The public URL works only while both conditions are true. |
| External validation | Public URL, authentication, tracking, and APIs from outside the local network. | Catches issues that local-only testing cannot reveal. |
Use a controlled upgrade procedure
Before upgrading, read the CE instructions and release notes for the target version. Back up persistent data and configuration, record the currently deployed release, and understand the supported migration procedure. After the upgrade, repeat both local and public verification. Confirm that the old vulnerable version or image is not still running through an overlooked service definition.
If rollback is supported by the project's instructions, document it before the upgrade. Do not assume that data modified by a newer application can always be opened safely by an older release. The project documentation for the selected versions must govern migration and rollback decisions.
Manage the tunnel lifecycle deliberately
Creating a tunnel and starting a tunnel are separate actions. When maintenance begins, decide whether the public endpoint should remain available. If you stop the tunnel, remote dashboard access and any analytics traffic using that address will stop. If you leave it running while Plausible is unavailable, users and integrations will receive failures from the unreachable local target.
When the tunnel is no longer needed, stop it. Delete obsolete tunnels rather than leaving unused configurations in the dashboard. If you replace the Localtonet client device, use the appropriate device-specific token for the replacement and update the tunnel selection as needed.
Troubleshoot Plausible CE and tunnel problems
The Plausible page does not load locally
Stop troubleshooting the public URL and return to the CE deployment. Confirm that the documented services are running, inspect their status and logs using the project's supported procedure, and verify the configured listener. Look for missing secrets, unavailable persistent services, permission errors, failed migrations, storage exhaustion, or a bind address that does not accept the intended connection.
Because the evidence supplied here does not establish the CE service names or log commands, use the exact commands from the installation method you selected. Do not substitute commands for another runtime or an older release.
It works on the Plausible host but not on the Localtonet device
This normally indicates a reachability difference between the two machines. Verify the address from the Localtonet device, not only from the Plausible host. A service bound only to a loopback interface cannot be reached through another machine's network connection. Also check local firewall policy, routing, name resolution, and any isolation introduced by the deployment runtime.
You can avoid this network hop by running the Localtonet client on the same host, provided that choice matches your security and operational requirements.
The public URL does not respond
Confirm that the Localtonet client is connected, the correct device token is in use, and the tunnel has been started. Then compare the tunnel's local target with the endpoint that passed local verification. A tunnel configuration can exist in the dashboard without being active.
If Plausible and Localtonet are on different machines, make sure the tunnel does not target the Localtonet machine's loopback address by mistake. Re-test the configured target directly from the client device.
The public URL opens the wrong service
The selected local port may belong to another application, or the Plausible listener may have changed. Stop the tunnel, identify the actual Plausible endpoint from the active deployment, verify it locally, update the target, and start the tunnel again.
The page loads, but tracking events do not appear
Verify the entire request path. Confirm that the website uses the integration instructions for your CE deployment, that it references the intended public address where required, and that the browser can retrieve the relevant script and submit the event request. Check for browser errors, blocked requests, incorrect site configuration, hostname mismatches, and application-side ingestion failures.
Also confirm that the tunnel remained running while the test event was sent. If only the dashboard was tested, you have not yet proven that the event-ingestion path works.
Requests redirect to a local or incorrect hostname
Review the public URL or hostname setting required by your installed CE version. The precise setting is not established by the supplied evidence, so use the current CE documentation rather than guessing an environment-variable name. After correcting it, restart or reload the application only through the documented procedure and repeat the external test.
A security scanner reports /storybook
Identify the exact Plausible CE version immediately. The v3.2.1 security release removes that endpoint and instructs affected deployments to update. If an update cannot be performed immediately, block the path using the mitigation described by Plausible and verify externally that access is denied. Do not rely on keeping the URL secret.
Frequently asked questions
What is Plausible Community Edition?
Plausible Community Edition is the official self-hosted edition of Plausible Analytics. It lets you operate the analytics application on infrastructure you manage. You are responsible for installation, maintenance, security, backups, capacity, uptime, and recovery.
Why does this guide not provide a fixed Plausible port or installation command?
The available official evidence confirms that self-hosting instructions belong to the separate Plausible Community Edition repository, but it does not establish a universal port, command, path, dependency version, or environment-variable set. Those details must come from the official instructions for the CE release you deploy and from your active configuration. Guessing them could create a broken or insecure installation.
Should I install Plausible CE from the main analytics repository?
Use the official plausible/community-edition installation instructions for a CE deployment. The main plausible/analytics repository contains the application source and points self-hosting users to the separate CE repository. Do not assume that a developer workflow from the main repository is the supported packaged deployment process.
Which Localtonet tunnel type should I use for Plausible?
Use an HTTP tunnel for the verified Plausible web endpoint. Plausible provides a browser-based interface and HTTP-facing functionality, making HTTP the appropriate tunnel family for this workflow. Point it at the exact local IP address and port that passed your local tests.
Does Localtonet require router port forwarding?
No. Our client establishes an outbound connection to a Localtonet relay server. This lets the running tunnel provide a public URL without inbound router port forwarding, firewall changes, VPN setup, or a public IP address.
Will the public Plausible URL work if the Localtonet client stops?
No. The tunnel is available only while the selected client device is connected and the tunnel is running. Plausible must also remain healthy and reachable from that client. If any part of this path stops, the public service becomes unavailable.
Is Plausible CE v3.2.1 important for public deployments?
Yes, if your installation uses a release affected by CVE-2026-8467 and GHSA-55hg-8qxv-qj4p. Plausible CE v3.2.1 removes the vulnerable /storybook endpoint, and the release notice recommends that affected deployments update as soon as possible. Check current project security information in case a newer supported release is available when you deploy.
Can I use a custom domain for the public analytics endpoint?
Localtonet HTTP tunnels can use Random Sub Domain, Custom Sub Domain, or Custom Domain process types. Availability may vary by current dashboard options or plan. Check the current Localtonet documentation for exact custom-domain and DNS requirements before changing DNS records.
Does publishing through Localtonet secure the Plausible administrator account automatically?
No. The tunnel provides connectivity to the selected local service. Application authentication, administrator credentials, software updates, least privilege, data protection, backups, and intentional dashboard-sharing settings remain part of your Plausible CE security responsibilities.
Publish your verified Plausible CE service with Localtonet
Finish the Plausible Community Edition installation, confirm its exact HTTP endpoint locally, update any affected release, and then create an HTTP tunnel from the device that can reach it.
Get Started Free →
