To host a website on a local network, choose the serving machine, the address other devices will use and the access boundary before starting the server. Test from another permitted device as well as the host. Local availability, trusted HTTPS and internet exposure are separate decisions that each need an explicit check.
Begin with the intended use: a private demonstration, a shared information page or an internal application. Name the devices that should reach it and those that should not. This guide uses Caddy’s static-file and HTTPS documentation for a concrete example, with an original access-boundary worksheet. Application runtimes and user permissions need their own requirements beyond the static-file example.
What are you serving, and from which folder?
Caddy’s static-file quick-start assumes a folder containing the website. Caddy file-server can use another folder through its root option. These documented starting points make the selected folder a useful first check. Prepare a dedicated test folder containing only the material intended for the demonstration, then confirm that the configured root points there.
Caddy can display a file listing when browsing is enabled. Treat that documented option as a deliberate content decision. Ask whether visitors should see an index page or a directory listing. Inspect the actual folder before enabling browsing rather than assuming every file under a convenient working directory is suitable for other devices to see.
The Caddy quick-start supports selecting a higher listening port. Caddy must be reloaded or restarted after a Caddyfile change. Record the actual address and configuration choices used in the test. A second person needs the full intended address, including a chosen non-default port, and the server must be running the configuration you think you changed.
Which address should another device use?
Write down the host’s intended LAN address or agreed internal hostname and the port selected for the service. Have the network owner confirm the addressing arrangement. Do not copy a localhost demonstration address from the serving machine and assume that it identifies the same server on every other device.
Separate name resolution from connection testing. First confirm that the permitted client is using the intended address. Then record whether it can reach the service and which page answers. A recognisable page is more useful evidence when you can connect it to the expected folder and test version. Preserve the observation before changing network settings.
If the second device cannot connect, ask the administrator to inspect the intended listening interface, host firewall and relevant network rules. Check the specific boundary needed for the test rather than opening access broadly. Keep any router or shared-network change outside a casual file-server experiment and under the network owner’s control.
Original local-site access boundary worksheet
Consider a hypothetical office sharing a static demonstration with approved colleagues on its internal network. Guest devices and outside internet clients are not intended participants. The following original worksheet records proposed expectations; it is not a claim that a particular network enforces them.
| Test position | Intended result | Address or evidence to record | Action if the result differs |
|---|---|---|---|
| Serving machine | Test page opens from the intended folder | Local test address and visible version marker | Inspect server state and selected root |
| Approved colleague device | Same intended page is reachable | Agreed LAN address or internal name and port | Inspect addressing and the permitted connection path |
| Another approved browser | HTTPS trust behaves as agreed | Hostname and certificate observation | Review client trust setup with the administrator |
| Guest device | Access follows the explicit exclusion policy | Controlled test result approved by network owner | Review the relevant boundary without widening it |
| Outside network | No access under this internal-only brief | Authorised observation of the exposure plan | Investigate unexpected public exposure |
| Retired demonstration | Access ends according to the closure plan | Server state and follow-up request | Stop the intended service and recheck |
Use a simple version marker in the fictional demonstration so the reviewer can tell which copy answered. Keep real customer files, credentials and unrelated working documents out of the served folder. Record the folder contents before testing. This helps the team review content exposure alongside the network boundary.
Complete the approved-device row before inviting a wider group. Give the tester the precise address and ask them to report the observed page, not merely “it works”. If the name and address routes differ, keep both observations so the administrator can investigate resolution separately from serving the file.
The exclusion rows are as useful as the successful-access row. Agree a safe test with the network owner and record the expected boundary in advance. If a guest or external device can reach the site unexpectedly, pause the demonstration and investigate that scope. Do not accept broader reach as an incidental convenience when the brief is internal-only.
How does local HTTPS affect other devices?
For non-public HTTPS sites, Caddy can create its own certificate authority. Clients that do not trust Caddy’s root CA show security errors. The automatic HTTPS documentation therefore makes trust on the viewing devices a separate concern from successfully opening the site on the server itself.
Automatic installation of Caddy’s root into local trust stores is not guaranteed. Caddy local HTTPS does not use ACME or perform DNS validation. These documented conditions should guide the administrator’s trust plan. Ask which approved clients need the local CA and how its trust is managed, rather than instructing colleagues to ignore certificate warnings.
Caddy’s DNS certificate challenge does not require the web server to be externally accessible. That documented alternative is useful when discussing a publicly trusted certificate for a domain while maintaining a separate access boundary. It still needs the appropriate DNS setup and permissions. Certificate validation and permission to expose an internal site remain different decisions.
Add a simple addressing diagnostic to the approved-client row. Give the tester the agreed internal name and, separately, the administrator-approved LAN address for the same service. Record each result without treating a certificate mismatch on a different name as permission to bypass the trust plan. If only one route works, preserve that difference for the administrator. The purpose is to identify the unresolved part of the route, not to accumulate alternative addresses for colleagues to try at random. Finish by writing one approved address in the handover so future viewers have a clear, maintained entry point.
What should happen when the demonstration ends?
Include a closure owner and a clear intended end state in the worksheet. The owner should stop the intended demonstration service, verify the follow-up access result and review any temporary network or trust changes through the agreed administrative process. Avoid leaving a forgotten file-serving process as the permanent answer to an internal application requirement.
If the site must remain available, create a separate operational brief covering access, updates, backups, monitoring and recovery. Test those arrangements before relying on the site for ongoing work. A one-machine demonstration can establish a useful local viewing route without establishing the whole operating model for a business service.
For the wider requirements, see hosting, domains and web development. To discuss a local service, get started with the access worksheet and the intended users. The completed brief should make the permitted reach, address and trust plan clear before anyone changes public exposure.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.