Networking

Actor networking is configured with two properties:

1. Network mode (Bridge or Host)
2. Port routing (Rivet Guard or Host)

Network Modes

Bridge

Bridge networking maps a random port on the host to the chosen port number for your actor. Ports can only be access over the LAN. All inbound traffic to actors using bridge networking must be routed through Rivet Guard (see below).

Actors in bridge networking have isolated network namespaces and cannot interfere with other actor's networking.

For containers, Rivet uses CNI on our actor servers to provide bridged port access to any ports chosen by the user. It maps a randomly chosen port number on the host machine to the chosen port number by you.

Bridge networking is currently not implemented for isolates.

Host

Requires enterprise or self-hosted cluster.

Host networking allows direct access to host ports on our actor servers with the drawback that you cannot choose a specific port number. Port numbers will be randomly chosen for you for each port. To read the port number in your application, there are environment variables provided with the port name and number (ex. PORT_MY_PORT=24020).

Containers with host networking have no restriction on what ports they can listen on and connect to. This is less secure than using bridge networking.

For isolates, Rivet restricts what ports an isolate can listen on.

Host networking is sometimes required for edge cases where actors need an unrestricted amount of ports. It's up to the developer to ensure that multiple actors on the same machine do not interfere with each others' networking.

Port Routing

Rivet Guard (RG)

Rivet Guard provides DDoS mitigation, automatic SSL management, monitoring, and more out of the box with negligible added latency. Use Rivet Guard for your application whenever possible for production applications.

Rivet Guard is a system of servers that proxies end-user connections through itself before connecting to the actor servers running your application over LAN. This provides DDoS protection with little to no added latency.

Rivet Guard ports cannot be accessed from requests made directly to the actor server over WAN, only through a Rivet Guard server over LAN.

Rivet Guard routing can be used with either host or bridge network modes.

Host

Requires enterprise or self-hosted cluster.

Host ports do not provide any proxying between the end-user and your application and is not enabled on production Rivet servers. This is primarily an option for self hosting Rivet.

It recommended to use Rivet Guard whenever possible for production applications to better protect from DDoS attacks & improve monitoring of your application.

If using host ports, read about differences in behavior with actor rescheduling.

Endpoint Type

Host

The host endpoint type uses the Host header to route the request to the correct actor. This is the default & recommended method to use for production Rivet clusters.

For example, the URL c03fc1cf-66dc-4946-9663-eae42a399060-http.actor.45a33878-e0e5-4f6b-8e72-7e9f6c0a306c.rivet.run would route to the:

• Actor with ID c03fc1cf-66dc-4946-9663-eae42a399060
• Port labelled http
• Region with ID 45a33878-e0e5-4f6b-8e72-7e9f6c0a306c

If self-hosting, host endpoints requires wildcard DNS records & wildcard SSL certificates.

Path

The path endpoint type uses the beginning of the request path to route to the correct actor. This should only be used if:

• Self hosting or developing Rivet without a wildcard DNS record (e.g. Rivet Guard running on 127.0.0.1:7080)
• Rare cases where explicit hostnames need to be whitelisted (e.g. Discord Activities URL mappings)

Routing Diagram

This diagram shows how requests are routed from the end-user to the application running on Rivet based on the network mode and port routing.