Decide what belongs on the public side.

1. Describe the person and the task.

For each service, finish this sentence: “A person in this role needs to perform this action from this kind of device.” Reading a public timetable, editing an internal procedure and maintaining a database are different tasks. Avoid making a service public simply because one volunteer needs occasional remote access.

Separate network access from application authorization. Reaching a login page is not permission to read member files. Conversely, hiding a service behind a private network does not decide which members can edit or export its content. Record both layers and the process for removing access when someone leaves.

Keep account recovery in the same discussion. A private service that only one person can unlock creates a different failure, even if its initial access rules look restrictive.

2. Fill in a small access matrix.

Here is a hypothetical community-workshop setup. The choices are examples for discussion, not a ready-made network design.

Write the actual mechanism beside each row: application accounts, an approved private access method, or another documented control. “Private” without a mechanism and a test is only a label.

3. Review the paths around the login page.

List the reverse proxy, application listeners, database ports and administration tools. An application can have a carefully configured login screen while a different interface remains reachable. Inspect the deployed configuration before changing it, and keep a recovery path for anything that controls remote access.

Docker deserves a separate check when it is part of your setup. A port mapping without an explicit host address normally publishes on all host addresses. A loopback binding limits access in the documented default NAT case, but network mode, direct routing and older Docker behavior matter. Read the documentation for the actual topology, then verify reachability over the IPv4 and IPv6 paths you use. Docker port publishing and mapping.

4. Check effective controls, not reassuring labels.

Inspect the firewall together with the software that creates network rules. Docker documents that published container traffic can be diverted before the usual UFW input rules apply. A clean-looking UFW status therefore does not prove a container port is inaccessible. Do not disable Docker’s firewall management as a quick fix; the documentation describes networking consequences. Docker packet filtering and firewalls.

Check application roles separately. For example, BookStack combines role abilities and permits content-level overrides, so a user’s effective permissions may differ from the name of one assigned role. Review the complete assignment and test representative pages and attachments. BookStack permission rules.

5. Keep transport and trust in the plan.

A service restricted to members still carries credentials and private content. Plan HTTPS and certificate trust for the actual clients instead of teaching members to ignore browser warnings. Keep certificate renewal ownership and failure checks in the notebook alongside domain access.

Caddy’s documentation distinguishes public certificate validation from its local certificate authority. A client must trust the local authority to use its certificates without warnings. For public certificates, HTTP and TLS-ALPN validation need their respective inbound paths; DNS validation is a separately configured alternative. Choose a method that fits the intended access boundary. Caddy automatic HTTPS and local trust.

This is an access-planning step, not a claim that a certificate alone makes an application private or appropriately authorized.

6. Test both the allowed and denied paths.

Use separate browser sessions for a signed-out visitor, an ordinary member and an editor. Check a normal page, a direct local attachment URL, an export action and an administration route. Re-test after removing an account or changing its role. Record the expected result before trying the action so an unexpected success is not mistaken for convenience.

From networks you are authorized to use for testing, verify that the public service is reachable and the intended private interfaces are not. Test the relevant address families and actual endpoint, not only a hostname that may resolve differently. Record the date, source network and outcome. These checks must be performed on your setup; none are claimed as completed here.

Test a confidential embedded image by its direct URL while signed out and with an unauthorized member. BookStack images are public by default, unlike local attachments; a restricted page alone is insufficient. Review image security and the storage and permission distinctions in the access guide before accepting the boundary.

7. Treat a failed boundary as a decision to revisit.

If an unauthorized account can read data, stop expanding access and inspect role inheritance, shares and direct file paths. If a private port is reachable, review its binding and network rules before adding another layer by guesswork. If the intended maintainer cannot connect, use the documented recovery route instead of granting everyone broader access.

Put the corrected rule and a repeatable check in the access notebook. Link it to the service inventory and recovery exercise. These boundaries reduce unwanted access when correctly implemented; they do not promise anonymity or remove the need for updates and careful data handling.