Skip to content

Clarification needed: How is Network Utilities Service intended to be deployed? #1

Description

@fred-head

Hello,

first of all, thank you for maintaining your IT-Tools fork and the Network Utilities Service. I really like the additional networking features compared to the original IT-Tools project.

While trying to set up the WHOIS and DNS tools, I ran into a few questions and I could not find documentation that explains the overall architecture.

From my testing, it appears that IT-Tools performs requests directly from the browser to the Network Utilities Service rather than proxying them through the IT-Tools backend. This raised a few questions:

  • Is this the intended architecture?
  • Is the Network Utilities Service expected to be publicly reachable via HTTPS?
  • Is the service URL stored locally in the browser (Local Storage), or centrally on the server?
  • How should administrators deploy this for multiple users?
  • Is there a recommended setup using Docker Compose and a reverse proxy?
  • What is the purpose of the "Basic Authentication" field in IT-Tools? Does the Network Utilities Service support authentication natively, or is this intended for use behind a reverse proxy?

One thing that confused me is that the default URL is set to http://localhost:8000. This seems difficult to use in a multi-user environment because each user would need to configure the service URL manually, and browsers will block HTTP requests from an HTTPS-hosted IT-Tools instance due to mixed-content restrictions.

As a self-hosting administrator, I would have expected one of the following approaches:

  • A server-side environment variable such as NETWORK_UTILS_URL that can be configured once by the administrator.
  • A centralized application setting stored by the IT-Tools instance and shared with all users.
  • A backend proxy approach where IT-Tools communicates with the Network Utilities Service internally, avoiding browser-side networking, CORS, DNS resolution, and mixed-content issues.

At the moment, it seems that every user must know and configure the service URL individually. This can be confusing in shared deployments and makes it difficult to provide a seamless experience for less technical users.

Could you clarify whether this behavior is intentional, or if there are plans for a more centralized configuration mechanism in the future?

Would it be possible to add more documentation or deployment examples for common self-hosted setups?

Thank you for your work and for any clarification you can provide.

Best regards

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions