Support Network Ingress

[markovejnovic]

One core use-case for VMs is to serve small, on-demand compute. Often people will run HTTP servers that need to be reachable from the wider internet. Unfortunately, Hyper does not support network ingress, which means that this use-case is not served.

Obviously this is less-than-ideal, since we do need to support the common case.

I do not know what this is supposed to look like. There is a large amount of work in architecting this system.

[spunkedy]

Staying in the Beam, something like https://github.com/chrismccord/reverse_it with a registry wouldn't be hard,

[jrimmer]

I wonder if enabling network ingress too fundamentally changes Hyper's mission? After implementing a proxy to support Foregejo's PR reviews in Hyper, I've been mulling over a design with GLM-5.2 for HTTP and SSH proxies and asked my toaster to describe it.

Context
This proposes adding network ingress to Hyper: letting external traffic reach a microVM directly. It's labeled design-proposed (not approved), depends on #75 (Networking Refactor) which is a full rewrite of the networking stack, and the maintainer admits: "I do not know what this is supposed to look like."

I suggest the use cases hyper#74 targets can be delivered sooner and more securely through proxy layers alongside the orchestration API, with no changes to Hyper's networking.

The argument
Hyper runs on bare metal. Its networking model: VMs on a private network, no inbound traffic, is a feature: strong isolation by default. Adding ingress rethinks TAP devices, IP allocation, routing, and firewalling across the entire stack. That's a platform networking project, not a microVM orchestration feature.

The capabilities users want: viewing a web server in a VM, terminal access, file transfer, don't need the VM to be directly reachable. They need a proxy that sits alongside the API, translates between public protocols and the private VM network, and routes using a session registry it already maintains. That proxy runs on the host or a separate machine — not inside Hyper.

Two proxy capabilities
HTTP — .web.hyper.site.com
Issue #8. Wildcard-subdomain HTTP proxy for web servers running inside session VMs.

Browser → Caddy (wildcard TLS) → Proxy (session→VM lookup) → VM private IP (forward HTTP/WS)

Port registration via explicit API (POST /v1/sessions/{id}/ports), guest agent auto-detection (/proc/net/tcp scan), or exec-based detection. Caddy handles TLS and WebSocket upgrades. VM stays on the private network.

From my reading, I believe this is how Replit (.repl.co), Codespaces (port forwarding), and Gitpod (.ws-proxy.gitpod.io) work.

An important "feature" is that this doesn't require a Hyper code change.

[jrimmer]

Another idea occurred to me which I shared with my toaster: Pluggable protocol support in Hyper. Obviously this will require a code change but it supports all the isolation principals similar to the other suggestion. Here's how my toaster described it:

An alternative to #74: instead of per-VM ingress (which requires rethinking TAP devices, IP allocation, routing, and firewalling across the entire networking stack), Hyper could expose a pluggable proxy interface, a single set of proxy ports (80/443, 22, etc.) where protocol-aware plugins handle connection routing.

Plugins are sidecar processes that Hyper launches and manages. Each plugin registers for a protocol (HTTP, SSH, TCP, custom) and receives incoming connections. The plugin owns the routing logic, it reads a route key from the connection (HTTP Host header, SSH username, etc.), resolves it to a VM via a simple route_key → vm_id lookup that Hyper provides, and forwards to the VM's private IP. VMs stay on the private network. No per-VM public IPs, no TAP changes, no networking rewrite.

This turns #74 from a networking-stack overhaul into an extension-point addition. HTTP and SSH proxies become reference plugins — 12345.web.hyper.site.com routes via the HTTP plugin's Host-header parsing, ssh 12345@ssh.site.com routes via the SSH plugin's username parsing. New protocols are new plugins, not core changes. Hyper stays focused on microVM orchestration; proxying is opt-in and protocol-pluggable rather than baked into the networking layer. The result is the same user-facing capability: public URLs and terminal access for VMs, delivered with a fraction of the architectural cost, and extensible to other protocols.