Elm ports automatic public export and internal visibility boundary

Direct answer

No. In current Elm releases, there is no documented way to restrict port visibility. Every port declared in a port module is automatically exported and becomes accessible to JavaScript consumers through the application instance. The compiler offers no configuration, annotation, or module boundary to treat ports as private.

Why module boundaries do not help

The exposing clause in an Elm module governs only Elm-to-Elm imports. It has no effect on JavaScript accessibility. A port omitted from a module's exposing list remains fully reachable from JavaScript via app.ports. Separating ports into different modules does not create a permission boundary; all ports in the compiled program remain exposed.

Recommended architectural boundary

Because the compiler cannot enforce privacy, the boundary must be architectural:

1. Keep the port surface minimal and avoid implementation-only ports where possible.
2. Isolate public ports in dedicated modules for logical clarity, even though this does not enforce a security boundary.
3. Wrap the Elm app instance in JavaScript so that only approved entry points call app.ports. Treat this wrapper as the permission boundary.
4. Validate all incoming port messages in Elm update functions, since JavaScript can invoke any declared port regardless of module structure.

Verification

To confirm this behavior, create a small port module with two ports, compile with elm make, and inspect app.ports in the browser console. Both ports will be accessible. In a multi-module project, initialize the app and enumerate app.ports to verify that ports declared outside the main module are still exposed.

The design keeps the module system simple at the cost of JavaScript-side privacy. Plan your interop surface accordingly.