A thin entry point
The service entry point parses the bind address, port, and configuration path, constructs a request handler, and starts Deno's HTTP server. The default binding is loopback. Argument validation rejects invalid ports rather than allowing a later, less useful startup failure.
A separate route registry brings together configuration, repository state, revision history, routing, synchronization, and test execution. This keeps the server bootstrap readable while allowing capabilities to evolve in dedicated modules.
Expose the operational model
The inspected registry includes EC2 instances, target groups, load balancers, network interfaces, IAM inventory, and policy-document views. It also contains mutation routes, which means the distinction between reading infrastructure and changing it is a real part of the design.
Read-only inspection and operational mutations need different authority boundaries. Organizing both in one interface makes that distinction more important, not less.
Input errors are returned as structured 400 responses, while unexpected exceptions are handled separately. That distinction gives callers a clearer path to correcting a request.
Make results as explicit as actions
The route registry creates a visible inventory of capabilities, but a request still needs a configured environment and execution evidence to establish its outcome. Separating input validation, route handling, and response structure helps the interface distinguish a malformed request from an unavailable dependency or a failed operation.