Managed FoundationDB clusters with mTLS isolation
Spin up an isolated FoundationDB cluster in seconds. Each project gets its own FDB instance with TLS encryption and certificate-based authentication.
One command to create a project with all certificates:
curl -sL https://dirt.cloud/init.sh | bash
This generates certificates, creates a project, waits for the cluster, and prints a ready-to-use fdbcli command. Files are saved to /tmp/dirt-{project_id}/.
The script above will tell you what's missing. To install manually:
# macOS (Apple Silicon)
brew install jq # or: apt install jq
curl -LO https://github.com/apple/foundationdb/releases/download/7.3.43/FoundationDB-7.3.43_arm64.pkg
sudo installer -pkg FoundationDB-7.3.43_arm64.pkg -target /
# macOS (Intel)
brew install jq
curl -LO https://github.com/apple/foundationdb/releases/download/7.3.43/FoundationDB-7.3.43_x86_64.pkg
sudo installer -pkg FoundationDB-7.3.43_x86_64.pkg -target /
# Ubuntu/Debian
sudo apt install jq
curl -LO https://github.com/apple/foundationdb/releases/download/7.3.43/foundationdb-clients_7.3.43-1_amd64.deb
sudo dpkg -i foundationdb-clients_7.3.43-1_amd64.deb
Note: Clusters use IPv6 addresses. Ensure your client has IPv6 connectivity.
If you prefer to run each step yourself:
1. Generate certificates:
# Create CA
openssl req -x509 -newkey rsa:2048 -nodes \
-keyout ca.key -out ca.crt -days 365 -subj "/CN=my-project"
# Create server cert
openssl req -newkey rsa:2048 -nodes \
-keyout server.key -out server.csr -subj "/CN=server"
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out server.crt -days 365
# Create client cert (for connecting)
openssl req -newkey rsa:2048 -nodes \
-keyout client.key -out client.csr -subj "/CN=client"
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out client.crt -days 365
2. Create a project:
curl -k -X POST https://fdb.dirt.cloud:8443/projects \
-H "Content-Type: application/json" \
-d "$(jq -n \
--arg ca "$(cat ca.crt)" \
--arg cert "$(cat server.crt)" \
--arg key "$(cat server.key)" \
'{tls: {ca_cert: $ca, server_cert: $cert, server_key: $key}}')"
# Response: {"project_id":"abc123","expires_at":"...","ready_in":"90s"}
3. Get your cluster file (requires client cert):
curl -k --cert client.crt --key client.key \
https://fdb.dirt.cloud:8443/projects/abc123 > fdb.cluster
# Contents: abc123:abc123@[2600:1900:...]:4500:tls
4. Wait for cluster and connect:
# Wait for cluster to be ready (tries every 10s for up to 2 min)
until fdbcli -C fdb.cluster \
--tls-ca-file ca.crt \
--tls-certificate-file client.crt \
--tls-key-file client.key \
--tls-verify-peers Check.Valid=1 \
--exec "status minimal" 2>/dev/null | grep -q "available"; do
echo "Waiting for cluster..." && sleep 10
done && echo "Cluster ready!"
# Connect interactively
fdbcli -C fdb.cluster \
--tls-ca-file ca.crt \
--tls-certificate-file client.crt \
--tls-key-file client.key \
--tls-verify-peers Check.Valid=1
Create a new project. Requires TLS certificates in request body. Returns project ID and expiration time.
Get cluster file for connecting to your FDB instance. Requires mTLS (client cert signed by your CA).
Configure project settings (e.g., add payment to remove expiration). Requires mTLS.
:tls suffix"Could not communicate with a quorum of coordination servers"
ping6 ipv6.google.com--tls-ca-file must be the same CA you used when creating the project.openssl verify -CAfile ca.crt client.crt
"invalid client certificate"
Your client cert wasn't signed by the CA you provided when creating the project. Generate a new client cert using the same CA:
openssl req -newkey rsa:2048 -nodes -keyout client.key -out client.csr -subj "/CN=client"
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt -days 365
"server_cert must be signed by ca_cert"
When creating a project, your server certificate must be signed by the CA you provide. This ensures your cluster will trust connections from clients using that CA.
TLS Verify Peers Option
The --tls-verify-peers Check.Valid=1 flag tells FoundationDB to verify that certificates are valid and not expired, but doesn't require specific CN or SAN values. Other options include:
Check.Valid=0 — Don't verify certificates (insecure, for testing only)S.CN=server — Require server cert CN to match "server"