Run your own knowledge workspace locally, verify it carefully, then publish only the web endpoint you intend to share
EdgeEver is an open-source notes and knowledge-base application with a browser interface, a classic three-pane workspace, SQLite-based storage, multi-device access, and native AI integrations. Its official materials support Docker deployment on a VPS, NAS, or home server, making it suitable for infrastructure you control. This guide explains how to prepare that environment, follow the current upstream Docker procedure without guessing undocumented settings, verify the local service, and maintain the deployment. After the local installation works, we show how to provide remote browser access with a Localtonet HTTP tunnel without opening an inbound router port.
📋 What's in this guide
What EdgeEver is and why self-host it
EdgeEver is an open-source knowledge workspace designed around notes, notebooks, attachments, synchronization, and a familiar three-pane interface. The project describes itself as an Evernote-style alternative with an open data architecture. Its documented capabilities include nested notebooks, rich-text and Markdown editing, a REST API, CLI access, Model Context Protocol integration, ZIP export, version history, and SQLite-based storage.
The project offers two fundamentally different deployment paths. Its Cloudflare deployment is intended for a serverless installation, while Docker is the documented option for infrastructure such as a VPS, NAS, or home server. This distinction matters for remote access. A Cloudflare deployment is already hosted on public infrastructure and ordinarily does not need a Localtonet tunnel. A Docker deployment on a private home network, however, normally exposes a local web endpoint first. That local endpoint is the appropriate target for a Localtonet HTTP tunnel.
Self-hosting gives you responsibility as well as control. You decide where the application runs, where its persistent data resides, when it is upgraded, how it is backed up, and whether it is reachable outside the local network. Docker can make the application lifecycle repeatable, but a container alone is not a backup, an authentication boundary, or a remote-access policy.
Understand the deployment architecture first
A reliable deployment is easier to troubleshoot when each layer has one clear responsibility. EdgeEver runs inside Docker on your server or NAS. Docker publishes the application on a host address and port selected by the current EdgeEver deployment configuration. A browser on the local network connects to that endpoint. The Localtonet client then runs on the same machine, or on another machine that can reach that endpoint, and forwards HTTP traffic through an outbound connection.
The path for remote access is therefore:
Remote browser
|
Public HTTPS address assigned to the Localtonet HTTP tunnel
|
Localtonet relay
|
Outbound connection from the Localtonet client
|
EdgeEver local IP address and published HTTP port
|
EdgeEver Docker container and persistent storageThis design does not require an inbound router port-forwarding rule, a public IP address, firewall changes for unsolicited inbound internet traffic, or a VPN setup. It does require the Localtonet client device to remain connected and the tunnel to remain started. Stopping the tunnel or disconnecting that device makes the public tunnel unavailable without stopping the local EdgeEver service.
| Layer | Purpose | What to verify |
|---|---|---|
| EdgeEver application | Provides notes, synchronization, the web interface, and application features | The login or application page loads and normal note operations work |
| Docker runtime | Runs the application and maps persistent storage and networking | The required containers remain running and restart as intended |
| Host endpoint | Makes the containerized HTTP service reachable from the host or LAN | The configured address and published port answer locally |
| Localtonet client | Creates an outbound connection from a device that can reach EdgeEver | The selected device token is connected without exposing the token |
| Localtonet HTTP tunnel | Maps a public HTTPS address to the local EdgeEver HTTP endpoint | The tunnel is started and targets the verified local address and port |
Prerequisites and decisions to make
Use a machine on which you are authorized to run a persistent service. The official EdgeEver material identifies VPS, NAS, and home-server installations as Docker targets. The supplied project evidence does not establish a minimum CPU count, minimum memory amount, supported NAS vendor list, required Docker version, or required Docker Compose version. Check the current EdgeEver deployment instructions and the requirements of your operating system before proceeding rather than assuming compatibility.
Docker environment
Install Docker using the supported method for the host operating system or NAS. If your platform provides Docker Compose as a separate application or NAS package, ensure it is available before following a Compose-based procedure. These generic diagnostic commands can confirm whether a conventional Docker installation exposes the expected command-line interfaces:
docker version
docker compose versionThese commands do not install EdgeEver. They only report whether Docker and the Compose command are available. Some NAS products manage containers entirely through a graphical interface, so the exact validation method can differ.
Persistent storage
Decide where EdgeEver's persistent application data will live before starting the deployment. A container's writable layer should not be treated as durable application storage. The current upstream configuration should define the required volume or host-path mappings. Preserve those mappings exactly unless the current EdgeEver documentation explicitly explains how to change them.
The project documents SQLite as part of its data architecture and supports complete ZIP export. It also describes local storage and S3-compatible object storage for Docker deployments. Those facts do not establish the exact directory names, database paths, environment variables, or object-storage parameters required by the current container release. Obtain such values from the current project deployment instructions and configuration files.
Local network planning
Give the host a stable local address through a suitable local-network arrangement, such as a DHCP reservation, if other devices or a separately installed Localtonet client need to reach it. Record the actual HTTP address and published port selected by the official EdgeEver configuration. Do not infer the port from examples for another application.
Account and access policy
Determine who should be able to reach the instance and confirm the current EdgeEver authentication controls before exposing it. Notes may contain personal, business, or confidential information. If you cannot verify that the installed release protects the interface appropriately, keep the application local until you can establish a suitable access policy.
The supplied upstream evidence confirms Docker support but does not include the current Docker command, container image reference, local port, configuration variables, volume paths, initial administrator credentials, or exact local URL. These values can change between releases. This guide therefore does not fabricate them. Use the current deployment instructions linked from the official EdgeEver project and copy the exact values for the release you are installing.
Install EdgeEver with the current Docker deployment
The EdgeEver repository currently contains a Dockerfile, a compose.yaml file, environment examples, migrations, and application source. The official site also describes a single-line Docker installation for VPS and NAS environments. The actual script URL and command are not present in the supplied evidence, so reproducing or reconstructing that command here would be unsafe. A fabricated installer URL could execute unrelated code or produce a deployment that does not match the current release.
Use the following workflow to install the application while preserving the current upstream configuration. The workflow deliberately distinguishes verified preparation and validation actions from release-specific values that must come from EdgeEver's current files.
Open the current EdgeEver deployment material
Begin at the official EdgeEver website or the EdgeEver repository. Select the Docker path for a VPS, NAS, or home server. Do not follow Cloudflare deployment instructions for this workflow because that creates a different architecture.
Review the installer or Compose configuration before running it
Confirm that the material belongs to the official project, identify the image or build process, inspect volume mappings, note the published HTTP port, and review every required configuration value. If using a shell installer, read it before execution where your platform permits. Do not insert guessed values for fields the current instructions do not explain.
Prepare the documented persistent locations
Create or select the host directories, named volumes, and object-storage configuration required by the current release. Ensure the Docker service has the necessary permissions. Record which locations contain the SQLite database, attachments, configuration, and any other persistent content identified upstream.
Set only documented configuration values
Copy the current environment example if instructed and supply the values required by that release. Treat administrator credentials, application secrets, API keys, object-storage credentials, and integration tokens as secrets. Do not commit them to a public repository, paste them into support messages, or include them in a tunnel configuration.
Start EdgeEver using the documented Docker method
Run the exact installer or Compose command given by the current EdgeEver deployment guide. If your NAS uses a container-management interface, translate the documented image, volumes, environment, and port mapping into that interface without changing their meaning. The supplied evidence does not establish a safe project-specific startup command, so none is guessed here.
Record the resulting local HTTP endpoint
From the current deployment output or Compose configuration, record the host address and published port. This is the endpoint you will test locally and later enter as the target of the Localtonet HTTP tunnel. Keep the private address separate from the public URL that Localtonet assigns later.
Convenience commands that download and execute a remote script must be exact. Because the extracted evidence confirms that such an installer exists but does not provide its command or URL, presenting one would require guessing. A human editor should add the current official command only after verifying it against the active EdgeEver deployment documentation for the release covered by the article.
Verify EdgeEver locally before adding remote access
Local verification separates application problems from tunnel problems. If EdgeEver does not answer on its local endpoint, creating a tunnel will not repair the container, database, permissions, or port mapping. Complete the following checks from the host and, where applicable, from another device on the same network.
Check container state
On a conventional command-line Docker installation, the following generic command lists running containers:
docker psCompare the result with the services defined by the current EdgeEver deployment. A container that repeatedly restarts, remains unhealthy, or exits immediately requires investigation before remote access is configured. Use the container name generated by your own deployment when viewing logs. This article does not invent that name because it is not established by the supplied evidence.
Confirm the published port
Inspect the active container or the current Compose configuration and identify the host-side published port. Docker port mappings have a host side and a container side. Browsers and the Localtonet client need an endpoint that is reachable from where they run. Do not automatically enter the internal container port into Localtonet.
If Localtonet runs directly on the Docker host, test the host endpoint from that machine. If Localtonet runs on another computer, test from that computer using the server's LAN address. A service bound only to loopback may work on the Docker host but not from another device.
Open the web interface
In a browser, open the exact local URL established by the deployment. Confirm that the application page renders rather than merely checking that a TCP connection opens. Complete any documented initial setup, then sign in if the release requires it.
Perform an application-level test
Create a temporary notebook or note, enter text, save it, refresh the browser, and confirm that the content remains. If attachment upload is part of your intended workflow, test it with a non-sensitive file. Sign out and sign back in when authentication is enabled. These checks exercise more of the application than loading the first page.
Test persistence safely
Once normal operation is confirmed, perform a controlled restart using the method documented for your deployment. Verify that the application returns and that the test content remains. Persistence failure at this stage usually points to an incorrect or unwritable volume mapping, not a Localtonet problem.
A public tunnel forwards requests to the configured local target. It cannot make a stopped container start, correct an incorrect Docker port mapping, repair a database, or provide missing application authentication. Resolve the local failure first.
Routine operations, upgrades, and backups
A self-hosted notes application becomes important infrastructure as soon as it contains information you cannot easily recreate. Plan routine operations before relying on it as your primary knowledge base.
Back up both application data and portable exports
Preserve the persistent storage defined by the current Docker deployment. A backup should be stored independently of the Docker host so that a disk or host failure does not remove both the live data and its backup. Because EdgeEver supports a lossless ZIP export containing Markdown, Front Matter, attachments, nested folders, and version histories, periodic application-level exports can provide an additional portable copy.
A ZIP export and an infrastructure backup serve different purposes. The export supports portability and application-level recovery workflows. A volume or filesystem backup preserves the deployed state defined by the current installation. Use a schedule appropriate to how often the notes change, and test restoration rather than assuming a copied file is usable.
Upgrade deliberately
Before changing releases, read the release notes and current deployment instructions. Back up persistent data, record the running version, and preserve a copy of the configuration. The repository has active releases, but that does not mean every upgrade is operationally identical. Database migrations, environment variables, image tags, or container definitions can change.
Use the update procedure documented for the installed deployment method. After upgrading, repeat the local checks: container state, logs, browser access, sign-in, note retrieval, note creation, attachment behavior, and persistence after restart. Only then test the public tunnel.
Monitor storage capacity
Notes may be small, but attachments, images, exports, logs, and backups can consume significant space. Monitor both the filesystem containing persistent application data and any separate object-storage destination. Do not rely on Docker container status alone as an indication that adequate storage remains.
Know how to stop the public access separately
EdgeEver and the Localtonet tunnel have independent lifecycles. Stopping the Localtonet tunnel removes the public route while leaving EdgeEver available locally. Stopping the EdgeEver containers makes the application unavailable both locally and through the tunnel. This separation is useful during maintenance or when remote access is no longer required.
Expose the verified EdgeEver interface with Localtonet HTTP
Use an HTTP tunnel because EdgeEver provides a browser-accessible web service. Do not use a raw TCP tunnel merely because Docker publishes a port. HTTP is the application protocol being served, and our HTTP tunnel provides a public HTTPS address using a random subdomain, a custom subdomain where supported, or a custom domain.
Install the Localtonet client on the Docker host or another device that can reach the verified EdgeEver endpoint. The second arrangement can be useful on a NAS where installing additional software is inconvenient, but the separate device must remain online and retain network access to the server.
Install and run the Localtonet client
Install our client for the operating system of the device that will originate the tunnel. Run it on a device that can reach the exact EdgeEver local endpoint you already tested. Current installation options should be obtained from the Localtonet application or documentation because commands and packages can vary by operating system and client version.
Authenticate or select the client device
Use the device-specific authentication token associated with the client. Treat this token as a secret. Do not place it in the EdgeEver configuration, screenshots, shell history examples, public repositories, or support posts.
Select an available Localtonet relay server
Choose a server or region currently available in your Localtonet dashboard. Availability can vary, so this article does not hardcode a server code or geographic location.
Create an HTTP tunnel to EdgeEver
Select the HTTP tunnel family and enter the local IP address and port from the successful EdgeEver test. If the Localtonet client is on the Docker host, use the endpoint reachable there. If it is on another device, use the server's reachable LAN address and published port. Select the appropriate HTTP Process Type, such as Random Sub Domain, Custom Sub Domain, or Custom Domain, based on the currently available options.
Start the tunnel
Creating a tunnel does not start it. Press Start after reviewing the target. When the selected client is connected and the tunnel is running, Localtonet provides the public address. For the current dashboard workflow, consult our HTTP tunnel documentation.
Test the public address from an external connection
Open the assigned public URL from a device that is not relying on the same local route, such as a phone using mobile data. Confirm that the intended EdgeEver page loads, authentication behaves correctly, and a non-sensitive test note can be opened. Stop or delete the tunnel when remote access is no longer required.
EdgeEver must be running and reachable at the configured local target, and the selected Localtonet client must remain connected with the tunnel started. A locally healthy EdgeEver instance can still appear offline publicly if the client or tunnel has stopped.
Security checklist before public exposure
Publishing a private knowledge base changes its exposure. The lack of router port forwarding does not make the application private once a public URL exists. Anyone who obtains that URL may be able to send requests to it, subject to the protections configured by the application and tunnel.
The Localtonet HTTP target should be the EdgeEver application endpoint only. Never point it at a Docker API, container-management dashboard, SSH service, SQLite file, host filesystem browser, or general NAS administration interface as part of this workflow.
Troubleshooting EdgeEver and Localtonet
The EdgeEver page does not load locally
Start at the container layer. Confirm that the required containers are running, then inspect their logs using the actual service or container names from your deployment. Check for missing required configuration, filesystem permission failures, occupied host ports, database migration errors, or unavailable storage. Compare your files with the deployment material for the installed release.
Next, verify the port mapping. The browser must connect to the host-side published port, not an internal container port that exists only inside Docker networking. If you changed the current upstream mapping, return to the documented value while troubleshooting.
EdgeEver works on the server but not from another LAN device
The service may be bound only to a loopback address, a local firewall may restrict the published port, or the client device may be on an isolated network. Test the server's LAN address from the device that will run Localtonet. Do not disable broad firewall protections merely to make the test succeed. Permit only the required local communication according to your network policy.
The Localtonet tunnel starts but returns an error
Recheck the tunnel's local IP address and port from the Localtonet client device. A common architecture mistake is entering 127.0.0.1 when the client is on a different computer. On that separate computer, loopback refers to the client computer itself, not the EdgeEver server.
Also confirm that EdgeEver is serving HTTP on the selected endpoint. Do not assume a raw port is HTTP solely because a container publishes it. Use the same URL that succeeded in the browser during local verification.
The public URL is offline after a reboot
Check both independent lifecycles. EdgeEver's containers must have restarted according to the deployment configuration, and the Localtonet client must be connected. The tunnel must also be running. A tunnel can exist in the dashboard without being started.
Notes disappear after recreating the container
This strongly suggests that persistent data was written to the disposable container layer or that the replacement deployment points to a different storage location. Stop making changes, preserve the available container and filesystem state, and compare the active volume mappings with the current EdgeEver configuration. Restoring from a tested backup or ZIP export may be necessary.
An upgrade fails
Avoid repeatedly recreating containers before preserving logs and configuration. Record the old and new versions, inspect the release notes, verify whether deployment files or required settings changed, and restore from the pre-upgrade backup if the documented upgrade cannot be completed safely. Do not delete the old persistent data merely because a new container fails to start.
| Symptom | Likely layer | First check |
|---|---|---|
| No local page and container is stopped | Docker or EdgeEver configuration | Container state and logs |
| Works on host but not elsewhere on LAN | Binding, host firewall, or network isolation | Reachability from the Localtonet client device |
| Works locally but not through the public URL | Localtonet target or tunnel lifecycle | Client connection, target IP and port, and Start state |
| Public URL worked before a reboot | Automatic startup | EdgeEver containers, Localtonet client, and tunnel status |
| Content is missing after container replacement | Persistent storage | Active volume mappings and available backups |
Frequently asked questions
What port does EdgeEver use with Docker?
The supplied official evidence does not establish a specific Docker host port, so this article does not guess one. Read the published port from the current EdgeEver deployment configuration or installation output, test that exact endpoint locally, and use the verified host-side port as the Localtonet HTTP target.
Should I use an HTTP or TCP tunnel for EdgeEver?
Use an HTTP tunnel for the browser-based EdgeEver interface. The local target is the IP address and published HTTP port that succeeded during local verification. A raw TCP tunnel is not necessary for this web-interface workflow.
Does the Localtonet client have to run on the EdgeEver server?
No. It may run on the same machine or on another device that can reach EdgeEver's local endpoint. If it runs elsewhere, configure the tunnel with the server's reachable LAN address rather than the Localtonet device's loopback address.
Do I need router port forwarding or a public IP address?
No. The Localtonet client establishes an outbound connection to our relay. This allows the public URL to reach the configured local service without an inbound router port-forwarding rule, a public IP address, firewall changes for inbound forwarding, or a VPN setup.
Will the public URL work when the Localtonet client is offline?
No. The selected client device must remain connected, the tunnel must be started, and EdgeEver must remain reachable at the configured local target. Creating a tunnel does not mean it is automatically running.
Does a Cloudflare deployment of EdgeEver need Localtonet?
Generally, no. EdgeEver's Cloudflare deployment is already hosted on public serverless infrastructure. Localtonet is relevant to this guide because a Docker deployment on a private VPS, NAS, or home server can have a local HTTP endpoint that needs controlled remote reachability.
Is creating a Localtonet tunnel enough to secure private notes?
No. The tunnel provides connectivity to the configured service. You must still verify EdgeEver authentication, protect credentials and tokens, maintain updates, expose only the intended endpoint, and test what an unauthenticated visitor can access.
How should I back up a Docker-based EdgeEver instance?
Back up the persistent storage locations defined by the current Docker deployment and keep the backup separately from the host. EdgeEver also supports portable ZIP export with Markdown, Front Matter, attachments, nested folders, and version histories. Test restoration rather than relying only on the existence of a copied archive.
Connect your verified EdgeEver service with Localtonet
Once EdgeEver works reliably on its local Docker endpoint, create a Localtonet HTTP tunnel to reach that interface remotely without opening an inbound router port. Keep application authentication enabled, protect your device token, and stop the tunnel whenever public access is unnecessary.
Get Started Free →
