Self-Host Norish and Share Recipes with Localtonet

What is verified, and what this guide can deliver

The official Norish repository identifies the project as a real-time, self-hosted recipe application for families and friends. The specific release evidence available for this guide identifies rc-v0.26.0-beta, associated with commit e59d0a1. That establishes a release identifier, not that this release is currently recommended, nor that a particular deployment configuration is supported.

The available repository extract does not contain the deployment instructions or complete Compose definition. Consequently, we cannot validate a current installation against a release or commit, provide an exact authoritative deployment-file link, or claim to have tested Norish through our platform. Rather than reconstruct missing configuration, this revision narrows its scope to deployment assessment and conditional remote-access testing.

Earlier installation claims about norishapp/norish, postgres:17-alpine, norishapp/obscura, valkey/valkey:9, a 3000:3000 mapping, and the variables AUTH_URL, MASTER_KEY, and OBSCURA_CDP_TOKEN are not revalidated by the supplied primary evidence. They are therefore not used here as installation instructions. The same applies to previously suggested secret-generation commands and service relationships. Do not build a deployment by copying those names into a new Compose file.

Separate the three readiness checks

These checks are independent. A healthy local installation can still have incorrect public redirects. A working tunnel can deliver an application error. A successful sign-in can still leave private recipes accessible to the wrong account. Complete each check deliberately rather than treating a loaded homepage as proof of readiness.

Prerequisites for assessing an existing deployment

Use a host that can remain online whenever access is needed. The application, its dependencies, the Localtonet client, and the tunnel are separate parts of the availability chain. Suspending a laptop or stopping Docker can interrupt the application even if the public tunnel configuration still exists.

Before proceeding, prepare:

• A working Norish installation with its exact release or commit recorded.
• The actual deployment configuration and the instructions that apply to that version.
• Administrative access to inspect the deployment without sharing credentials.
• A known local HTTP endpoint, including the host address and published port.
• A non-sensitive test account and test recipe, where the installed application supports them.
• A Localtonet account and a client on a device that can reach the web endpoint.
• An external test connection, such as a phone using mobile data.

Record the configuration you actually run

Do not assume a web port, image tag, database version, or storage location from an older article. Record the application image and version, supporting services, published web port, persistent mounts, configuration files, required secret locations, and startup method. Keep secret values out of this inventory; record their secure storage location instead.

If your installation uses Docker Compose, the following are general inspection commands, not Norish installation commands. Run them from the existing project directory, with any file-selection or project options normally used by your deployment:

docker --version
docker compose version
docker compose config --services
docker compose config --images
docker compose ps

The first two commands identify the installed tools. The next two show the services and images described by the resolved Compose configuration. The last shows project container status. If Compose cannot resolve the file because required variables are missing, recover the correct environment or deployment invocation before continuing.

A full docker compose config can help inspect mounts, ports, dependencies, and restart policies, but its output may contain interpolated credentials. View it privately. Do not paste the complete result into a public issue or upload it as an unredacted diagnostic attachment.

For a new installation, resolve the missing prerequisites first

The missing Norish deployment evidence includes supported host architectures, required resources, the complete service definition, secret formats, persistence paths, initialization behavior, and the release-specific startup sequence. This guide does not substitute generic Docker commands for those requirements. The repository link above is a project entry point, not a claim that its visible extract supplies an executable installation procedure.

Verify the local application before adding a tunnel

Local verification separates application failures from networking failures. Start with the existing project's service status, then inspect recent logs:

docker compose ps
docker compose logs --tail=100

A running container is not necessarily a healthy application. Look for repeated restarts, unsuccessful initialization, dependency connection errors, or permission failures. If health checks are defined, review them, but do not assume every service has one. Avoid changing configuration solely to make a status label look healthy.

Test from the Localtonet client's network location

The tunnel target must be reachable from the device running our client. If the client runs directly on the same host as the web service, a loopback address may be appropriate. If it runs on another LAN device, use the server's reachable private address. If it runs inside a container, 127.0.0.1 refers to that container's network environment, not automatically the Docker host.

The following shell example prompts for your verified endpoint instead of assuming a Norish port. Enter a full local HTTP URL, including its port:

read -r -p "Verified local web URL: " LOCAL_WEB_URL
curl --connect-timeout 5 --max-time 20 -v "$LOCAL_WEB_URL"

This example uses Bash and requires curl. Run it on the client device or in the network environment where the client will operate. Do not include passwords or tokens in the URL. Verbose output can contain response cookies or other sensitive information, so redact it before sharing.

A connection refusal suggests no listener at the selected address and port. A timeout suggests a reachability or service-response problem. An HTTP response proves that a server answered, but its status and content still matter: an error page is not a successful functional test.

Test a representative recipe workflow

Open the same endpoint in a browser. Complete the account flow supported by your installation, load the main interface, create or view a non-sensitive recipe, navigate away, and reload it. Where supported, test an edit and confirm it persists. Then sign out and inspect what remains visible to an unauthenticated visitor.

Record the hostname used during these tests. On another person's device, localhost refers to that person's device. A link or callback pointing there will not reach your server. Local success is a baseline, not evidence that the application accepts a public hostname.

Create, start, test, and retire the HTTP tunnel

With Localtonet, the client establishes an outbound connection to one of our relay servers. A running HTTP tunnel supplies a public HTTPS address for the configured local web target. This does not require inbound router port forwarding, a public IP address, or VPN setup. It does not bypass authorization or organizational network policy.

The workflow below follows our documented common tunnel lifecycle. See the Localtonet HTTP tunnel documentation for the current HTTP-specific interface. The supplied evidence does not include a live dashboard retest or operating-system installation commands, so this guide does not claim those were performed or invent them.

Verify the start and stop behavior externally

Disable Wi-Fi on a test phone and open the exact HTTPS address. Confirm that the response comes from the intended application, not merely that some page appears. A browser can display cached content, so use a fresh navigation and, where appropriate, a harmless read request rather than relying on a previously loaded screen.

After stopping the tunnel, repeat a fresh request. It should no longer retrieve the application through that tunnel; the precise error response is not specified here. The local application can remain available because stopping a tunnel does not stop its containers. Deleting the tunnel configuration also does not delete Norish data or revoke application sessions.

If remote access still works, investigate another tunnel, reverse proxy, router mapping, or public endpoint. Retiring one route does not close other routes. For repeat testing, start the intended configuration again and verify the address currently shown instead of assuming it has remained unchanged.

Validate the canonical URL, authentication, and browser behavior

The canonical public URL is the address the application is intended to use for externally visible links and authentication flows. Its scheme, hostname, port, and sometimes path can matter. Public HTTPS and local HTTP are different origins even when they ultimately reach the same application.

No exact Norish setting for this configuration is verified here. In particular, changing a variable named AUTH_URL is not presented as a complete fix. Obtain confirmation for your installed release covering the canonical URL, supported proxy behavior, callback registration, allowed origins, and session-cookie handling. If that confirmation is unavailable, keep family sharing on hold.

Use a fresh browser session

Test with a private browser window so that old local cookies do not hide a problem. Sign in through the public address, navigate to a test recipe, reload, edit it if permitted, and sign out. Open a protected link again after logout. If the installed application supports invitations, generated share links, uploads, or live updates, test each feature that your household intends to use.

Where multiple accounts are supported, test with a second account that should not have access to private content. Confirm actual access denial rather than only the absence of a link in the interface. A hidden menu item is not proof of server-side authorization.

Inspect failures without weakening controls

Browser developer tools can reveal redirect destinations, rejected cookies, failed requests, and mixed-content errors. Look for requests to local addresses, unexpected HTTP URLs, and origin failures. Protect any captured diagnostics: request headers, cookies, callback parameters, and response bodies may contain credentials or private data.

Do not resolve a failed test by disabling origin validation, broadly trusting forwarded headers, permitting every callback URL, or exposing internal services. Those changes can trade an obvious functional failure for a less visible security failure. Correct the release-specific application configuration, then repeat the full test.

Routine operations, backup readiness, and recovery

The commands in this section describe general Docker Compose behavior for an existing, validated project. They do not establish Norish's supported deployment or migration process. Run them using the same project directory, environment, and options used for the original deployment.

Status and logs

docker compose ps
docker compose logs --tail=100
docker compose logs -f

Use status and recent logs before restarting services. Follow logs while reproducing a failure, then press Ctrl+C to stop the log viewer. That does not stop the containers. Redact diagnostics before sharing them.

Stop, start, and restart

docker compose stop
docker compose start

These commands stop and start existing project containers. Stopping the application makes its local endpoint unavailable even if the tunnel remains running. For a deliberate maintenance window, stop the tunnel first and verify the application locally before reopening remote access.

docker compose restart

A restart restarts existing containers; it does not apply changed Compose environment settings. Compose deployments commonly use docker compose up -d to reconcile changed configuration, potentially recreating containers, but that is not a substitute for the Norish release's documented change or upgrade sequence.

Restart after reboot

Detached execution does not by itself prove automatic startup after a reboot. Verify the Docker daemon's boot behavior, the actual container restart policies, and the supported persistent startup method for the Localtonet client on your operating system. No universal service-install command is supplied here because those details are not established by the evidence.

During a planned maintenance window, reboot the host and repeat the local and external verification tests. Check Docker first, then the application and dependencies, then the Localtonet device connection and tunnel state. Record any manual recovery actions. Do not promise unattended availability until this test succeeds.

Back up the complete recovery set

The available evidence does not establish Norish's database backup commands, attachment paths, volume names, or restore ordering. A generic archive command would therefore risk omitting essential data or copying a live database inconsistently.

Before storing important recipes, identify the persistent state in your actual deployment and obtain the release-supported backup procedure. Your recovery plan should account for:

• Database contents using a consistency-preserving backup method.
• Uploaded files and other persistent application data, if present.
• Compose files, environment files, and deployment-specific configuration.
• Required secrets, stored securely with appropriate access restrictions.
• The exact application and dependency versions needed to restore the backup.

Test recovery on an isolated deployment with its public tunnel stopped. Restore using the confirmed procedure, verify account access and representative recipes, and check attachments where applicable. Record which backup was restored and how long recovery took. A container restart is not a restore test, and a directory copy is not automatically a complete backup.

Upgrade and rollback

No supported Norish upgrade or rollback sequence is established here. Before changing versions, record the current images, preserve configuration and backups, review the target release's migration requirements, and rehearse the change on an isolated copy. Do not assume that pulling newer images is sufficient.

Rollback may require restoring the matching pre-upgrade data as well as the previous application version. An older image may not understand a migrated database. Retain a known-good recovery set and obtain explicit compatibility guidance before attempting an in-place downgrade.

Security checklist before inviting family members

A tunnel changes who can reach the web service. It does not replace Norish's account model or make the application inherently safe. Keep test exposure short and use non-sensitive content until the public configuration is confirmed.

• Expose only the web endpoint. Do not publish databases, cache services, browser automation services, Docker sockets, or administrative interfaces simply to make the recipe UI work.
• Use least privilege. Confirm account permissions and use strong, unique credentials wherever supported. Apply suitable access restrictions where available without assuming every plan or application includes them.
• Protect secrets. Keep device tokens, application keys, database passwords, and session material out of repositories, screenshots, and public logs.
• Review data sensitivity. A recipe service can contain names, photographs, dietary restrictions, schedules, and private notes.
• Maintain the complete stack. Review host, container runtime, application, dependency, and client updates rather than treating HTTPS as a substitute for maintenance.
• Assign responsibility. Decide who manages accounts, backups, updates, incident response, and service outages.

Family members need the public application address and whatever application access is appropriate. They do not need your Localtonet device token or host administration credentials. If a secret is exposed, stopping the tunnel is useful containment, but it does not invalidate the secret. Follow the relevant credential replacement or revocation procedure separately.

Troubleshoot by layer

The local connection is refused or times out

Check the actual published web port, container status, and logs. Confirm that your command targets the intended project and that another process has not occupied the port. Test from the client's network location. Do not add a tunnel until this path works.

The local page works, but the public URL fails

Confirm that the selected client is connected, the tunnel is started, and its IP and port match the successful local test. A configuration can exist without running. Check whether loopback points to the wrong machine or container before changing application settings.

Sign-in returns to localhost or loops between pages

Inspect the redirect chain and obtain the release-supported public URL, callback, and proxy configuration. Do not assume one environment-variable change resolves all three. Keep the deployment out of family use until a fresh external sign-in and sign-out succeed.

The homepage loads, but editing or other actions fail

Repeat the action locally and inspect application logs alongside the browser's network panel. A failure in both locations points toward application or dependency behavior. A public-only failure warrants investigation of origins, cookies, generated API URLs, and proxy handling. Neither result justifies publishing extra internal ports.

The service disappears when a terminal closes

Determine which process stopped. Containers, an interactive application process, and the Localtonet client have separate lifecycles. Use supported persistent operation for each component. Do not infer client persistence from Docker's detached mode.

Access still works after stopping the tunnel

Rule out cached content with a fresh request, then check for other public routes. Stopping one tunnel closes that route, not every possible network exposure. If sensitive content was reachable unexpectedly, investigate authorization and credential exposure as well as connectivity.

Frequently asked questions