> ## Documentation Index
> Fetch the complete documentation index at: https://flux-docs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Remotes

> Resolution and caching of the two underlying remote instances.

<Info>
  This module is internal. It is documented so you can reason about how Flux behaves
  and performs, but it is not re-exported from the root `Flux` module and its surface
  may change without notice. For everyday use, reach for [`Flux.Server`](/api/server)
  and [`Flux.Client`](/api/client).
</Info>

```luau theme={null}
local Remotes = require(ReplicatedStorage.Flux.Utils.Remotes)
```

The smallest module in Flux. It finds or creates the two remote instances every event travels
over, and caches them.

## RemoteGroup

```luau theme={null}
export type RemoteGroup = {
	Reliable: RemoteEvent,
	Unreliable: UnreliableRemoteEvent,
}
```

<ResponseField name="Reliable" type="RemoteEvent">
  Named `Flux_Reliable`. Carries `Fire`, `FireAll`, and all invoke traffic.
</ResponseField>

<ResponseField name="Unreliable" type="UnreliableRemoteEvent">
  Named `Flux_Unreliable`. Carries `FireUnreliable` and `FireAllUnreliable`.
</ResponseField>

***

## Remotes.Get()

```luau theme={null}
function Remotes.Get(): RemoteGroup
```

Resolves both remotes with `WaitForChild`, caches the group, and returns it.

<Warning>
  Yields until both instances exist. Called by the client through `Bridge.Initialize`, so the
  first `Flux.Client(...)` call on a client blocks until the server has created them.

  If no server code ever calls `Flux.Server(...)`, this waits forever and every client hangs.
  See [Installation](/installation#server-must-initialise-first).
</Warning>

***

## Remotes.Create()

```luau theme={null}
function Remotes.Create(): RemoteGroup
```

Finds each remote with `FindFirstChild` and creates any that is missing, then caches and returns
the group. Non-yielding and idempotent.

Called by the server through `Bridge.Initialize`.

```luau theme={null}
if not reliable then
	reliable = Instance.new("RemoteEvent")
	reliable.Name = RELIABLE_NAME
	reliable.Parent = script
end
```

<Note>
  Both functions share one `_cachedGroup`, so whichever runs first wins and the other returns the
  cache. Only one context ever calls each in practice.
</Note>

***

## Where the remotes live

<Tree>
  <Tree.Folder name="Remotes (the ModuleScript)" defaultOpen>
    <Tree.File name="Flux_Reliable (RemoteEvent)" />

    <Tree.File name="Flux_Unreliable (UnreliableRemoteEvent)" />
  </Tree.Folder>
</Tree>

<Info>
  The remotes are parented to the `Remotes` ModuleScript itself, which is `script` inside the
  module, not to a folder. That is why the module needs no path configuration: it looks for its
  own children.

  One side effect is that the instance tree in Studio shows two remotes nested under a
  ModuleScript, which looks unusual but is intentional.
</Info>

## Constants

| Constant          | Value               |
| ----------------- | ------------------- |
| `RELIABLE_NAME`   | `"Flux_Reliable"`   |
| `UNRELIABLE_NAME` | `"Flux_Unreliable"` |

<Warning>
  Renaming these instances at runtime breaks resolution. `Remotes.Create` would create a fresh
  pair alongside the renamed ones, and the two sides would end up on different remotes. Leave
  them alone.
</Warning>

## Two remotes for the whole game

However many events you declare, Flux creates exactly these two instances. The event name
travels inside the payload as a length-prefixed string, and the receiving dispatcher uses it to
find listeners.

<Tabs>
  <Tab title="Raw remotes">
    ```
    Remotes/
      Chat            (RemoteEvent)
      Damage          (RemoteEvent)
      Purchase        (RemoteFunction)
      Position        (UnreliableRemoteEvent)
      ... one per message type
    ```
  </Tab>

  <Tab title="Flux">
    ```
    Flux/Utils/Remotes/
      Flux_Reliable     (RemoteEvent)
      Flux_Unreliable   (UnreliableRemoteEvent)
    ```
  </Tab>
</Tabs>

<Note>
  There is no `RemoteFunction` anywhere in Flux. Invocations are request and response packets
  over `Flux_Reliable`, which is why they can be concurrent, why they carry an explicit request
  id, and why the timeout is Flux's own 60 seconds rather than the engine's behaviour.
</Note>

## Next steps

<CardGroup cols={2}>
  <Card title="Bridge" icon="layer-group" href="/api/internals/bridge">
    What fires these remotes, and when.
  </Card>

  <Card title="Architecture" icon="sitemap" href="/concepts/architecture">
    How the modules fit together.
  </Card>
</CardGroup>