Connect Two Raspberry Pi AI Servers

Network two Raspberry Pis into a distributed AI system over Wi-Fi.

Introduction

30 Second Summary

Your phone talks to servers all over the world every time you open an app. Your two Raspberry Pis are sitting on the same Wi-Fi network, but right now they have no idea the other one exists.

In this project, you will wire two Raspberry Pi servers into a unified AI network over Wi-Fi so they can share models, send tasks to each other, and work together as a distributed system you fully control.

What You'll Build

A two-node AI network where Pi 1 (n8n + Ollama) and Pi 2 (OpenClaw + Cerebras) communicate wirelessly to share AI inference and automate workflows across both machines.

By the end of this project, you'll have:

  • Both Pis locked down with static IPs and SSH key access so they reliably find and authenticate with each other across reboots.
  • OpenClaw on Pi 2 configured to use Ollama on Pi 1 as a free, local fallback model provider alongside Cerebras cloud inference.
  • A working n8n workflow on Pi 1 that sends tasks to OpenClaw on Pi 2 and receives a response, proving the full cross-Pi communication loop.
  • A Tailscale VPN setup that lets you access your AI network from anywhere, not just your local Wi-Fi.

Are there any prerequisites?

This project assumes both Pis are already running their respective services. Pi 1 should have n8n and Ollama installed, and Pi 2 should have OpenClaw configured with a Cerebras API key. You also need a macOS computer on the same Wi-Fi network for SSH access.

Lock Down Your Network Layer

Before your two Pis can share AI workloads, they need to reliably find each other on your Wi-Fi network.

Right now, your router assigns IP addresses dynamically. That means after a reboot, Pi 1 might get a completely different address, and every service connection you configured would break. In this step, you will pin both Pis to fixed IPs and set up SSH key access so they can authenticate with each other without passwords.

In This Step, Get Ready To:
  • Assign static IPs to both Raspberry Pis so they keep the same address after every reboot.
  • Set up SSH key-based access between your Mac and both Pis, and between the Pis themselves.
  • Verify network connectivity and confirm each Pi's services are running.
Assign Static IPs to Both Pis

Your router uses DHCP to hand out IP addresses to devices on your network. By default, these addresses can change. You need to lock them down so that Pi 1 and Pi 2 always get the same IP.

  • Open Terminal on your Mac and SSH into Pi 1.
  • Run the following command to check Pi 1's current IP address.
hostname -I
  • Write down the IP address that appears (e.g. 192.168.1.101).
  • Repeat this on Pi 2 to note its current IP address as well.

Now you need to pin these addresses. The most reliable approach is to set DHCP reservations in your router, which tells the router to always assign the same IP to a specific device.

Router DHCP Reservation (Recommended)

  • Open a browser on your Mac and navigate to your router's admin panel. This is usually at 192.168.1.1 or 192.168.0.1.
  • Find the DHCP reservation or Address reservation section. The exact location varies by router brand.
  • Add a reservation for Pi 1 by selecting its MAC address and assigning it a fixed IP (e.g. 192.168.1.101).
  • Add a second reservation for Pi 2 with its own fixed IP (e.g. 192.168.1.102).
  • Save the settings in your router.

Pro tip: finding your Pi's MAC address

Most router admin panels show connected devices with their MAC addresses. If yours does not, SSH into the Pi and run ip link show wlan0. The MAC address appears after link/ether.

Static IP on the Pi

If you cannot access your router's admin panel, you can configure a static IP directly on each Pi by editing /etc/dhcpcd.conf.

  • SSH into Pi 1 and open the DHCP client configuration file.
sudo nano /etc/dhcpcd.conf
  • Add the following lines at the bottom of the file. Replace the IP addresses with ones that fit your network.
interface wlan0
static ip_address=[[PI1_STATIC_IP="192.168.1.101/24"]]
static routers=[[ROUTER_IP="192.168.1.1"]]
static domain_name_servers=[[ROUTER_IP="192.168.1.1"]]

What does this configuration do?

The interface wlan0 line targets the Wi-Fi adapter. static ip_address sets the fixed IP with a /24 subnet mask. static routers points to your router's IP so the Pi can reach the internet.

  • Save the file with Ctrl+O and exit with Ctrl+X.
  • Repeat this process on Pi 2 with a different static IP (e.g. 192.168.1.102/24).

Whichever method you chose, reboot both Pis to apply the changes.

sudo reboot
  • Wait about 30 seconds, then SSH back into each Pi using the static IPs you assigned.
  • Run hostname -I on each Pi to confirm the IP matches what you configured.

Can't SSH back in after reboot?

If the Pi is not reachable at the new static IP, the IP you chose may conflict with another device on your network. Connect a monitor and keyboard to the Pi, log in locally, and try a different IP address. Help me troubleshoot my static IP setup.

Set Up SSH Key Access Between the Pis

Password-based SSH works, but it is fragile for automated connections. When n8n on Pi 1 needs to interact with Pi 2, you do not want a password prompt blocking the workflow. SSH keys let devices authenticate automatically using a cryptographic key pair instead of a password.

You will set up key access in three directions: Mac to Pi 1, Mac to Pi 2, and Pi 1 to Pi 2 (and vice versa).

First, generate an SSH key on your Mac if you do not already have one.

ssh-keygen -t ed25519

What does this command do?

This generates an Ed25519 key pair. The private key stays on your Mac. The public key gets copied to the Pis. When you SSH in, the two keys are matched cryptographically, so no password is needed.

  • Press Enter through all the prompts to accept the defaults. If you already have a key, it will ask if you want to overwrite. Choose no.
  • Copy your Mac's public key to both Pis.
ssh-copy-id [[PI_USER="your Pi username"]]@[[PI1_IP="Pi 1 static IP"]]
ssh-copy-id [[PI_USER="your Pi username"]]@[[PI2_IP="Pi 2 static IP"]]

Now set up key access between the Pis themselves. This is important for cross-Pi service communication.

  • SSH into Pi 1 and generate a key pair there.
ssh-keygen -t ed25519
  • Copy Pi 1's public key to Pi 2.
ssh-copy-id [[PI_USER="your Pi username"]]@[[PI2_IP="Pi 2 static IP"]]
  • SSH into Pi 2 and repeat the same process. Generate a key and copy it to Pi 1.
ssh-keygen -t ed25519
ssh-copy-id [[PI_USER="your Pi username"]]@[[PI1_IP="Pi 1 static IP"]]

Time to verify that passwordless SSH works in both directions.

  • From Pi 1, run the following command. It should print Pi 2's hostname without asking for a password.
ssh [[PI_USER="your Pi username"]]@[[PI2_IP="Pi 2 static IP"]] hostname
  • From Pi 2, do the reverse.
ssh [[PI_USER="your Pi username"]]@[[PI1_IP="Pi 1 static IP"]] hostname

If both commands print the other Pi's hostname without a password prompt, your SSH key access is working.

Verify Network Connectivity and Services

With static IPs and SSH keys in place, confirm that both Pis can reach each other and that each Pi's services are running properly.

  • From Pi 1, ping Pi 2.
ping -c 3 [[PI2_IP="Pi 2 static IP"]]
  • From Pi 2, ping Pi 1.
ping -c 3 [[PI1_IP="Pi 1 static IP"]]

Both pings should succeed with low latency, typically under 10ms on a local network.

Now confirm the services on each Pi are responding.

  • On Pi 1, check that Ollama is running.
curl http://localhost:11434/api/tags

What should I see?

This should return a JSON response listing all the models you have installed in Ollama. If you see a connection refused error, Ollama may not be running. Start it with sudo systemctl start ollama.

  • On Pi 2, check that OpenClaw is running.
openclaw status

You should see output confirming that the OpenClaw gateway is active on port 18789.

Your network layer is solid. Both Pis have fixed addresses, passwordless SSH access, and confirmed connectivity. Next up, you will open Ollama on Pi 1 to the network so Pi 2 can use it for local AI inference.

Open Ollama to the Network

Right now, Ollama on Pi 1 only talks to itself. It listens on 127.0.0.1 (localhost), which means no other device on your network can reach it. For Pi 2 to use Ollama as a model provider, you need to open Ollama's door to the rest of your Wi-Fi network.

In This Step, Get Ready To:
  • Configure Ollama to accept connections from any device on your network.
  • Verify Ollama is listening on the correct network interface.
  • Test that Pi 2 can reach Ollama on Pi 1 over Wi-Fi.
Configure Ollama to Bind to All Interfaces

Ollama runs as a systemd service on your Raspberry Pi. To change how it listens for connections, you need to set an environment variable called OLLAMA_HOST. Setting it to 0.0.0.0 tells Ollama to accept connections from any network interface, not just localhost.

  • SSH into Pi 1 from your Mac.
  • Open the Ollama service override file.
sudo systemctl edit ollama.service

This opens a blank editor for your override configuration. The override file lets you add settings without modifying the original service file.

  • Add the following lines in the editor:
[Service]
Environment="OLLAMA_HOST=0.0.0.0"
Environment="OLLAMA_ORIGINS=*"

What do these environment variables do?

  • OLLAMA_HOST=0.0.0.0 tells Ollama to listen on all network interfaces instead of just localhost. This is what allows Pi 2 to connect.
  • OLLAMA_ORIGINS=* allows cross-origin requests from other machines. Without this, requests from Pi 2 could be rejected.
  • Save and exit the editor.
  • Reload the systemd configuration and restart Ollama.
sudo systemctl daemon-reload
sudo systemctl restart ollama

What does this command do?

The daemon-reload command tells systemd to re-read all service files, picking up your new override. The restart command stops and starts Ollama so it applies the new environment variables.

Pro tip: Ollama upgrades

If you upgrade Ollama in the future, the systemd override may need to be re-applied. After any upgrade, run sudo systemctl edit ollama.service to check that your environment variables are still there.

Verify Ollama Is Listening on All Interfaces

Before testing from another device, confirm that Ollama is actually bound to the right address on Pi 1 itself.

  • On Pi 1, check which address Ollama is listening on.
sudo ss -tlnp | grep 11434

What does this command do?

The ss command shows socket statistics. The flags -tlnp filter for TCP listening sockets with numeric addresses and process names. Piping to grep 11434 narrows it down to Ollama's port.

I see 0.0.0.0:11434

You should see output showing 0.0.0.0:11434 or [::]:11434 (the IPv6 equivalent). This means Ollama is accepting connections from any network interface. You are good to go.

I see 127.0.0.1:11434

If you still see 127.0.0.1:11434, the override did not take effect. Double-check that your override file has the [Service] header and both Environment lines. Then run sudo systemctl daemon-reload && sudo systemctl restart ollama again.

Still seeing 127.0.0.1?

Run sudo systemctl cat ollama.service to see the full merged service file. Look for your override section at the bottom. If it is missing, re-run sudo systemctl edit ollama.service and make sure you are adding the lines between the comment markers the editor provides. Help me troubleshoot my Ollama systemd override.

  • Confirm Ollama still works locally by querying its model list.
curl http://localhost:11434/api/tags

This should return a JSON response listing the models installed on Pi 1. If you see your models, Ollama is healthy and ready for remote connections.

Test Remote Access From Pi 2

The real test is whether Pi 2 can actually reach Ollama over the network. This is the same request you just ran locally, but from a completely different machine.

  • SSH into Pi 2 from your Mac.
  • Send a request to Ollama on Pi 1 using Pi 1's IP address.
curl http://[[PI1_IP="Pi 1's static IP address"]]:11434/api/tags

I see a JSON model list

You should see the exact same JSON list of models that you saw when running the command locally on Pi 1. This confirms that Pi 2 can reach Ollama across your Wi-Fi network.

I see an error

If the connection times out or is refused, there are a few things to check.

  • Verify Pi 2 can reach Pi 1 at all by running ping -c 3 <Pi 1's IP>. If this fails, the issue is at the network level, not Ollama.
  • Check for firewall rules on Pi 1 by running sudo iptables -L on Pi 1. Look for any DROP rules that might be blocking port 11434.
  • Make sure you are using the correct IP address. Run hostname -I on Pi 1 to confirm.

Still can't connect?

help me debug why Pi 2 cannot reach Ollama on Pi 1.

Ollama on Pi 1 is now open for business on your local network. Next up, you will configure OpenClaw on Pi 2 to use this remote Ollama instance as a model provider, giving you a hybrid setup with both cloud and local inference.

Connect OpenClaw to Remote Ollama

Ollama is now accepting connections from across your network. The next step is to tell OpenClaw on Pi 2 where to find it. Right now, OpenClaw uses Cerebras for cloud inference. By adding Ollama on Pi 1 as a second provider, you create a hybrid setup. Cerebras handles primary inference in the cloud, and Ollama is available as a free, local fallback that costs zero API tokens.

In This Step, Get Ready To:
  • Register Ollama on Pi 1 as a provider in OpenClaw's configuration.
  • Verify that OpenClaw can discover models from the remote Ollama instance.
  • Test a cross-Pi inference request from OpenClaw through Ollama.
Add Ollama as a Provider in OpenClaw

OpenClaw supports Ollama as a bundled provider plugin. It communicates with Ollama using Ollama's native API (/api/chat). You need to point it at Pi 1's IP address instead of the default localhost.

  • SSH into Pi 2.
  • Run the following commands to register Ollama as a provider:
openclaw config set models.providers.ollama.baseUrl "http://[[PI1IP="Pi 1's static IP address"]]:11434"
openclaw config set models.providers.ollama.apiKey "ollama-local"

What do these commands do?

The first command tells OpenClaw the network address of your Ollama instance on Pi 1. The second sets a placeholder API key. Ollama does not require authentication, but OpenClaw expects a non-empty value in this field.

Do Not Add /v1 to the URL

Use the native Ollama API URL without a /v1 suffix. Ollama does offer an OpenAI-compatible endpoint at /v1, but it can cause issues with tool-calling in OpenClaw. Stick with the base URL.

Verify Model Discovery and Set Up Hybrid Mode

If the connection is working, OpenClaw should be able to pull a list of models from Pi 1's Ollama instance over the network.

  • List available Ollama models from OpenClaw:
openclaw models list --provider ollama

I see my models listed

You should see the same models that are installed on Pi 1's Ollama instance. This confirms OpenClaw on Pi 2 is successfully communicating with Ollama on Pi 1 over your Wi-Fi network.

I see an error or no models

If the command returns an error or an empty list, work through these checks:

  • Verify you can still reach Ollama from Pi 2 directly:
curl http://[[PI1IP="Pi 1's static IP address"]]:11434/api/tags
  • If the curl command fails, go back to Step 2 and confirm Ollama is still listening on 0.0.0.0:11434.
  • If the curl command succeeds but OpenClaw still shows no models, double-check that the base URL you configured does not have a trailing /v1 or a trailing slash.
  • Confirm the API key is set to any non-empty value by re-running the config set command.

If you are still stuck, help me troubleshoot my OpenClaw Ollama provider connection.

Your Cerebras provider remains the primary model for complex inference tasks. Ollama on Pi 1 acts as a fallback you can use for simpler tasks like heartbeat checks, which saves your Cerebras API tokens.

  • To configure a fallback model, edit the OpenClaw configuration file:
nano ~/.openclaw/openclaw.json

Look for the agents.defaults.model.fallbacks section and add your Ollama model there. Save and exit when done.

Test the Cross-Pi Connection

Time to prove the whole chain works. You will temporarily switch OpenClaw to the Ollama provider, send a test message, and watch it travel from Pi 2 to Pi 1 for inference.

  • Temporarily switch OpenClaw to use an Ollama model. Replace the model name with one from your list:
openclaw models set ollama/[[OLLAMAMODEL="your Ollama model name, e.g. llama3.2"]]
  • Send a test message through the OpenClaw CLI or dashboard to trigger an inference request.
  • Open a second terminal, SSH into Pi 1, and watch Ollama's logs to confirm it received the request:
journalctl -u ollama -f

What should I see?

In the Ollama logs on Pi 1, you should see an incoming request being processed. This confirms that a request originated on Pi 2 (OpenClaw), traveled over your Wi-Fi network, and was handled by Ollama on Pi 1. The response then traveled back to Pi 2.

  • Switch back to your Cerebras model as the primary provider:
openclaw models set cerebras/[[CEREBRASMODEL="your Cerebras model name, e.g. llama3.1-8b"]]

What does this command do?

This restores Cerebras as your primary inference provider. Ollama remains configured as a fallback. OpenClaw will use Cerebras for main tasks and can fall back to Ollama on Pi 1 when needed.

You now have a hybrid AI setup. Cerebras handles heavy inference in the cloud for free, and Ollama on Pi 1 is available as a local fallback that costs nothing and keeps your data on your own hardware. Next up, you will close the loop by building an n8n workflow on Pi 1 that triggers OpenClaw on Pi 2, proving full two-way communication across your Pi network.

Build a Cross-Pi n8n Workflow

You have a hybrid AI setup where OpenClaw on Pi 2 can reach Ollama on Pi 1 for local inference. Now it is time to close the loop in the other direction. n8n on Pi 1 will send a task to OpenClaw on Pi 2 via an HTTP request, proving that both Pis can initiate communication with each other. This is the final piece that turns two standalone servers into a genuinely distributed AI system.

In This Step, Get Ready To:
  • Confirm that n8n on Pi 1 can reach the OpenClaw gateway on Pi 2.
  • Build an n8n workflow that sends a prompt to OpenClaw and captures the response.
  • Test the full cross-Pi round trip from n8n to OpenClaw and back.
Verify n8n Can Reach OpenClaw

The OpenClaw gateway runs on port 18789 by default. Before building anything in n8n, you need to confirm that Pi 1 can actually reach that port on Pi 2 over the network.

  • SSH into Pi 1 from your Mac.
  • Test connectivity to the OpenClaw gateway on Pi 2.
curl http://[[PI2IP="your Pi 2 static IP address"]]:18789

What should I see?

You should get a response from the OpenClaw gateway. Any response (even an error page or JSON message) confirms that Pi 1 can reach the service on Pi 2.

Connection refused or timed out?

The OpenClaw gateway may be bound to 127.0.0.1 by default, which means it only accepts local connections. Check OpenClaw's gateway configuration on Pi 2 for a bind address setting and change it to 0.0.0.0 to listen on all interfaces. Alternatively, you can create an SSH tunnel from Pi 1 to Pi 2 to forward the port.

If you are still stuck, help me troubleshoot my OpenClaw gateway connectivity.

Create the n8n Workflow

n8n is a visual workflow automation tool. You will build a simple three-node workflow that sends a prompt to OpenClaw on Pi 2 and displays the AI response.

  • Open n8n in your browser at http://your Pi 1 IP:5678.
  • Click Add workflow to create a new workflow.
  • Give it a descriptive name like Cross-Pi OpenClaw Test.

Your workflow needs three nodes wired together in sequence.

First, add a Manual Trigger node. This lets you execute the workflow on demand by clicking a button.

  • Click the + button on the canvas.
  • Search for Manual Trigger and select it.

Next, add an HTTP Request node. This is the node that will call OpenClaw's gateway on Pi 2.

  • Click the + button after the Manual Trigger node.
  • Search for HTTP Request and select it.
  • Set the Method to POST.
  • Set the URL to OpenClaw's gateway endpoint on Pi 2.
http://[[PI2IP="your Pi 2 static IP address"]]:18789

What about the exact API endpoint?

The OpenClaw gateway exposes its HTTP API on port 18789. The exact REST endpoint paths for sending messages programmatically may vary depending on your OpenClaw version. Check your OpenClaw documentation or run openclaw --help on Pi 2 to find the available API routes.

  • Under Body, select JSON as the content type.
  • Enter a JSON body with a test prompt. The exact structure depends on your OpenClaw API, but a simple message payload is all you need.
{
  "message": "What is the capital of France? Reply in one sentence."
}

Why a simple prompt?

You are testing the network plumbing, not the AI's capabilities. A short, factual question makes it easy to verify that the response actually came from OpenClaw on Pi 2.

Finally, add a Set node to extract the response so you can read it clearly in the execution log.

  • Click the + button after the HTTP Request node.
  • Search for Set and select it.
  • Add a field called response and map it to the body of the HTTP Request output. You can use the expression editor to reference the JSON response from the previous node.
Test the Full Round Trip

This is the moment of truth. When you execute this workflow, a request will travel from n8n on Pi 1, across your Wi-Fi network to OpenClaw on Pi 2. OpenClaw will process it using either Cerebras (cloud) or Ollama on Pi 1 (local). The response then flows back to n8n.

  • Click Test workflow in n8n to execute the workflow manually.
  • Watch each node turn green as the execution progresses through the chain.
  • Click on the Set node to inspect the output. You should see the AI-generated response from OpenClaw.

What should I see?

The Set node's output should contain the AI's answer to your test prompt. If you asked about the capital of France, you should see a response mentioning Paris. The exact format depends on how OpenClaw structures its API response.

To confirm the request actually reached Pi 2, you can also check OpenClaw's logs on Pi 2.

  • SSH into Pi 2 in a separate terminal window.
  • Run openclaw status to verify the gateway processed a recent request.

Workflow execution failed?

Click on the failed node (it will be red) to see the error details. Common issues include incorrect URL, OpenClaw gateway not listening on the network, or a malformed JSON body.

Go back to the first substep and re-run the curl test from Pi 1 to confirm basic connectivity is still working. If curl works but n8n does not, the issue is likely in the HTTP Request node configuration.

If you need more help, help me debug my n8n workflow calling OpenClaw.

You now have a fully connected two-node AI system. n8n automates task dispatch from Pi 1. OpenClaw orchestrates AI agent behavior on Pi 2. Ollama provides local inference back on Pi 1. All three services communicate wirelessly across your network. Next up, you will take this setup beyond your living room with a secret mission.

Secret mission

Set Up Tailscale for Remote Access

Your AI network only works when you're on the same Wi-Fi right now. What if you could SSH into your Pis, trigger n8n workflows, and access OpenClaw from a coffee shop or your phone's hotspot? Tailscale creates a private VPN mesh that makes this possible with zero port forwarding and zero firewall headaches.

Before you go

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs on local hardware with the Cerebras free tier, so there are no ongoing cloud costs. The main consideration is whether you want Ollama, n8n, and OpenClaw to keep running on your Pis.

Resources you used:

  • Static IP assignments (DHCP reservations in your router or /etc/dhcpcd.conf entries on each Pi).
  • SSH keys on your Mac, Pi 1, and Pi 2.
  • Ollama systemd override on Pi 1 (OLLAMA_HOST=0.0.0.0 and OLLAMA_ORIGINS=*).
  • OpenClaw provider configuration on Pi 2 (Ollama remote base URL in ~/.openclaw/openclaw.json).
  • n8n workflow on Pi 1 (the cross-Pi HTTP Request workflow).
  • Tailscale installation on both Pis and your Mac (if you completed the Secret Mission).

Keep everything running

No action needed. Choose this if you are still actively building on your two-node AI network or plan to add more services soon.

  • Your static IPs, SSH keys, and Ollama network config will persist across reboots.
  • Ollama, n8n, and OpenClaw will continue running as systemd services on their respective Pis.
  • If you installed Tailscale, it will stay connected and your Pis will remain accessible from any network.

Pause - I'll come back to this later

Shut down the running services to free up memory and CPU on your Pis. Your configuration files and static IPs will remain intact for when you return.

  • On Pi 1, stop Ollama and n8n:
sudo systemctl stop ollama
sudo systemctl stop n8n
  • On Pi 2, stop OpenClaw:
sudo systemctl stop openclaw
  • If you installed Tailscale, stop it on both Pis: sudo tailscale down.
  • Your static IP assignments, SSH keys, Ollama systemd override, and OpenClaw provider config will all be preserved. When you are ready to resume, start the services again with sudo systemctl start <service>.

Delete - I don't want to use this again

Remove all project resources and revert your Pis to their pre-project state.

  • On Pi 1, remove the Ollama systemd override that exposes it to the network:
sudo systemctl revert ollama.service
sudo systemctl daemon-reload
sudo systemctl restart ollama
  • This restores Ollama to its default localhost-only binding.
  • On Pi 1, delete the cross-Pi n8n workflow from the n8n editor at http://<PI1_IP>:5678.
  • On Pi 2, remove the Ollama provider from OpenClaw's configuration:
openclaw config set models.providers.ollama.baseUrl ""
openclaw config set models.providers.ollama.apiKey ""
  • Remove the SSH keys exchanged between the Pis. On each Pi, edit ~/.ssh/authorized_keys and remove the key from the other Pi.
  • If you configured static IPs via DHCP reservations, log into your router and remove the reservations. If you edited /etc/dhcpcd.conf, remove the static IP block you added and reboot.
  • If you installed Tailscale, uninstall it from both Pis: sudo tailscale down && sudo apt remove tailscale. Remove the devices from your Tailscale admin console at https://login.tailscale.com/admin/machines.

Mission accomplished

That's a Wrap!

Nice work! You just built a distributed AI network from two Raspberry Pis and a Wi-Fi connection. Both machines now communicate wirelessly, sharing AI inference capabilities and orchestrating workflows across device boundaries.

Here's what you learned:

  • Configured static IPs and SSH key-based authentication between two Raspberry Pis for reliable, secure cross-device communication that survives reboots.
  • Opened Ollama to the network by setting OLLAMA_HOST=0.0.0.0, turning Pi 1 into a local AI inference server that any device on your network can use.
  • Connected OpenClaw on Pi 2 to remote Ollama on Pi 1 as a hybrid model provider, giving you both cloud inference via Cerebras and free local inference via Ollama.
  • Built an n8n workflow on Pi 1 that sends HTTP requests to OpenClaw on Pi 2, proving full cross-Pi AI orchestration.
  • Installed Tailscale on both Pis to access your AI network from anywhere, not just your local Wi-Fi.

Ready to quiz yourself?