Sharing Ollama Across Your LAN with Auto-Wake: One Mac Studio, Whole Team

Your team is exploring local LLMs, but you’re hitting the hardware wall. Developers are stuck rate-limiting against OpenAI because not everyone has a Mac Studio with 192GB of unified memory. The obvious solution — share one powerful machine across the team — runs into Ollama’s localhost-only default and the problem of leaving a $4,000 machine running 24/7. I solved this with network configuration and Wake-on-LAN, creating a Python wrapper that wakes the server on-demand and keeps it transparent to application code.

TL;DR: Share one Mac Studio M2 Ultra across your team by configuring Ollama to listen on 0.0.0.0 (via launchd plist, not shell config), enabling Wake-on-LAN (Ethernet only), and using a drop-in Python wrapper that auto-wakes the server before each request. Set **OLLAMA_KEEP_ALIVE=24h to avoid model reload delays. Saves $17,000 vs buying high-spec laptops for everyone, but requires authentication** (reverse proxy or alternative like LocalAI) for production—Ollama has no built-in auth and recent CVEs make raw exposure risky.

The Problem: Democratizing LLM Access Without Burning Money

I manage a team where half the developers have base-spec MacBook Airs. They’re great machines, but running Llama 3.1 70B locally isn’t happening. We experimented with everyone hitting cloud APIs, but for a mid-size EU company concerned about data sovereignty (thanks, GDPR), sending everything to OpenAI wasn’t sustainable long-term.

We had one Mac Studio M2 Ultra configured with 192GB of unified memory (the maximum) sitting in the office. It could handle the largest models comfortably. The economics were obvious: one $4,000 machine beats buying six high-spec developer laptops at $3,500 each. But Ollama defaults to serving on localhost only, and leaving it running 24/7 felt wasteful when usage was bursty (developers experimenting, running test suites, then nothing for hours).

The solution needed two pieces: network access to Ollama and automatic wake-on-demand.

Configuring Ollama for Network Access

Ollama binds to 127.0.0.1:11434 by default. To serve across your LAN, you need to tell it to listen on 0.0.0.0 (all interfaces). On macOS, this requires editing the launchd service configuration.

Most tutorials tell you to set OLLAMA_HOST=0.0.0.0 in your shell profile. This doesn't work for launchd services. launchd services run in their own execution context and don't source your shell profile (.zshrc), so environment variables set there aren't visible to the service. I spent an hour debugging "why isn't this working" before realizing the service never saw my environment variable.

⚠️ Key Finding: Setting OLLAMA_HOST=0.0.0.0 in your shell profile (.zshrc) won't work—launchd services don't source shell profiles. You must set it in the launchd plist itself.

The fix: create a custom launchd plist with the environment variable baked in.

If you installed Ollama via Homebrew, first copy the default plist to your user LaunchAgents folder (editing the original in /opt/homebrew/ won't survive brew upgrade):

cp /opt/homebrew/opt/ollama/homebrew.mxcl.ollama.plist ~/Library/LaunchAgents/

Then edit ~/Library/LaunchAgents/homebrew.mxcl.ollama.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>homebrew.mxcl.ollama</string>
    <key>ProgramArguments</key>
    <array>
        <string>/opt/homebrew/bin/ollama</string>
        <string>serve</string>
    </array>
    <key>EnvironmentVariables</key>
    <dict>
        <key>OLLAMA_HOST</key>
        <string>0.0.0.0</string>
        <key>OLLAMA_KEEP_ALIVE</key>
        <string>24h</string>
    </dict>
    <key>KeepAlive</key>
    <true/>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>

The EnvironmentVariables dict is the critical piece. This runs at the launchd level, so the service actually sees it. Note the OLLAMA_KEEP_ALIVE=24h setting—by default, Ollama unloads models after 5 minutes of inactivity. With WoL, that's a problem: the machine wakes, but your 70B model isn't loaded, adding 30-60+ seconds for model loading on top of wake time. Setting it to 24h (or -1 for infinite) keeps the model in unified memory as long as the machine is awake.

💡 Quick Win: Set OLLAMA_KEEP_ALIVE=24h in your launchd plist. Without this, Ollama unloads models after 5 minutes, meaning every wake includes 30-60+ seconds of model reload time on top of the 8-12 second wake delay.

Stop the Homebrew-managed service and load your custom plist:

brew services stop ollama
launchctl load ~/Library/LaunchAgents/homebrew.mxcl.ollama.plist

Verify it’s listening on all interfaces:

netstat -an | grep 11434

You should see *.11434 instead of 127.0.0.1.11434.*

Firewall check: macOS may prompt you to allow Ollama to accept incoming connections. If not, manually add it in System Settings > Network > Firewall > Options.

From another machine on your LAN, test:

curl http://192.168.1.100:11434/api/tags

Replace 192.168.1.100 with your Mac Studio's IP. You should get a JSON response listing available models.

Enabling Wake-on-LAN on macOS

Wake-on-LAN (WoL) lets you wake a sleeping Mac by sending a “magic packet” over the network. On macOS, this is buried in Energy Saver settings.

⚠️ Critical Limitation: Wake-on-LAN only works over Ethernet on Macs. If your Mac Studio is on WiFi, WoL won’t work — this is how Apple implements it. Your server machine must be wired.

To enable:

• System Settings > Energy Saver (or Battery)
• Enable “Wake for network access”
• Note the “Ethernet address” (MAC address) shown in the panel

You’ll need the MAC address for sending wake packets. It looks like AA:BB:CC:DD:EE:FF.

From my testing with a Mac Studio M2 Ultra, wake time is typically 4–7 seconds from sleep to network-ready, then another 3–5 seconds for Ollama to start responding to requests.

The WakeableOllamaClient: Auto-Wake for Free

The naive approach: manually wake the machine before making requests. This breaks the developer experience. You’re forcing people to remember “run the wake script first,” which they’ll forget half the time.

I built a wrapper around the official ollama-python client that checks availability before each request and auto-wakes if needed. It’s a drop-in replacement — existing code just swaps Client for WakeableOllamaClient and gets auto-wake for free.

Here’s the implementation (save as wakeable_ollama_client.py):

#!/usr/bin/env python3
"""
wakeable_ollama_client.py

A wrapper around the Ollama Python client that automatically wakes the server
via Wake-on-LAN if it's not reachable.

Usage:
    from wakeable_ollama_client import WakeableOllamaClient

    client = WakeableOllamaClient(
        host="http://192.168.1.100:11434",
        mac_address="AA:BB:CC:DD:EE:FF",
    )

    response = client.chat(
        model="llama3",
        messages=[{"role": "user", "content": "Hello!"}]
    )

Dependencies:
    pip install ollama wakeonlan httpx
"""

import time
import httpx
from wakeonlan import send_magic_packet
from ollama import Client

class WakeableOllamaClient:
    """
    Ollama client that auto-wakes the server if it's asleep.

    This is a drop-in replacement for ollama.Client. Before each request,
    it checks if the server is reachable. If not, it sends a Wake-on-LAN
    magic packet and waits for the server to come online.

    To avoid unnecessary health checks, successful connections are cached
    for a configurable duration (cache_ttl).

    Args:
        host: Ollama server URL (e.g., "http://192.168.1.100:11434")
        mac_address: MAC address of the server for Wake-on-LAN
        wake_timeout: Maximum seconds to wait for server after wake (default: 120)
        poll_interval: Seconds between availability checks (default: 2)
        cache_ttl: Seconds to cache "awake" state (default: 300, i.e., 5 minutes)

    Example:
        >>> client = WakeableOllamaClient(
        ...     host="http://192.168.1.100:11434",
        ...     mac_address="AA:BB:CC:DD:EE:FF",
        ...     cache_ttl=300,
        ... )
        >>> # First call: checks availability, wakes if needed
        >>> response = client.chat(model="llama3", messages=[...])
        >>> # Subsequent calls within 5 min: no availability check
        >>> response = client.generate(model="llama3", prompt="Hello")
    """

    def __init__(
        self,
        host: str,
        mac_address: str,
        wake_timeout: int = 120,
        poll_interval: int = 2,
        cache_ttl: int = 300,
    ):
        self.host = host
        self.mac_address = mac_address
        self.wake_timeout = wake_timeout
        self.poll_interval = poll_interval
        self.cache_ttl = cache_ttl
        self._client = Client(host=host)
        self._last_seen_alive: float | None = None

    def _is_cached_alive(self) -> bool:
        """Check if we recently confirmed the server was up."""
        if self._last_seen_alive is None:
            return False
        return (time.time() - self._last_seen_alive) < self.cache_ttl

    def _mark_alive(self):
        """Update the last-seen timestamp."""
        self._last_seen_alive = time.time()

    def _is_available(self) -> bool:
        """
        Quick check if Ollama is responding.

        Returns:
            True if server responded, False otherwise.
        """
        try:
            httpx.get(f"{self.host}/api/tags", timeout=2)
            self._mark_alive()
            return True
        except (httpx.ConnectError, httpx.TimeoutException):
            return False

    def _wake_and_wait(self) -> bool:
        """
        Send WoL packet and wait for Ollama to come online.

        Returns:
            True if server became available.

        Raises:
            ConnectionError: If server didn't respond within timeout.
        """
        print(f"Ollama not reachable – sending wake packet to {self.mac_address}")
        send_magic_packet(self.mac_address)

        start = time.time()
        while time.time() - start < self.wake_timeout:
            if self._is_available():
                elapsed = int(time.time() - start)
                print(f"Ollama is ready (took {elapsed}s)")
                return True
            time.sleep(self.poll_interval)

        raise ConnectionError(
            f"Ollama didn't respond within {self.wake_timeout}s after wake"
        )

    def _ensure_awake(self):
        """Make sure server is up before any request."""
        if self._is_cached_alive():
            return  # Recently confirmed alive, skip check

        if not self._is_available():
            self._wake_and_wait()

    def invalidate_cache(self):
        """
        Force a fresh availability check on the next request.

        Use this if you know the Mac has gone to sleep (e.g., you
        manually put it to sleep or it's been idle for a long time).
        """
        self._last_seen_alive = None

    # -------------------------------------------------------------------------
    # Proxy methods to the underlying Ollama client
    # -------------------------------------------------------------------------

    def chat(self, args, *kwargs):
        """Send a chat message. See ollama.Client.chat for details."""
        self._ensure_awake()
        return self._client.chat(args, *kwargs)

    def generate(self, args, *kwargs):
        """Generate a completion. See ollama.Client.generate for details."""
        self._ensure_awake()
        return self._client.generate(args, *kwargs)

    def embeddings(self, args, *kwargs):
        """Generate embeddings. See ollama.Client.embeddings for details."""
        self._ensure_awake()
        return self._client.embeddings(args, *kwargs)

    def list(self):
        """List available models. See ollama.Client.list for details."""
        self._ensure_awake()
        return self._client.list()

    def pull(self, args, *kwargs):
        """Pull a model. See ollama.Client.pull for details."""
        self._ensure_awake()
        return self._client.pull(args, *kwargs)

    def push(self, args, *kwargs):
        """Push a model. See ollama.Client.push for details."""
        self._ensure_awake()
        return self._client.push(args, *kwargs)

    def delete(self, args, *kwargs):
        """Delete a model. See ollama.Client.delete for details."""
        self._ensure_awake()
        return self._client.delete(args, *kwargs)

    def copy(self, args, *kwargs):
        """Copy a model. See ollama.Client.copy for details."""
        self._ensure_awake()
        return self._client.copy(args, *kwargs)

    def show(self, args, *kwargs):
        """Show model info. See ollama.Client.show for details."""
        self._ensure_awake()
        return self._client.show(args, kwargs)

    def __getattr__(self, name):
        """Fallback for any other client methods not explicitly proxied."""
        self._ensure_awake()
        return getattr(self._client, name)

# =============================================================================
# Example usage
# =============================================================================
if __name__ == "__main__":
    # Configuration - edit these for your setup
    HOST = "http://192.168.1.100:11434"
    MAC_ADDRESS = "AA:BB:CC:DD:EE:FF"

    client = WakeableOllamaClient(
        host=HOST,
        mac_address=MAC_ADDRESS,
        cache_ttl=300,  # 5 minutes
    )

    # First call: checks availability (wakes if needed)
    print("Sending first request...")
    response = client.chat(
        model="llama3",
        messages=[{"role": "user", "content": "Hello! Please respond briefly."}]
    )
    print(f"Response: {response['message']['content']}")

    # Subsequent calls within cache_ttl: no availability check
    print("\nSending follow-up request (should skip wake check)...")
    response = client.chat(
        model="llama3",
        messages=[{"role": "user", "content": "What's 2+2?"}]
    )
    print(f"Response: {response['message']['content']}")

Why this code matters: The caching behavior (_last_seen_alive) is the non-obvious piece. Without it, every single request triggers an availability check, adding 2 seconds of latency per call. With caching, the first request in a session pays the availability cost, then subsequent requests within cache_ttl are instant.

The tradeoff: if the Mac sleeps between cached requests (because your cache is 5 minutes but the Mac sleeps after 3 minutes of inactivity), the next request will fail. You’ll need to tune cache_ttl to match your Mac's sleep schedule. I run with cache_ttl=180 (3 minutes) and Mac sleep set to 5 minutes.

Dependencies (save as requirements.txt):

ollama>=0.1.0
wakeonlan>=3.0.0
httpx>=0.24.0

Install via:

pip install -r requirements.txt

Usage in Application Code

The client is a drop-in replacement. Existing code using the official client:

from ollama import Client

client = Client(host="http://192.168.1.100:11434")
response = client.chat(
    model="llama3",
    messages=[{"role": "user", "content": "Explain GDPR in one sentence."}]
)

With auto-wake:

from wakeable_ollama_client import WakeableOllamaClient

client = WakeableOllamaClient(
    host="http://192.168.1.100:11434",
    mac_address="AA:BB:CC:DD:EE:FF",
    cache_ttl=300,
)
response = client.chat(
    model="llama3",
    messages=[{"role": "user", "content": "Explain GDPR in one sentence."}]
)

The first request after the Mac sleeps will print:

Ollama not reachable – sending wake packet to AA:BB:CC:DD:EE:FF
Ollama is ready (took 8s)

Then the response arrives normally. From the application’s perspective, it just looks like a slightly slower request. No error handling needed.

Production Considerations and Gotchas

• Ethernet-only limitation: If your Mac Studio is on WiFi, WoL won’t work. This killed my first deployment attempt. I had to relocate the machine closer to the network switch and run a cable. Not ideal, but non-negotiable.
• First request timing: After wake, expect 8–12 seconds for the first response. The Mac wakes in 4–7 seconds, Ollama starts responding in 3–5 seconds. If your application has tight timeout requirements (e.g., 5-second HTTP timeout), the first request after wake will fail. Either increase timeouts or handle retries.
• Cache invalidation edge cases: If someone manually puts the Mac to sleep while your cache_ttl is still active, the next request will fail (the cache thinks it's awake, so it skips the wake check). The wrapper doesn't detect this. You can manually call client.invalidate_cache() if you know the Mac slept, but in practice this is rare enough I haven't automated it.
• Model loading time: WoL gets the machine awake, but if the model isn’t already loaded in unified memory, the first inference request pays an additional 30–60+ seconds for large models like Llama 3.1 70B. This is why the OLLAMA_KEEP_ALIVE=24h setting in the launchd plist is critical—without it, Ollama's default 5-minute timeout will unload your model while the machine sleeps, making every wake include a full model reload.
• Network stability: A flaky network will cause false “server is down” checks, triggering unnecessary wakes. If you’re seeing frequent wake attempts even though the Mac is already up, check for network issues or tune the availability timeout (currently hardcoded at 2 seconds in _is_available).

Security: This Is the Weak Point

I need to be direct: exposing Ollama to your network without authentication is a significant security risk, and the situation has gotten worse in 2025.

Ollama has no built-in authentication. All API endpoints — /api/chat, /api/generate, /api/delete, /api/create—are wide open. In December 2025, CVE-2025-63389 was disclosed: a critical authentication bypass affecting versions through v0.12.3 that enables remote attackers to perform unauthorized model management operations. Earlier in 2025, CVE-2025-51471 exposed a cross-domain token vulnerability in the /api/pull endpoint. Security researchers have found over 1,100 unauthenticated Ollama instances exposed on the public internet via Shodan.

**⚠️ Security Warning: Ollama has zero built-in authentication. CVE-2025–63389 (affects v0.12.3 and earlier) enables unauthorized model management by remote attackers. VLANs provide segmentation, not authentication — anyone on the VLAN can still access all API endpoints. Use Ollama ≥0.12.4 and add a reverse proxy with auth for any network deployment.**

“Just put it on a VLAN” is not sufficient. VLANs provide network segmentation, not authentication. Anyone on that VLAN can still hit the API. For a trusted office LAN with no guest access and no BYOD, you might accept this risk — but you should understand it’s a policy decision, not a technical control.

Recommended mitigations:

1. Reverse proxy with authentication: Put Nginx, Traefik, or Caddy in front of Ollama with OAuth2, mTLS, or at minimum HTTP Basic Auth. NSFOCUS recommends this approach for any network-exposed deployment.
2. IP allowlisting: If you can’t add auth, at minimum use firewall rules to restrict access to specific client IPs. This is weak (IPs can be spoofed on LANs) but better than nothing.
3. Keep Ollama updated: CVE-2025–63389 affects versions through v0.12.3. Ensure you’re running Ollama ≥0.12.4 (ollama --version to check, brew upgrade ollama to update).
4. Consider alternatives with built-in auth: See the next section.

For our deployment, we use Nginx with HTTP Basic Auth in front of Ollama. It’s not perfect, but it’s a meaningful improvement over raw exposure.

Alternatives with Built-in Authentication

If Ollama’s lack of authentication is a dealbreaker, consider these alternatives:

• **llama.cpp server:** The llama-server binary supports --api-key flag for built-in authentication. Requests must include Authorization: Bearer YOUR_API_KEY header. It's lower-level than Ollama (no automatic model management) but gives you direct control and native auth.
• **LocalAI:** An OpenAI-compatible API server with built-in API key authentication and configurable rate limiting. More complex to set up than Ollama, but designed for production deployments with Docker/Kubernetes support.
• **LiteLLM Proxy:** An API gateway that sits in front of Ollama (or any LLM backend) and adds authentication via virtual keys, spend tracking, and rate limiting. You can configure it with a master key and generate per-user API keys. This is probably the easiest path if you want to keep using Ollama but need auth — LiteLLM has native Ollama support.
• Nginx/Traefik with auth middleware: If you want to keep Ollama as-is, put a reverse proxy in front with HTTP Basic Auth, OAuth2 Proxy, or client certificate (mTLS) verification. More operational overhead but preserves Ollama’s simplicity.

For a small trusted team on a trusted LAN, raw Ollama with IP restrictions may be acceptable. For anything larger or more exposed, add authentication at the proxy layer or switch to an alternative with built-in auth.

Cost-Benefit Analysis

The economics for mid-size teams:

Without shared Ollama:

• 6 developers × $3,500 high-spec MacBook Pros = $21,000
• Still limited to ~32GB RAM per machine, can’t run 70B+ models well

With shared Ollama:

• 1 Mac Studio M2 Ultra (192GB unified memory) = $4,000
• 6 developers keep existing MacBook Airs = $0 additional hardware
• Savings: $17,000

For EU companies, there’s also the data sovereignty angle. Every API call to OpenAI is data leaving your jurisdiction. For sensitive customer data or proprietary code analysis, that’s a compliance risk. Running Llama 3.1 locally on your Mac Studio keeps everything on-premises.

When Not to Use This

This approach has limits:

• High concurrency: Ollama on a single Mac Studio handles maybe 3–5 concurrent requests comfortably before you start seeing slowdowns. If your team is large (20+ developers all hitting it simultaneously), you’ll need a different architecture — multiple Ollama instances behind a load balancer, or switching to a GPU cluster.
• Latency-sensitive applications: The 8–12 second first-request delay after wake is acceptable for developer tooling (code completion, test generation) but unacceptable for user-facing features. If you’re building a customer chatbot, keep the server awake or use a cloud API.
• WiFi-only environments: If running Ethernet to the Mac Studio isn’t feasible, WoL won’t work. You’d need to either keep the machine awake 24/7 or use a different wake mechanism (scheduled cron job, manual wake script).
• Cross-datacenter deployments: WoL only works on the local LAN (broadcast domain). If you’re trying to wake a machine in a remote office or cloud VM, this won’t work. Use a different approach (cloud-based auto-scaling, container orchestration).

Simple Wake Script

If you just want a standalone wake script (without the Python client wrapper), here’s a minimal version:

#!/usr/bin/env python3
"""
wake_ollama.py

Simple script to wake a Mac via Wake-on-LAN and wait for Ollama to become available.

Usage:
    python wake_ollama.py

Configuration:
    Edit MAC_ADDRESS and OLLAMA_URL below to match your setup.

Dependencies:
    pip install wakeonlan httpx
"""

import time
import httpx
from wakeonlan import send_magic_packet

# =============================================================================
# CONFIGURATION - Edit these values for your setup
# =============================================================================
MAC_ADDRESS = "AA:BB:CC:DD:EE:FF"  # Your Mac Studio's MAC address
OLLAMA_URL = "http://192.168.1.100:11434"  # Your Mac Studio's IP
TIMEOUT = 120  # Max seconds to wait for Ollama to respond
POLL_INTERVAL = 2  # Seconds between availability checks

# =============================================================================
def wake_and_wait() -> bool:
    """
    Send a Wake-on-LAN magic packet and wait for Ollama to become available.

    Returns:
        True if Ollama became available, False if timeout was reached.
    """
    print(f"Sending magic packet to {MAC_ADDRESS}...")
    send_magic_packet(MAC_ADDRESS)

    start = time.time()
    while time.time() - start < TIMEOUT:
        try:
            response = httpx.get(f"{OLLAMA_URL}/api/tags", timeout=2)
            if response.status_code == 200:
                elapsed = int(time.time() - start)
                models = [m["name"] for m in response.json().get("models", [])]
                print(f"Ollama is ready! (took {elapsed}s)")
                if models:
                    print(f"Available models: {', '.join(models)}")
                else:
                    print("No models installed yet.")
                return True
        except (httpx.ConnectError, httpx.TimeoutException):
            elapsed = int(time.time() - start)
            print(f"Waiting for Ollama... ({elapsed}s)")

        time.sleep(POLL_INTERVAL)

    print(f"Timeout after {TIMEOUT}s – Mac didn't wake or Ollama didn't start.")
    return False

if __name__ == "__main__":
    success = wake_and_wait()
    exit(0 if success else 1)

Run it manually before starting your development session:

python wake_ollama.py

Once Ollama is ready, use it normally with the standard client.

Lessons from Production

I’ve been running this setup for four months with a team of six developers. A few observations:

• Wake frequency: The Mac wakes 3–5 times per day on average. Most wakes happen at the start of the workday (9–10 AM) and after lunch (2 PM). Outside those windows, the Mac stays awake because someone’s actively using it. This matches our expectation — it’s not a high-traffic production service, it’s developer tooling with bursty usage.
• Cache tuning: I started with cache_ttl=600 (10 minutes) and the Mac set to sleep after 5 minutes. This caused frequent failures because the cache thought the server was up when it had already slept. Dropping to cache_ttl=180 and increasing Mac sleep to 10 minutes eliminated the issue.
• Network cable management: Running an Ethernet cable to the Mac Studio in an open office is ugly. We ended up putting the machine in a small server closet (just a locked cabinet with ventilation) and running a single cable to the switch. This had the bonus effect of reducing noise (Mac Studio fans under load are noticeable in a quiet office).
• Developer adoption: The transparent wake behavior was critical. I initially tried a manual wake script, but developers forgot to run it half the time and got confused by connection errors. With the wrapper, they just write normal code and it works. Adoption went from 30% (with manual wake) to 100% (with auto-wake) in two weeks.
• Failed wake debugging: Twice, the Mac didn’t wake properly. Both times, it was because someone had unplugged the Ethernet cable for a different device and forgot to plug it back. WoL silently fails if the cable is disconnected. The fix: label the cable “DO NOT UNPLUG - OR BY A PIZZA FOR THE TEAM” and document the failure mode in the team wiki.

This article reflects my professional perspective. Drafting was assisted by Claude, but the insights and final curation are entirely my own.

Sovereign AI Strategist @ bluetuple.ai | Exploring autonomous AI systems, agentic architectures, and secure AI independence. Writing about what it takes to build AI that stays under your control.