To add a machine to a FoundationDB cluster:

  - Choose one of the servers to start as the initial coordinator.
  - Copy the {command}`/etc/foundationdb/fdb.cluster` file from this
    server to all the other servers. Restart FoundationDB on all of these
    other servers, so they join the cluster.
  - All of these servers are now connected and working together in the
    cluster, under the chosen coordinator.

At this point, you can add as many nodes as you want by just repeating the
above steps. By default there will still be a single coordinator: you can
use {command}`fdbcli` to change this and add new coordinators.

As a convenience, FoundationDB can automatically assign coordinators based
on the redundancy mode you wish to achieve for the cluster. Once all the
nodes have been joined, simply set the replication policy, and then issue
the {command}`coordinators auto` command

For example, assuming we have 3 nodes available, we can enable double
redundancy mode, then auto-select coordinators. For double redundancy, 3
coordinators is ideal: therefore FoundationDB will make
*every* node a coordinator automatically:

```ShellSession
fdbcli> configure double ssd
fdbcli> coordinators auto
```

This will transparently update all the servers within seconds, and
appropriately rewrite the {command}`fdb.cluster` file, as well as
informing all client processes to do the same.

## Client connectivity {#module-services-foundationdb-connectivity}

By default, all clients must use the current {command}`fdb.cluster`
file to access a given FoundationDB cluster. This file is located by default
in {command}`/etc/foundationdb/fdb.cluster` on all machines with the
FoundationDB service enabled, so you may copy the active one from your
cluster to a new node in order to connect, if it is not part of the cluster.

## Client authorization and TLS {#module-services-foundationdb-authorization}

By default, any user who can connect to a FoundationDB process with the
correct cluster configuration can access anything. FoundationDB uses a
pluggable design to transport security, and out of the box it supports a
LibreSSL-based plugin for TLS support. This plugin not only does in-flight
encryption, but also performs client authorization based on the given
endpoint's certificate chain. For example, a FoundationDB server may be
configured to only accept client connections over TLS, where the client TLS
certificate is from organization *Acme Co* in the
*Research and Development* unit.

Configuring TLS with FoundationDB is done using the
{option}`services.foundationdb.tls` options in order to control the
peer verification string, as well as the certificate and its private key.

Note that the certificate and its private key must be accessible to the
FoundationDB user account that the server runs under. These files are also
NOT managed by NixOS, as putting them into the store may reveal private
information.

After you have a key and certificate file in place, it is not enough to
simply set the NixOS module options -- you must also configure the
{command}`fdb.cluster` file to specify that a given set of
coordinators use TLS. This is as simple as adding the suffix
{command}`:tls` to your cluster coordinator configuration, after the
port number. For example, assuming you have a coordinator on localhost with