Keep your prompt workspace private on the host, then publish only the access path you intend
Prompt Optimizer is a browser-based application for improving, testing, evaluating, and organizing AI prompts. This guide deploys its published Docker image with password protection, binds the web port to loopback by default, verifies the application locally, and configures a model provider. It then installs the Localtonet client as a managed Linux service and creates an HTTP tunnel without inbound router port forwarding, firewall changes, VPN setup, or a public IP address. The operational sections include reboot checks, updates, rollback, failed-update recovery, troubleshooting, and safe cleanup.
📋 What's in this guide
How the secure self-hosted architecture works
Prompt Optimizer helps turn an initial prompt into a more structured and reusable prompt. The current project describes system-prompt and user-prompt optimization, iterative improvement, analysis, single-result and comparison evaluation, context variables, multi-turn testing, function calling, prompt sources, reusable favorites, and versioned prompt assets. It also includes text-to-image, image-to-image, and multi-image workflows when a compatible model is configured.
The project supports web, desktop, Chrome extension, and Docker usage. This tutorial focuses on Docker because it is a practical deployment path for an authorized home server, lab machine, development workstation, or small office server. The container serves the web application on container port 80. We publish that port as host port 8081, but we explicitly bind it to 127.0.0.1 when the Localtonet client runs on the same host.
The distinction between 127.0.0.1:8081:80 and 8081:80 is security-critical. A mapping written only as 8081:80 normally publishes the port on every suitable host interface. That can make Prompt Optimizer directly reachable from a LAN or another connected network, independently of the Localtonet tunnel. Binding to 127.0.0.1 limits the host-side listener to the Docker host's loopback interface.
linshen/prompt-optimizer image serves the application through container port 80.
127.0.0.1:8081:80, preventing ordinary direct access through the host's LAN address.
ACCESS_PASSWORD environment variable enables Prompt Optimizer's access-control prompt.
Test these layers in order. Confirm Docker first, then start Prompt Optimizer, verify its password prompt, configure a model, and complete a non-sensitive optimization. Install and validate the Localtonet client only after the local application works. Finally, start the HTTP tunnel and test it from an external network.
Localtonet does not install Prompt Optimizer or configure its model provider. A healthy local target is required before a tunnel can carry traffic to it. Keeping installation and remote publication as separate stages also makes failures easier to diagnose.
Prerequisites and network decisions
Use a host on which you are authorized to administer Docker and install the Localtonet service. The machine must remain powered on and connected whenever remote access is required. It needs outbound internet access for image retrieval, model-provider requests, and the Localtonet client connection.
Required components
- A working Docker installation with permission to communicate with the Docker engine.
- An available local host port, using
8081in this tutorial. - A modern browser for the Prompt Optimizer interface.
- A strong, unique Prompt Optimizer access password.
- Credentials for a supported model provider if you want to optimize or evaluate prompts.
- A Localtonet account and a device-specific authentication token.
- For the managed Linux service path below, Debian 12, Ubuntu 22.04 or later, or another supported package environment with systemd 247 or newer and OpenSSL 3.
Confirm Docker is operational
docker versionA working installation should report both client and server information. If only the client appears, or Docker reports that it cannot connect to the daemon, repair Docker before continuing. Follow the host administrator's privilege model rather than weakening Docker socket permissions.
Docker administration is privileged. A user who can control the Docker engine can usually start privileged workloads, inspect container configuration, and access files available to containers. Limit Docker access to trusted administrators.
Check for an existing deployment or port conflict
docker ps -a --filter name=prompt-optimizer
docker ps
If a container named prompt-optimizer already exists, identify it before creating another one. It may be an active deployment, a stopped installation, or a previous failed attempt. Starting a new container with the same name will fail.
Docker also reports an error if another process has already bound port 8081. You can select a different unused host port, such as 8082, while leaving the container-side port at 80. Use the chosen host port consistently in browser tests and the Localtonet target.
Choose where the Localtonet client will run
| Client location | Recommended Docker binding | Localtonet target | Security consequence |
|---|---|---|---|
| Same host as Docker | 127.0.0.1:8081:80 |
127.0.0.1, port 8081 |
The application is not ordinarily reachable through the host's LAN interfaces |
| Another device on the same LAN | A specific private host address, such as 192.168.1.50:8081:80 |
The Docker host's private address, port 8081 |
The service becomes directly reachable on that interface unless network and firewall rules restrict it |
| Every suitable host interface | 8081:80 or 0.0.0.0:8081:80 |
Any reachable host address, port 8081 |
Broadest direct exposure and not recommended for this workflow |
Bind to a specific private interface instead of every interface. Restrict inbound port 8081 to the Localtonet client device with the host firewall and network controls, then test those controls from both an allowed and a disallowed device. Docker-published ports can interact with host firewall implementations in platform-specific ways, so verify the effective result rather than assuming a rule works.
Install Prompt Optimizer with a protected secret file
The current project deployment uses the linshen/prompt-optimizer image, container port 80, and the ACCESS_PASSWORD environment variable. The primary workflow below stores that variable in a root-readable environment file instead of placing the password directly in a docker run command.
Create a restricted configuration directory
Create a root-owned directory and an empty file readable only by root. This keeps the secret out of the Docker command line and ordinary shell history.
sudo install -d -m 700 /etc/prompt-optimizer
sudo install -m 600 /dev/null /etc/prompt-optimizer/prompt-optimizer.envEnter the password through an editor
Open the protected file with the administrator-approved editor and add one line in the format shown. Replace the placeholder inside the editor with a long, unique password.
sudoedit /etc/prompt-optimizer/prompt-optimizer.envACCESS_PASSWORD=REPLACE_WITH_A_STRONG_UNIQUE_PASSWORDPull the published image
Pulling separately makes registry and download failures easier to distinguish from container startup failures.
docker pull linshen/prompt-optimizerCreate the loopback-only container
Publish container port 80 only on the host's loopback address and load the access password from the restricted environment file.
docker run -d \
--name prompt-optimizer \
--restart unless-stopped \
--env-file /etc/prompt-optimizer/prompt-optimizer.env \
-p 127.0.0.1:8081:80 \
linshen/prompt-optimizerInspect startup status and logs
Confirm that the container remains running, then inspect recent application output for startup errors.
docker ps --filter name=prompt-optimizer
docker logs --tail 100 prompt-optimizerOpen the local application
On the Docker host, visit http://localhost:8081. Confirm that the application requests the configured access password.
This method avoids typing the password as a visible Docker argument, but it does not make the password inaccessible to privileged administrators. Root and users with Docker control may be able to read the environment file or inspect container configuration. Keep both host administration and Docker access restricted.
Do not add the completed environment file to a source repository, backup location with broad access, support attachment, or shell transcript. If the password is exposed, replace it in the protected file and recreate the container. Restarting the existing container does not apply changed creation-time environment configuration.
Complete Prompt Optimizer's first-run configuration
A working password prompt confirms that the web layer is available, but Prompt Optimizer still needs a model configuration before it can optimize or evaluate prompts. Open Model Manager and connect one text model that you are authorized to use.
The current project lists integrations that include OpenAI, Gemini, DeepSeek, Grok, Zhipu AI, SiliconFlow, and MiniMax. Provider availability, model names, credentials, endpoint requirements, quotas, prices, and regional restrictions are controlled by the selected provider and can change independently of Prompt Optimizer.
Enter provider credentials only in the application's intended model settings. Never put a provider key into the Localtonet dashboard, public tunnel URL, Docker image name, screenshots, or support logs. The web application stores its application data in the browser, and model requests go directly from the application to the provider you configure.
Opening the same deployment from another computer does not guarantee that the new browser already contains the models, favorites, settings, or other browser-held data created in the installation browser. Use Prompt Optimizer's supported export, import, and backup capabilities for important assets.
Run a simple functional test
Start with a non-sensitive text prompt. Select the configured model, run one optimization, and confirm that a usable result returns. This checks that the browser application loaded, the model is enabled, provider credentials are accepted, outbound provider connectivity works, and the account has access to the selected model.
Establish text optimization before testing image or advanced evaluation workflows. A complex image request can fail because of model compatibility, image preparation, input size, provider restrictions, or model selection. A basic text test gives you a simpler operational baseline.
Version-specific note for v2.11.11
The v2.11.11 release was marked as the latest release in the evidence reviewed for this revision. Its notes describe a model-selection order for analysis, evaluation, and variable generation: an explicitly selected evaluation model takes priority, followed by the global optimization model, the caller's fallback model, and the first enabled model. Deleted or disabled models are skipped, while image recognition still requires an explicitly configured and enabled model.
That release also added persisted evaluation and image-recognition settings to backup and restore, improved oversized-image preparation, and stated that no manual user-data migration was required for the v2.11.11 upgrade. These details are specific to v2.11.11. Review the current release notes before a later upgrade rather than treating those assurances as permanent behavior.
Verify local operation and unintended network exposure
Complete these checks before installing or starting the public tunnel. The objective is not only to prove that Prompt Optimizer works, but also to prove that host port 8081 is not unintentionally reachable through a LAN interface.
| Layer | Test | Expected result | Failure focus |
|---|---|---|---|
| Docker engine | docker version |
Client and server information appear | Docker daemon and account permissions |
| Container | docker ps --filter name=prompt-optimizer |
The container is running | Container logs and exit state |
| Published address | docker port prompt-optimizer 80 |
127.0.0.1:8081 is shown |
Incorrect Docker port binding |
| Local HTTP | Open http://localhost:8081 |
The password prompt appears | Application startup, mapping, or browser |
| Application function | Optimize a non-sensitive prompt | The configured provider returns a result | Model, credential, quota, or provider connection |
| Direct LAN access | Open the server's private address and port from another device | The connection fails for a loopback-only deployment | Unintended broad binding or another listener |
Inspect the exact Docker publication
docker port prompt-optimizer 80
For the same-host design, the output should identify 127.0.0.1:8081. An output such as 0.0.0.0:8081 or [::]:8081 indicates broader publication than intended. Stop and recreate the container with the loopback-only mapping before proceeding.
Test the loopback endpoint
curl -I http://127.0.0.1:8081/An HTTP response confirms that a local process answers at the target. The exact status can depend on application behavior, so verify the complete password flow in a browser as well. Use a private browsing window or a separate browser profile to avoid mistaking an existing authenticated session for a successful access-control configuration.
Confirm that the LAN path is closed
From another device on the same network, try to open the Docker host's private address with port 8081. For example, if the host is 192.168.1.50, test http://192.168.1.50:8081. A loopback-only deployment should not answer through that address.
If the application does open, do not start the tunnel yet. Recheck docker port, inspect other containers and host processes, and make sure you recreated the intended container rather than merely restarting an old one. A direct LAN listener remains reachable independently of whether the Localtonet tunnel is stopped.
Use non-sensitive prompts and redact provider keys, account identifiers, private endpoints, model responses, and the Prompt Optimizer password from screenshots. Anyone with authorized application access may be able to use provider resources available in that browser profile.
Install Localtonet as a managed Linux service
The following supported path covers Debian or Ubuntu on x64 with systemd 247 or newer and OpenSSL 3, including Debian 12 and Ubuntu 22.04 or later. Localtonet also provides packages and downloads for other Linux architectures, Fedora or RHEL, Windows, macOS, Docker, Android, and additional supported environments. Use the current Localtonet installation documentation for those alternatives.
Download the current Debian or Ubuntu x64 package
Obtain localtonet-linux-x64.deb from our current documentation page. Open a terminal in the directory containing the downloaded package.
Install the package
Install the downloaded package with the documented package-manager command.
sudo apt install ./localtonet-linux-x64.debSet and protect the device AuthToken
Edit /etc/localtonet/auth-token as root and replace DUMMY_AUTH_TOKEN with the device-specific token on a single line. Do not paste the token into a public command transcript.
sudoedit /etc/localtonet/auth-token
sudo chmod 600 /etc/localtonet/auth-tokenValidate the headless configuration
Run the documented configuration check before enabling the service. Correct token-file or configuration errors if the check fails.
sudo localtonet --headless --authtoken-file /etc/localtonet/auth-token --check-configEnable and start the service
Once validation succeeds, enable the standard tunneling service at boot and start it immediately.
sudo systemctl enable --now localtonet.serviceInspect service status and logs
Verify the systemd state and review the service journal. Avoid publishing logs if they contain device or account information.
sudo systemctl status localtonet.service
sudo journalctl -u localtonet.service
This tutorial uses the standard localtonet.service for an HTTP tunnel. It does not use the separate Localtonet VPN Manager service. Standard HTTP tunneling and VPN Manager are different product workflows.
Verify startup after a reboot
Reboot during an approved maintenance window, then check all local components before relying on remote access:
sudo systemctl rebootAfter reconnecting to the server, verify Docker, the container, the Localtonet service, and the local HTTP endpoint:
docker ps --filter name=prompt-optimizer
sudo systemctl is-active localtonet.service
sudo journalctl -u localtonet.service -b
curl -I http://127.0.0.1:8081/
The unless-stopped policy asks Docker to restart the container after Docker starts unless an administrator deliberately stopped it. It does not by itself prove that the application is healthy or that a Localtonet tunnel is running. Always test the complete path after maintenance.
Create and start the Localtonet HTTP tunnel
Once http://127.0.0.1:8081 works and direct LAN access is closed, create an HTTP tunnel. The Localtonet client establishes an outbound connection to our relay server. No inbound router port forwarding, public IP address, firewall change, or VPN setup is required for the same-host arrangement.
Open the HTTP/s tunnel page
In the Localtonet dashboard, begin an HTTP/s tunnel configuration for the Prompt Optimizer web service.
Select the process type
Choose Random Sub Domain, Custom Sub Domain, or Custom Domain as available in your current dashboard and plan. All three process types serve the HTTP target at a public HTTPS address. Check current documentation before making custom-domain DNS changes.
Select the AuthToken and relay server
Select the token for the Linux host and an available relay server from the current dashboard. Do not copy server codes from old tutorials because available values can change.
Enter the local target
When Localtonet and Docker run on the same host, enter local IP address 127.0.0.1 and local port 8081. If you intentionally selected another host port, enter that port instead.
Start the tunnel
Create the configuration and press Start. Creating a tunnel does not mean it is running. Wait for the tunnel to become active, then use the assigned public HTTPS address.
Test the public address from a device that is not relying on the Docker host's local network path, such as a phone using mobile data. Confirm that the Prompt Optimizer password prompt appears and that a non-sensitive optimization succeeds.
The tunnel remains available only while the selected Localtonet client is connected and the tunnel is running. If the server sleeps, Docker stops, the Localtonet service exits, or the tunnel is stopped, the public address cannot reach Prompt Optimizer.
Keep Prompt Optimizer's password enabled, use a unique password, and share the URL only with intended users. The tunnel supplies connectivity, not a replacement for application authentication, provider-account security, least privilege, or organizational access policy.
If Localtonet must run on another device
Loopback cannot cross machines. On a different Localtonet device, 127.0.0.1 refers to that device rather than the Docker server. You must recreate Prompt Optimizer with a binding to a specific private address owned by the Docker host, such as:
-p 192.168.1.50:8081:80Substitute the Docker host's actual stable private address. Configure the firewall and network so only the authorized Localtonet client device can connect to that address and port. Test the path from the Localtonet client, then verify that unrelated LAN devices cannot connect. Do not use a broad all-interface binding merely for convenience.
Operate, update, roll back, and clean up safely
Routine container and service commands
docker stop prompt-optimizer
docker start prompt-optimizer
docker restart prompt-optimizer
docker logs --tail 100 prompt-optimizer
sudo systemctl status localtonet.service
sudo journalctl -u localtonet.service -bFor planned maintenance, stop the Localtonet tunnel if remote users should not encounter an unavailable target. Stopping the container does not automatically delete or stop the tunnel configuration.
Prepare for an update
Prompt Optimizer's web deployment stores application data in the browser. Before changing the container, use the application's current export or backup features for important favorites, referenced resources, and settings. Protect the export because it may contain prompts, examples, media references, model configuration, or business context.
Review the target release notes for upgrade instructions. Do not assume that the v2.11.11 no-migration statement applies to later releases. Also confirm that the protected environment file and loopback binding remain the intended configuration.
Preserve the current container for rollback
Stop the public tunnel or schedule downtime, then pull the new image. Preserve the old container under a rollback name instead of deleting it immediately:
docker pull linshen/prompt-optimizer
docker stop prompt-optimizer
docker rename prompt-optimizer prompt-optimizer-rollback
If prompt-optimizer-rollback already exists, inspect and remove or archive that known object before starting. Do not delete an unidentified container.
Create the updated container
docker run -d \
--name prompt-optimizer \
--restart unless-stopped \
--env-file /etc/prompt-optimizer/prompt-optimizer.env \
-p 127.0.0.1:8081:80 \
linshen/prompt-optimizerVerify the replacement locally before restarting or relying on the public tunnel:
docker ps --filter name=prompt-optimizer
docker logs --tail 100 prompt-optimizer
docker port prompt-optimizer 80
curl -I http://127.0.0.1:8081/Open a private browser window, confirm the password prompt, sign in, verify the expected model configuration or restore browser-held data if necessary, and perform a non-sensitive optimization. Then start or test the Localtonet tunnel from an external network.
Roll back a failed update
If the new container starts but does not pass verification, stop and remove only the failed replacement, restore the previous name, and start the preserved container:
docker stop prompt-optimizer
docker rm prompt-optimizer
docker rename prompt-optimizer-rollback prompt-optimizer
docker start prompt-optimizerRepeat the local status, log, port, password, and functional tests. Restart the public tunnel only after the prior deployment works locally.
Recover when recreation fails midway
If the new docker run command fails after the old container was renamed, the preserved container should still exist under prompt-optimizer-rollback. Inspect both names:
docker ps -a --filter name=prompt-optimizerCorrect the creation error if it is safe to do so. To abandon the update, rename the preserved container back and start it:
docker rename prompt-optimizer-rollback prompt-optimizer
docker start prompt-optimizerA common recovery obstacle is a partially created replacement retaining the primary name. Inspect it first. Remove only the known failed replacement before restoring the old name.
Finalize a successful update
Keep the rollback container only for the approved validation period. Once local access, authentication, model operation, external tunnel access, and post-reboot behavior have all passed, remove the stopped rollback container:
docker rm prompt-optimizer-rollbackClean up unused images only according to your host's retention policy. Do not run broad pruning commands without reviewing what else they would remove.
Upgrade the Localtonet package
For the documented Debian or Ubuntu package path, install the new package and restart the standard tunneling service. The package workflow preserves its configuration:
sudo apt install ./localtonet-linux-x64.deb
sudo systemctl restart localtonet.service
sudo systemctl status localtonet.service
sudo journalctl -u localtonet.service -bRecheck the dashboard connection state and the tunnel after the service restart. A running systemd service does not by itself prove that a particular tunnel is started.
Safe shutdown and cleanup
When remote access is no longer required, stop the tunnel in the Localtonet dashboard. Stop the Prompt Optimizer container if the application should no longer run:
docker stop prompt-optimizerDelete the tunnel only if you no longer need its saved configuration. Before removing the container or protected environment file, export important browser-held assets and confirm that no rollback is required. Removing a container, configuration file, or browser profile can be destructive depending on where relevant data is stored.
Troubleshoot each layer independently
The container exits immediately
docker ps -a --filter name=prompt-optimizer
docker logs --tail 200 prompt-optimizerLook for image retrieval failures, invalid Docker syntax, a port collision, an unreadable environment file, or an application startup error. Do not troubleshoot the public URL until the container remains running.
Docker says the container name is already in use
A stopped container retains its name. Inspect the existing object and determine whether it is the active deployment, a rollback copy, or a failed replacement. Do not keep changing names on every attempt because that leaves several ambiguous containers behind.
Port 8081 is already allocated
Another container or host process is using the selected address and port. Stop that service if appropriate, or choose another unused host port such as 8082. Preserve the loopback address:
-p 127.0.0.1:8082:80
The local URL and Localtonet target port then become 8082. The container-side port remains 80.
The application opens on the LAN when it should not
Run docker port prompt-optimizer 80. If Docker reports 0.0.0.0:8081, [::]:8081, or a LAN address, recreate the container with 127.0.0.1:8081:80. Also check for another container or host service responding on the same port.
The application does not ask for a password
Confirm that the environment file contains the exact variable name ACCESS_PASSWORD and a non-empty value. Avoid printing the file into logs or support conversations. If you changed it after container creation, replace the container using the update procedure because a restart does not apply new creation-time environment values.
The interface works but optimization fails
Check Model Manager, the enabled model, provider credentials, account access, quota, endpoint configuration, and browser connectivity. For the v2.11.11 behavior described earlier, review the explicit evaluation model and fallback order. Image recognition requires an explicitly configured and enabled model.
The Localtonet configuration check fails
Confirm that /etc/localtonet/auth-token contains the correct device-specific token on one line and has restrictive permissions. Run the documented check again:
sudo chmod 600 /etc/localtonet/auth-token
sudo localtonet --headless --authtoken-file /etc/localtonet/auth-token --check-configDo not start the service until validation succeeds. Never paste the token into public logs or troubleshooting posts.
The Localtonet service is not running
sudo systemctl status localtonet.service
sudo journalctl -u localtonet.service -b
sudo systemctl restart localtonet.service
Review package compatibility, configuration-check results, token-file access, and outbound connectivity. The standard HTTP tunnel uses localtonet.service, not the separate VPN service.
The public URL does not load
Reconfirm http://127.0.0.1:8081 first. Then verify that the Localtonet service is active, the correct device appears connected, the tunnel target is 127.0.0.1 with the selected host port, and the tunnel has been started.
If the Localtonet client is on another device, test the Docker host's private address and port from that client device. A loopback target cannot work across machines.
The tunnel worked before a reboot
Check Docker, the Prompt Optimizer container, the Localtonet systemd service, the dashboard device state, and the tunnel state separately. The container restart policy does not start a stopped tunnel, and an active Localtonet service does not repair an unhealthy Docker target.
Frequently asked questions
Why bind Docker to 127.0.0.1 instead of using 8081:80?
A mapping written as 8081:80 can publish the service on every suitable host interface. Using 127.0.0.1:8081:80 limits the listener to the Docker host, which is appropriate when the Localtonet client runs on that same host.
How is Prompt Optimizer password protection enabled?
Set the documented ACCESS_PASSWORD variable when creating the container. This guide loads it from a root-readable environment file so the literal password is not placed in the docker run command.
Can Docker administrators still inspect the password?
Yes. The environment file prevents common command-line and shell-history disclosure, but root and privileged Docker administrators may still be able to read container configuration or the protected file. Restrict Docker and host administration to trusted accounts.
Does Localtonet replace Prompt Optimizer authentication?
No. The HTTP tunnel makes the local service reachable at a public HTTPS address. Keep Prompt Optimizer's password protection enabled and continue to secure the host, provider account, and browser-held configuration.
Do I need router port forwarding or a public IP address?
No. Our client establishes an outbound connection to a Localtonet relay server. This workflow does not require inbound router port forwarding, firewall changes, VPN setup, or a public IP address.
Can the Localtonet client run on another machine?
Yes, but Prompt Optimizer must then be reachable from that client device through a private network address. Bind Docker to a specific private interface, restrict the port to the client device with firewall and network controls, and verify that unrelated devices cannot connect.
Where does the web version store Prompt Optimizer data?
The project states that the web application stores application data in the browser and sends model requests directly to the configured provider. Different browsers or profiles can therefore have separate state. Export or back up important assets before browser changes or upgrades.
How do I verify the deployment after a reboot?
Verify the Docker container, Localtonet systemd service, local HTTP endpoint, dashboard device connection, tunnel state, public password prompt, and a non-sensitive optimization. No single restart policy proves that the entire path is healthy.
Can I use a custom domain?
HTTP tunnels support Random Sub Domain, Custom Sub Domain, and Custom Domain process types. Availability can vary by current plan or configuration. Check the dashboard and current documentation before selecting an option or changing DNS.
Publish your verified Prompt Optimizer service with Localtonet
Bind Prompt Optimizer to 127.0.0.1:8081, confirm its password and model workflow locally, then create an HTTP tunnel for remote access without opening an inbound router port.
