Build a private notes workspace at home, verify it locally, and publish only the HTTP service you intend to use
EdgeEver is an open-source notes workspace with an Evernote-style three-pane interface, SQLite-based storage, rich text and Markdown editing, revision history, exports, attachments, and AI integrations. Its official installer can deploy the Docker edition on a VPS, NAS, or home server. This guide covers the verified installation path, explains how to discover the generated local endpoint without guessing its port, and shows how to test the application before allowing remote access. Once the local deployment works, we configure a separate Localtonet HTTP tunnel so authorized users can reach it without inbound router port forwarding, firewall changes, VPN setup, or a public IP address.
📋 What's in this guide
How the EdgeEver and Localtonet architecture works
EdgeEver is a web-based, self-hosted note-taking and personal knowledge workspace. It preserves the familiar notebook tree, note list, and editor arrangement associated with classic three-pane note applications. The project supports rich text and Markdown source views, nested notebooks, revision history, public note sharing, attachments, Mermaid diagrams, single-note exports, and complete ZIP library exports. It stores its data using SQLite and offers REST API, MCP, and CLI access.
EdgeEver supports two substantially different deployment models. One model runs on Cloudflare infrastructure. The other runs the application with Docker on a VPS, NAS, or home server. This article focuses on the Docker model because that is the workflow in which the web application commonly exists only on a private machine or local network.
A Cloudflare deployment already produces an internet-accessible service and normally does not need a Localtonet tunnel. By contrast, a home-server or NAS deployment may be reachable only through a private address such as the host's LAN address. The exact address and port are deployment details that must be read from the generated Docker configuration rather than assumed.
This separation is important. Localtonet does not install, configure, or repair EdgeEver. EdgeEver must first start successfully and respond locally. The tunnel is then an access layer placed in front of that known-good service. Testing in this order makes failures easier to isolate: application problems remain application problems, while tunnel configuration can be examined independently.
The supplied EdgeEver project information confirms an official Docker installer but does not establish the container's current host port, hostname, generated directory, or exact browser URL. Read those values from the installer output and generated Compose configuration. This guide deliberately does not substitute a commonly used web port because doing so could direct traffic to the wrong service.
Prerequisites for the Docker installation
Before starting, choose the machine that will hold your notes and attachments. EdgeEver documents Docker deployments for a VPS, NAS, or home server. The appropriate choice depends on your storage, backup, availability, and maintenance requirements. A home server keeps the service physically close to you but depends on your local electricity and internet connection. A NAS may already have a storage and backup strategy. A VPS is hosted remotely and may already be internet reachable, so review its firewall and network exposure before installing anything.
The verified one-line installer uses curl, a shell pipeline, and bash. The target therefore needs an environment capable of running that command, plus a working Docker installation and permission to create and start containers. The evidence supplied for this guide does not establish a complete supported operating-system matrix or NAS compatibility list. Confirm that your exact platform can run Docker and Bash before proceeding.
| Requirement | Why it is needed | What to confirm |
|---|---|---|
| Docker-capable host | Runs the EdgeEver container and generated Compose deployment | Docker is installed, running, and available to the account executing the installer |
curl and Bash |
Downloads and executes the official installer | Both commands are available and outbound HTTPS access to the installer is permitted |
| Persistent storage | Holds the SQLite database, notes, and attachments | The selected disk has sufficient free space and is included in a backup plan |
| Local browser access | Lets you test the application before tunneling it | A browser can reach the host and the mapped port reported by Docker |
| Localtonet client device | Creates the outbound connection used for remote access | The client will run on the EdgeEver host or on a device that can reach EdgeEver over the LAN |
Plan storage and recovery before installation
A self-hosted notes application can become a primary repository for personal or business knowledge. Treat its storage as durable data rather than disposable container state. EdgeEver supports a lossless ZIP export containing Markdown, Front Matter, nested folders, relative attachment links, and version histories. That application-level export is useful for portability, but it should not be the only recovery mechanism considered for the host.
After installation, inspect the generated Compose configuration to identify which host directories or named volumes contain persistent data. Do not delete or recreate those resources until you understand their purpose. The supplied evidence does not specify their current names or paths, so this article cannot safely provide a backup command that assumes them. Record the actual values generated on your machine and include the relevant storage in a tested backup process.
Check for existing network listeners
The installer needs to publish the web application through a host port. If that port is already occupied, Docker may fail to start the deployment. Since the official evidence provided here does not state the current mapped port, inspect the installer's output rather than reserving an assumed number in advance. If startup reports an address or port conflict, use the generated Compose configuration to identify the requested mapping and investigate the conflicting listener.
Decide where the Localtonet client will run
The simplest topology is often to run our client directly on the Docker host and target the locally published EdgeEver port. Another valid topology is to run it on a separate always-on machine on the same private network. In the second case, the EdgeEver Docker port must listen on an interface reachable from that machine, and any host-level network policy must permit the connection.
Do not broaden the application's LAN exposure merely for convenience. Prefer the smallest reachable scope that supports your chosen topology. If the Localtonet client is on the Docker host, a loopback-bound application endpoint may be sufficient. If the client is elsewhere, use the Docker host's private address only after confirming that LAN access is intentional.
The official command downloads a script and sends it directly to Bash. This is convenient, but it also means the downloaded content executes immediately with your account's permissions. For a controlled environment, inspect the script first, confirm that the URL is exactly https://edgeever.org/install.sh, and avoid running copied commands from untrusted pages or messages.
Install EdgeEver with the official Docker installer
The project's documented fast path is a single installer command. According to the current EdgeEver project information, the script pulls the official image from GitHub Container Registry, generates an administrator password, creates or starts the Docker Compose deployment, and schedules daily updates.
Run the installer from an interactive shell on the selected host. Keep the terminal open and read the complete output because it may contain the generated password, deployment location, port mapping, startup status, and operational instructions relevant to that version.
Confirm Docker is available
Sign in to the VPS, NAS shell, or home server using an account authorized to operate Docker. Confirm that the Docker service is running. Resolve Docker installation or permission errors using the documentation for your exact host platform before running the EdgeEver installer.
Run the official EdgeEver installation command
Execute the project-published command shown below. Type or paste it carefully and verify the HTTPS hostname before submitting it.
Save the generated administrator password securely
The installer generates an administrator password. Capture it from the output and place it in a password manager or another appropriate secret store. Do not publish it in screenshots, shell transcripts, support requests, Compose files shared with others, or Localtonet tunnel settings.
Record the generated deployment details
Note the actual Compose location, container identity, host address, and mapped port shown by the installer or generated configuration. These details can vary, and the supplied project evidence does not establish values that are safe to hardcode.
Confirm that the Compose deployment started
Review the final installer status. If the installer reports a failed container, port collision, image-pull problem, or storage error, correct that problem before attempting remote access. A Localtonet tunnel cannot make a stopped or unhealthy application work.
curl -fsSL https://edgeever.org/install.sh | bashWhat the installation command does
The -f option makes curl fail on HTTP server errors, -s uses silent mode, -S still displays errors, and -L follows redirects. The downloaded response is passed to Bash. These are general command-line behaviors; they do not validate the contents of the downloaded script. Hostname verification and script review remain important.
EdgeEver's installer automates several tasks that would otherwise be handled manually. It obtains the official GHCR image, creates the Compose-based deployment, generates the initial administrator password, starts the application, and schedules daily updates. Because an automatic update can change application behavior, review release information and retain recoverable backups even when updates are managed for you.
Complete local health checks and a real login before creating the public tunnel. Also verify that the administrator password is private and that no unexpected setup page, debug output, or unauthenticated administrative function is reachable.
Using a manual Docker deployment
The EdgeEver project also references a manual Docker deployment guide and includes a compose.yaml file in its repository. A manual deployment can be appropriate when an administrator needs to review every image, environment value, storage mapping, network binding, and update action.
However, the evidence supplied for this draft does not include the complete current manual deployment procedure or establish its required environment variables, volume paths, image tag policy, or port mapping. Reproducing those details from assumption would create a fragile tutorial. For that reason, this guide uses the verified installer and treats the generated Compose configuration as the authority for the installation on your host.
Discover and verify the local EdgeEver endpoint
Successful command completion is not enough. Verification should confirm that a container is running, identify the real host-side port, test the HTTP health endpoint, load the browser interface, and complete an authenticated operation. These checks establish a baseline before another networking layer is introduced.
Inspect running containers and published ports
Use Docker's container listing to see running containers and their published ports. This command does not depend on knowing the generated Compose directory:
docker ps
Find the EdgeEver-related container in the output and read its PORTS column. A Docker port publication represents a host address and port mapped to a container port. Use the host-side value for local browser testing and for the Localtonet target. Do not automatically use the container-side port.
If the installer printed a Compose directory, change to that exact directory and inspect the project status:
docker compose psRun the Compose command only from the directory containing the generated Compose file, or supply the correct file through normal Docker Compose options. This article does not provide a path because the current path is not established by the supplied evidence.
Construct the local origin
An HTTP origin combines a scheme, host, and port. Use the values you actually observed. When testing in a browser on the Docker host, the host may be a loopback address if the port is bound there. From another LAN device, use the Docker host's private address if the port is listening on a reachable interface.
For illustration only, the structure is http://HOST:PORT. Replace both placeholders. They are not literal EdgeEver configuration values. If the generated deployment reports a different scheme, follow the generated configuration rather than this structural example.
Test EdgeEver's health and API description endpoints
EdgeEver's published deployment instructions identify /api/health and /api/openapi.json as verification endpoints. Append these paths to the discovered local origin:
http://HOST:PORT/api/health
http://HOST:PORT/api/openapi.jsonOpen the health endpoint in a browser or use an HTTP client available on the host. A valid application response confirms more than an open TCP port: it shows that an HTTP request reached EdgeEver. The OpenAPI document can further confirm that the API route is being served. Do not assume a particular status body because the supplied evidence does not establish its exact current JSON format.
Verify login and note operations
Open the base local origin and sign in with the administrator password generated during installation. Confirm that the workspace loads rather than relying only on a health response. Create a temporary note, edit it, refresh the page, and verify that the change persists. If appropriate for your test environment, attach a small non-sensitive file and confirm that it can be reopened.
These checks exercise authentication, browser delivery, database persistence, and basic storage behavior. Delete the temporary content when finished. Do not use private notes as troubleshooting samples, and do not test against EdgeEver's public demo because the demo resets daily and explicitly should not contain private content.
| Check | Expected evidence | If it fails |
|---|---|---|
| Container status | The EdgeEver container is running | Inspect installer output and container logs before testing networking |
| Published port | Docker reports a host-side mapping | Review the generated Compose configuration and port conflicts |
| Health route | /api/health returns an application response |
Confirm the scheme, host, port, container state, and route spelling |
| OpenAPI route | /api/openapi.json is served |
Confirm that the request reaches EdgeEver rather than another local service |
| Administrator login | The generated credentials open the workspace | Recheck the captured password without exposing it in logs or messages |
| Persistence test | A test note remains after refresh | Investigate application storage before adding real data |
Routine operation, updates, exports, and recovery planning
A self-hosted application needs ongoing care after its first successful login. At minimum, monitor storage consumption, verify that the container returns after a host reboot, preserve the administrator credential, review updates, and test recovery. Remote availability is not a substitute for those operational controls.
Starting and stopping the deployment
The official installer creates a Docker Compose deployment, but the supplied evidence does not establish its generated directory. Once you have recorded that directory, normal Compose operations can be run from it. The following commands show standard Docker Compose actions and must be executed in the correct project directory:
docker compose ps
docker compose stop
docker compose start
Use stop when you want to halt the existing containers without removing the deployment. Use start to start those stopped containers. Before using commands that remove containers, volumes, or images, understand the generated storage mappings and take a verified backup.
Reading logs safely
If the application does not start or a request fails, inspect the logs from the generated Compose project:
docker compose logsLogs may contain internal paths, hostnames, request details, or other operational information. Review them locally and redact secrets and private content before sharing an excerpt. Never include the generated administrator password, Localtonet device token, private tunnel endpoint, or personal note data in a public issue.
Understand automatic updates
The official installer schedules daily updates. Automation reduces manual maintenance, but it also creates an operational responsibility. Keep recoverable data backups, review EdgeEver release notes when practical, and verify the application after an update. A basic post-update check should include the health route, login, note loading, and a persistence test.
The exact scheduler implementation, update time, rollback mechanism, and host-specific management commands are not established by the supplied evidence. Inspect what the installer created on your machine before changing or disabling it. Do not assume that replacing a container image automatically restores an older database format.
Export the knowledge base
EdgeEver supports a lossless ZIP backup and portability workflow. The archive can contain Markdown, Front Matter, nested folders, relative attachment links, and version histories. Use this capability periodically and before significant upgrades. Store exports away from the Docker host so a single disk failure does not remove both the live data and its backup.
An export is most valuable when it can be restored. Establish a periodic recovery test using a separate, controlled environment. Verify that expected notebooks, notes, attachments, and history are present. The supplied evidence confirms export and restoration portability but does not provide enough current detail to prescribe exact UI button names or an automated backup command, so follow the options shown by your installed EdgeEver version.
Application ZIP exports support portability, while host or storage backups protect the Docker deployment itself. Where practical, use both. Keep at least one recoverable copy outside the physical host and protect backups according to the sensitivity of the notes they contain.
Expose the verified EdgeEver service with Localtonet
Add remote access only after the local endpoint passes all verification checks. With Localtonet, our client establishes an outbound connection from your device to a relay server. You do not need inbound router port forwarding, firewall changes, VPN setup, or a public IP address for this tunnel workflow.
An HTTP tunnel is appropriate because EdgeEver presents a browser-based HTTP service. The tunnel targets the local IP address and host-side port discovered from Docker. It then provides a public HTTPS address. The tunnel remains available only while the selected Localtonet client is connected and the tunnel is running.
HTTP tunnels support Random Sub Domain, Custom Sub Domain, or Custom Domain as their Process Type. All three serve the same target content through a public HTTPS address. Availability can vary by current product configuration or plan, so use the choices displayed in your dashboard. Exact custom-domain DNS instructions should be taken from current documentation rather than inferred.
Install and run the Localtonet client
Install our client on the EdgeEver host or on another always-on device that can reach the verified EdgeEver origin. Start the client and ensure that the device is connected before configuring the tunnel.
Create an HTTP tunnel
Open the HTTP tunnel configuration in the Localtonet dashboard. Use HTTP tunneling for the EdgeEver browser service rather than a raw TCP, UDP, File Server, proxy, or VPN configuration.
Select the Process Type
Choose Random Sub Domain, Custom Sub Domain, or Custom Domain from the options currently available to you. A generated address is the simplest choice when you do not need a specific hostname.
Select the device token and relay server
Select the device-specific authentication token for the connected client, then select an available server or region shown in the current product. Do not copy tokens into documentation or hardcode a relay value from another account or article.
Enter the verified local IP address and port
Use the EdgeEver host address reachable from the Localtonet client and the host-side Docker port discovered during local verification. If the client runs on the same host, use the applicable local address. If it runs elsewhere, use the reachable private address and test it from that client device first.
Start the tunnel and test the public address
Creating a tunnel does not start it. Press Start, wait for the tunnel to run, and open the assigned public HTTPS URL in a private browser session. Confirm that EdgeEver loads and requires the expected authentication. Stop or delete the tunnel when it is no longer needed.
For the current dashboard workflow, consult our HTTP tunnel documentation . Use that page to confirm any interface details that may have changed since this draft was reviewed.
Choosing the correct local target
The target depends on where our client runs. Suppose Docker reports a host-side port and the EdgeEver page works from a browser on the Docker host. A Localtonet client on that same host should target the corresponding local address and port. If our client runs on another LAN device, first open the EdgeEver origin from that exact device. Only after that direct test succeeds should the same private host address and port be entered as the tunnel target.
Do not use the public Localtonet URL as its own local target. Do not use the Docker container's internal address unless the Localtonet client is deliberately attached to a network that can route to it and you understand the lifecycle implications. The stable and readily verifiable choice is normally the published host-side endpoint shown by Docker.
Validate from outside the local network
Test the public URL from a network that is not relying on the same LAN route, such as a mobile connection. Confirm the sign-in page appears, log in with an authorized account, open a test note, and save a harmless change. Then sign out and verify that protected content is not available without authentication.
Also test failure behavior. Stop the Localtonet tunnel and confirm that the public URL no longer provides the application. Restart it and recheck access. Remember that tunnel creation and tunnel execution are separate states. A saved configuration does not mean the service is publicly reachable unless the selected client is connected and the tunnel is running.
Security practices for a remotely accessible notes service
A notes workspace may contain private conversations, credentials copied accidentally, internal documents, personal records, or business plans. Public reachability increases the importance of authentication, patching, backups, and access review. A tunnel removes the need to open an inbound router port, but it does not replace application authorization.
Do not rely on an unguessable-looking hostname as the only control. Keep EdgeEver authentication enabled, use strong unique credentials, remove unnecessary public note shares, and avoid storing secrets in notes when a dedicated secret manager is more appropriate.
Keep device tokens private
A Localtonet device token identifies the client that runs the tunnel. Treat it as a secret. Select it in the dashboard or enter it only where the official client workflow requires it. Never place a real token in a tutorial, Compose file, repository, screenshot, or support post.
Do not confuse tunneling with VPN access
This workflow publishes one EdgeEver HTTP service. It is not a general VPN into the home network. Localtonet VPN Manager is our separate private mesh VPN feature. Use the HTTP tunnel when the intended result is a public HTTPS address for this specific browser application.
Consider the scope of EdgeEver integrations
EdgeEver can integrate with AI services and MCP clients, and it can provide REST API access. Those capabilities can process or expose knowledge-base content depending on how they are configured. This tutorial does not enable an AI provider, MCP endpoint, or API automation. Review the permissions and data-handling implications separately before connecting external models, assistants, scripts, or public integrations.
Troubleshooting installation and remote access
The installer command fails immediately
Confirm that curl and Bash are installed, that the host can resolve edgeever.org, and that outbound HTTPS traffic is permitted. Check the exact command for altered punctuation or an untrusted hostname. If curl reports an HTTP error, do not bypass its failure handling by downloading from an unofficial mirror.
Docker is unavailable or permission is denied
EdgeEver cannot start until Docker works for the account running the installer. Confirm that the daemon is active and that your account has the required local permissions. Docker installation and privilege models vary by operating system and NAS vendor, and the supplied evidence does not establish one universal remediation command. Follow the platform-specific Docker instructions for your host.
The image cannot be pulled
Check outbound network access, DNS resolution, available disk space, and any registry restrictions on the host. The official installer pulls the project image from GitHub Container Registry. Preserve the exact error message, but redact environment details and secrets before sharing it.
The container starts and then exits
Run docker ps to see running containers and use the generated Compose project's logs to inspect the failure. Common categories include invalid generated configuration, unavailable storage, permission problems, and a port already in use. Do not repeatedly reinstall over persistent data until the cause is understood.
No port appears in Docker output
Review the generated Compose file and installer output. A container can be running without publishing a host port, or the application may be using a network configuration not visible as the mapping you expected. Because the verified evidence does not specify the current Compose layout, use the generated file as the authority rather than adding an assumed port.
The health endpoint works on the host but not from another LAN device
This usually narrows the problem to address binding, host network policy, or LAN routing rather than EdgeEver itself. Confirm whether Docker published the port only to a loopback address. If the Localtonet client runs on the EdgeEver host, LAN access may be unnecessary. If it runs on another device, the target must be reachable from that device without weakening unrelated network controls.
The tunnel starts but the public URL shows an error
Return to the Localtonet client device and open the exact target configured in the tunnel. If that direct request fails, correct the local IP address, host-side port, scheme, or Docker service before changing relay settings. Also confirm that the selected device token belongs to the connected client and that the tunnel has been started, not merely created.
The public URL reaches the wrong application
This indicates that the configured port belongs to another local service. Compare the tunnel target with Docker's published port and test the health route directly. The /api/health and /api/openapi.json paths help distinguish EdgeEver from an unrelated web server listening on the same host.
The public page loads, but login or saves fail
First reproduce the behavior through the local origin. If it also fails locally, investigate EdgeEver logs, storage, and authentication rather than the tunnel. If local use works but the public workflow does not, record the browser error and the affected request while keeping note content and credentials private. Avoid assuming a header, proxy, or application setting that is not documented for the installed version.
Access disappears unexpectedly
Check both parts of the lifecycle. The Localtonet client device must remain connected, and the tunnel must remain running. Also confirm that the EdgeEver container is active and that Docker still reports the same host-side mapping. A host reboot, container failure, client shutdown, or stopped tunnel can each interrupt access.
An update changes behavior
Review the installed EdgeEver version and its release notes, then test the local health endpoint, login, note rendering, attachments, and persistence. Use your recovery plan if data or functionality is affected. Do not downgrade containers blindly against an altered database. The exact supported rollback procedure is not established by the evidence supplied for this article.
Frequently asked questions
What port does EdgeEver use with Docker?
The supplied official evidence does not establish a fixed current host port. Read the installer output, run docker ps, and inspect the generated Compose configuration. Use the host-side published port rather than guessing a common HTTP port or copying the container-side value.
Can EdgeEver run on a NAS or home server?
Yes. EdgeEver documents Docker deployment for a VPS, NAS, or home server. The evidence does not provide a complete NAS model or operating-system compatibility list, so confirm that your particular platform supports Docker, Bash, persistent storage, and the official installer command.
Does the EdgeEver installer create an administrator password?
Yes. The official installer generates an administrator password. Save it securely when it appears and do not expose it in logs, screenshots, documentation, or tunnel configuration. Complete a local login test before making the service remotely reachable.
Does the official installer update EdgeEver automatically?
The current project information states that the installer schedules daily updates. The exact host scheduler, execution time, and rollback behavior are not established in the supplied evidence. Inspect the generated installation, keep recoverable backups, and verify EdgeEver after updates.
Why should I test EdgeEver locally before creating the tunnel?
Local testing proves that Docker, the application, authentication, storage, and the selected port already work. If remote access then fails, you can focus on client connectivity and tunnel targeting rather than debugging every layer at once.
Does Localtonet require router port forwarding for EdgeEver?
No. Our client establishes an outbound connection to a Localtonet relay server, so this workflow does not require inbound router port forwarding, firewall changes, VPN setup, or a public IP address. The EdgeEver service must still be reachable from the device running our client.
Is a Localtonet HTTP tunnel the same as a VPN?
No. This HTTP tunnel publishes the specific EdgeEver web endpoint configured as its target. Localtonet VPN Manager is our separate private mesh VPN capability. Standard HTTP tunneling should not be treated as general network-level VPN access.
Will the EdgeEver tunnel remain online permanently?
It remains available only while the selected Localtonet client is connected, the tunnel is running, and the EdgeEver service is reachable. Creating a tunnel does not start it. Host shutdowns, stopped containers, disconnected clients, and stopped tunnels can all interrupt access.
Should I use Localtonet for a Cloudflare-hosted EdgeEver deployment?
A Cloudflare deployment already produces an online application and generally does not need this HTTP tunnel workflow. Localtonet is most relevant here when the Docker deployment runs privately on a NAS, home server, or another host without a suitable inbound public route.
How should I back up an EdgeEver Docker installation?
Use EdgeEver's lossless ZIP export for portable copies of notes, attachments, metadata, nested folders, and version histories. Also identify the persistent Docker storage created on your host and include it in an appropriate host-level backup process. Keep a copy away from the live machine and test restoration periodically.
Connect your private EdgeEver workspace with Localtonet
Finish the Docker installation, verify the real local HTTP endpoint, and then create a focused HTTP tunnel for remote browser access without opening an inbound router port.
Get Started Free →
