BryanNet

LAN access, firewall, DNS and HTTPS

Prerequisites and authority

Local installation authority, a complete approved release package, working Docker and access to the deployment record are required. Preserve existing data before installation/update/removal.

Establish application reachability

Choose separate addresses for the API, administrator interface and entitled customer website. A private LAN deployment can use local addresses initially. Customer-facing production links and payment callbacks should use stable HTTPS names.

  1. Record the server's fixed management address or DHCP reservation.
  2. Confirm the installed application ports and host firewall rules.
  3. Test from the host, then another permitted LAN device.
  4. Configure DNS names and HTTPS through the supported proxy or tunnel.
  5. Set the deployment's public URL inputs to the actual origins and verify derived links.
  6. Recheck browser requests, login and integration redirects after changes.

The host-port defaults are API 8000, admin 5173 and customer 5174. The revised installers keep these when available and offer distinct available alternatives when a default is occupied; they do not stop the other application. Confirm and record the selected ports. They are persisted as API_PORT, ADMIN_PORT and CUSTOMER_PORT in the installed .env, and used by Control, local verification and dashboard links. Updates and rollback retain the installed choices rather than selecting new ports. Container-internal service ports remain unchanged. Platform-specific release acceptance is still required before publishing these revised instructions.

Fresh installations use HOST_BIND_ADDRESS=127.0.0.1 unless LAN listening is explicitly enabled. A loopback listener is accessible from the host or a same-host reverse proxy/tunnel, not another LAN device. Linux LAN opt-in uses 0.0.0.0; an authorized Windows administrator can explicitly configure this value in the installed .env and recreate the Compose services. Apply host firewall restrictions first and review all three listeners, especially administration. Binding to all interfaces is not an instruction to forward ports on a router. Existing installations without a bind setting retain their previous all-interface behavior on update for compatibility; review their firewall and exposure separately.

If changing an existing deployment's port manually, update its corresponding local public origin where applicable and recreate the services in a maintenance window, then verify browser requests, router/payment callbacks and ingress routes. Preserve externally configured HTTPS origins rather than replacing them with localhost URLs. A backup preserves deployment configuration, but it does not reserve ports on a replacement host.

Choose an ingress method without changing provider

BryanNet does not require Cloudflare. Use the organization's preferred persistent HTTPS tunnel, reverse proxy or hosted ingress if it provides stable routes, trusted certificates and the required access controls. Cloudflare Tunnel is one optional example in Cloudflare Tunnel for web access (not router API), not an account or vendor requirement.

A Local/LAN installation does not need to be made public merely to finish setup. Online payment webhooks require a provider-reachable endpoint; only publish the routes the chosen customer/payment workflow needs. Keep administration private by default. A domain name or DNS record alone does not connect the Internet to a service listening on localhost, and a tunnel does not resolve a local port conflict.

Responsibility and support boundary

The organization or its appointed IT provider owns its domain, ingress account, credentials, host firewall and network operation. BryanNet guidance covers the application origins, required routes, provider-event verification and application acceptance checks. It is not an included network-management, DevOps or third-party tunnel service. Use the selected provider's maintained installation and troubleshooting instructions for its infrastructure.

Assisted setup can be agreed separately when requested. Define the limited task, account ownership and handover; do not assume ongoing monitoring, DNS administration or infrastructure availability is included with the software. Never send tunnel tokens, gateway secrets or administrator passwords through a support chat.

Restrict administrator access to authorized users and paths. Keep MySQL internal and RouterOS API reachable only over management networks. A public website being accessible does not prove the containerized API can reach a router. Test that path independently.

If the interface loads but requests fail, inspect the actual API URL, HTTPS/mixed-content behavior and allowed origins. Avoid changing browser security settings to conceal an incorrect deployment configuration. A certificate warning, connection refusal and HTTP error represent different failure layers.

Related guides

Related guides: First-deployment walkthrough and success checklist, Deployment verification and first login, Back up BryanNet and validate backups, Restore BryanNet safely, Product updates, compatibility and rollback.