DEV Community: Eric Berry

How to Set Up Ollama on Windows for Network Access via Tailscale

Eric Berry — Wed, 11 Jun 2025 20:50:40 +0000

Running large language models locally with Ollama is fantastic, but what if you want to access your powerful Windows machine's Ollama instance from other devices on your network? This guide shows you how to set up Ollama on Windows 11 and make it securely accessible to any device on your Tailscale network.

Why This Setup?

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

Ollama running automatically as a background service on Windows
Secure access from any device on your Tailscale network
No GUI clutter or manual startup required
A robust setup that survives reboots

Prerequisites

Windows 11 Pro with administrator access
Tailscale account and Tailscale installed on your devices
Basic familiarity with PowerShell

Step 1: Install Ollama on Windows

Download the Windows installer from ollama.ai
Run the installer and complete the setup
Ollama will install and likely add itself to Windows startup

Step 2: Install and Configure Tailscale

Download Tailscale from tailscale.com
Install and authenticate with your Tailscale account
Note your Windows machine's Tailscale IP address:

   tailscale ip -4

You'll get something like 100.119.78.59

Step 3: Stop Default Ollama Processes

The Windows installer starts Ollama automatically, but it only listens on localhost by default. We need to stop all running instances:

# Check for running Ollama processes
tasklist | findstr ollama

# Kill any running processes (replace PID with actual process IDs)
taskkill /f /pid [PID_NUMBER]

Step 4: Configure Ollama for Network Access

Set the environment variable to make Ollama listen on all network interfaces:

# Set system-wide environment variable
[Environment]::SetEnvironmentVariable("OLLAMA_HOST", "0.0.0.0:14434", "Machine")

Note: We're using port 14434 instead of the default 11434 to avoid conflicts, but you can use any available port.

Step 5: Create an Automatic Startup Task

Instead of running Ollama as a manual service, we'll create a scheduled task that starts automatically:

# Create scheduled task (run as administrator)
schtasks /create /tn "OllamaAutoStart" /tr "C:\Users\[YOUR_USERNAME]\AppData\Local\Programs\Ollama\ollama.exe serve" /sc onstart /ru SYSTEM

Replace [YOUR_USERNAME] with your actual Windows username.

Step 6: Test the Setup

Start the scheduled task manually to test:

# Run the task
schtasks /run /tn "OllamaAutoStart"

# Verify it's running
tasklist | findstr ollama

You should see Ollama running in the background.

Step 7: Test Network Access via Tailscale

From another device on your Tailscale network, test the connection:

curl http://[YOUR_TAILSCALE_IP]:14434/api/tags

Replace [YOUR_TAILSCALE_IP] with the IP address from Step 2.

If successful, you should get a JSON response listing available models.

Step 8: Disable GUI Auto-Start (Optional)

If you prefer Ollama to run invisibly without the system tray icon:

Press Ctrl + Shift + Esc to open Task Manager
Go to the "Startup" tab
Find "Ollama" and right-click → "Disable"

Step 9: Configure Other Devices

On any other device in your Tailscale network, point Ollama to your Windows server:

export OLLAMA_HOST=http://[YOUR_TAILSCALE_IP]:14434

Now commands like ollama list, ollama pull llama2, and ollama run llama2 will use your Windows machine instead of requiring local installation.

Troubleshooting

Port Conflicts

If you get a "bind: Only one usage of each socket address" error:

# Check what's using the port
netstat -ano | findstr :14434

# Kill conflicting processes
taskkill /f /pid [PID]

Service Won't Start

If the scheduled task fails to start Ollama:

# Check task status
schtasks /query /tn "OllamaAutoStart"

# Delete and recreate if needed
schtasks /delete /tn "OllamaAutoStart"

Environment Variable Not Working

Ensure the environment variable is set system-wide:

# Check current value
$env:OLLAMA_HOST

# Reset if needed
[Environment]::SetEnvironmentVariable("OLLAMA_HOST", "0.0.0.0:14434", "Machine")

Security Considerations

Tailscale provides encryption: All traffic between your devices is end-to-end encrypted
No public internet exposure: Your Ollama instance is only accessible within your Tailscale network
Access control: Use Tailscale's ACL features to restrict which devices can access your Ollama server

Benefits of This Setup

Centralized compute: Use your powerful Windows machine's GPU from lightweight devices
Consistent models: All devices share the same model downloads and configurations
Resource efficiency: No need to run Ollama on every device
Secure remote access: Access your AI models from anywhere with Tailscale
Automatic startup: Everything works after reboots without manual intervention

Conclusion

You now have a robust, automatically-starting Ollama server that's securely accessible across all your devices via Tailscale. This setup is perfect for scenarios where you have one powerful machine but want to access AI models from laptops, phones, or other devices anywhere you have internet access.

The combination of Ollama's simplicity, Windows' scheduled tasks, and Tailscale's secure networking creates a professional-grade AI inference setup that "just works."

Implementing the Active Record Pattern in Python with SQLModel

Eric Berry — Sun, 26 Jan 2025 14:25:00 +0000

While working with SQLModel in Python, I found myself missing the elegant database interactions of Rails. With a lot of assistance from Claude, I discovered this pattern for bringing Active Record-style elegance to Python while maintaining its strong typing benefits.

When transitioning from Ruby on Rails to Python, many developers miss the elegance of Active Record. While Python's SQLAlchemy (and by extension, SQLModel) takes a different approach by default, we can implement a similar pattern that brings the convenience of Rails-style models to our Python applications while maintaining type safety and following Python best practices.

The Active Record Pattern

The Active Record pattern, popularized by Ruby on Rails, treats database records as objects with methods for database operations. Instead of using separate repository classes or data access objects (DAOs), the model itself knows how to interact with the database.

For example, in Rails you might write:

# Find a record
user = User.find(123)

# Update it
user.name = "New Name"
user.save

# Create a new record
post = Post.create(title: "Hello World")

Implementing in Python with SQLModel

While Python's SQLModel doesn't provide this pattern out of the box, we can implement it with a base class that provides these familiar operations. Here's how:

1. The Base CRUD Model

First, we create a base class that implements common CRUD operations:

from typing import TypeVar, List, Optional, Tuple
from datetime import datetime
import uuid
from sqlmodel import SQLModel, Session, select
from sqlalchemy import func

T = TypeVar("T", bound="CRUDModel")

class CRUDModel(SQLModel):
    id: str = Field(
        default_factory=lambda: str(uuid.uuid4()),
        primary_key=True
    )
    created_at: datetime = Field(default_factory=datetime.utcnow)
    updated_at: datetime = Field(default_factory=datetime.utcnow)

    @classmethod
    def all(cls: type[T], session: Session) -> List[T]:
        statement = select(cls)
        return session.exec(statement).all()

    @classmethod
    def find(cls: type[T], session: Session, id: str) -> Optional[T]:
        statement = select(cls).where(cls.id == id)
        return session.exec(statement).first()

    @classmethod
    def create(cls: type[T], session: Session, **kwargs) -> T:
        db_obj = cls(**kwargs)
        session.add(db_obj)
        session.commit()
        session.refresh(db_obj)
        return db_obj

    def update(self: T, session: Session, **kwargs) -> T:
        kwargs['updated_at'] = datetime.utcnow()
        for key, value in kwargs.items():
            setattr(self, key, value)
        session.add(self)
        session.commit()
        session.refresh(self)
        return self

    def delete(self: T, session: Session) -> None:
        session.delete(self)
        session.commit()

    @classmethod
    def paginate(
        cls: type[T],
        session: Session,
        page: int = 1,
        per_page: int = 20
    ) -> Tuple[List[T], int]:
        statement = select(cls)
        total = session.exec(select(func.count()).select_from(statement)).one()

        offset = (page - 1) * per_page
        results = session.exec(
            statement.offset(offset).limit(per_page)
        ).all()

        return results, total

2. Using the Pattern in Your Models

With our base class defined, we can create models that inherit from it:

class Article(CRUDModel, table=True):
    title: str = Field(..., description="Article title")
    content: str = Field(..., description="Article content")
    status: str = Field(default="draft")

    # Relationships
    comments: List["Comment"] = Relationship(
        back_populates="article",
        sa_relationship_kwargs={"cascade": "all, delete-orphan"}
    )

3. Using the Models

Now we can use our models with a familiar Rails-like syntax, while maintaining Python's explicit session management:

from db.session import get_session

# List all articles
with get_session() as session:
    articles = Article.all(session)

# Find a specific article
with get_session() as session:
    article = Article.find(session, "some-uuid")
    if article:
        print(f"Found: {article.title}")

# Create a new article
with get_session() as session:
    article = Article.create(
        session,
        title="My New Article",
        content="Some content here"
    )

# Update an article
with get_session() as session:
    article = Article.find(session, "some-uuid")
    if article:
        updated = article.update(
            session,
            title="Updated Title",
            content="New content"
        )

# Delete an article
with get_session() as session:
    article = Article.find(session, "some-uuid")
    if article:
        article.delete(session)

# Pagination
with get_session() as session:
    articles, total = Article.paginate(session, page=2, per_page=10)

Key Differences from Rails

While this pattern brings Rails-like convenience to Python, there are some important differences to note:

Explicit Session Management: Python requires explicit session management, which promotes better understanding of database transactions.

# Python with SQLModel
with get_session() as session:
    article = Article.create(session, title="Hello")

# vs Rails
article = Article.create(title: "Hello")

Type Safety: Python's type hints provide better IDE support and catch errors earlier.

class Article(CRUDModel, table=True):
    title: str  # Type safety!
    views: int = Field(default=0)

Class Methods: Python uses explicit @classmethod decorators for operations that don't require an instance.
Error Handling: Python encourages explicit exception handling:

with get_session() as session:
    try:
        article = Article.find(session, "non-existent")
        if article is None:
            raise HTTPException(status_code=404, detail="Article not found")
    except Exception as e:
        # Handle other database errors
        raise HTTPException(status_code=500, detail=str(e))

Best Practices

When using this pattern in Python, keep these best practices in mind:

Always Use Context Managers:

   # Good
   with get_session() as session:
       article = Article.create(session, title="Hello")

   # Not Good
   session = get_session()
   article = Article.create(session, title="Hello")
   session.close()

Type Safety:

   # Use proper type hints
   def get_article(id: str) -> Optional[Article]:
       with get_session() as session:
           return Article.find(session, id)

Validation:

   class Article(CRUDModel, table=True):
       title: str = Field(..., min_length=1, max_length=100)
       status: str = Field(
           default="draft",
           validate_default=True,
           validator=lambda x: x in ["draft", "published"]
       )

Relationship Management:

   class Article(CRUDModel, table=True):
       # Use cascade deletes appropriately
       comments: List["Comment"] = Relationship(
           back_populates="article",
           sa_relationship_kwargs={"cascade": "all, delete-orphan"}
       )

Conclusion

The Active Record pattern can be effectively implemented in Python while maintaining type safety and following Python best practices. While it requires more explicit session management than Rails, it provides similar convenience while giving developers more control over database operations.

This pattern is particularly useful for:

Teams transitioning from Rails to Python
Projects that prefer model-centric database operations
Applications where type safety and explicit session management are important

Remember that this is just one approach to database operations in Python. SQLModel and SQLAlchemy support other patterns like repositories or data access objects, which might be more appropriate for certain use cases.

Resources

Build a Rails script watcher/runner using fswatch

Eric Berry — Wed, 14 Sep 2022 19:56:29 +0000

I often find myself spending a lot of time in the Rails console testing out code. As my examples get more complex, I often will create a temporary ruby file to write the script, then copy-paste into the console.

Although this works ok, it is tedious and could be optimized.

Rails runner (rails r) will allow you to run a ruby script within the context of the application environment.

For example, if I had a ruby file named runme.rb and inside it had some debugging code:

puts Member.count

I could run that script using rails runner runme.rb. This is nice, but I then have to return to the terminal each time I modify the file. What if we could automate this?

fswatch is a cross-platform file change monitor. It will watch any files you specify, then run a script on change.

Let's set up a script within our Rails app to run this file automatically when it changes.

Install fswatch

It's easy to install fswatch. On a mac, you can run

$ brew install fwatch

Set up a watcher script

I created an executable bash script at bin/console-runner:

#!/bin/bash

usage() {
    echo "Watch a ruby script and use Rails runner each time it changes"
    echo ""
    echo "For example, you may have a file called \`runme.rb\` that you would"
    echo "run using Rails runner (e.g. \`rails runner runme.rb\`). This script"
    echo "will watch the file and run it each time there is a change."
    echo ""
    echo "Usage:"
    echo "  ./script/console-runner <ruby-script>"
}

if [ $# -eq 0 ]; then
    usage
    exit 1
else
  fswatch -0 -o $1 | xargs -0 -n1 -I{} rails runner $1
fi

Be sure to make the script executable:

$ chmod +x bin/console-runner

We can test the script documentation by running the command:

$ ./bin/console-runner
Watch a ruby script and use Rails runner each time it changes

For example, you may have a file called `runme.rb` that you would
run using Rails runner (e.g. `rails runner runme.rb`). This script
will watch the file and run it each time there is a change.

Usage:
  ./bin/console-runner <ruby-script>

Create your console script to be watched

Next, I created a file in the root folder of my Rails app called runme.rb.

puts Member.count
puts Rails.env

Run the script

Finally, I can run the script:

./bin/console-runner runme.rb

Success! Now each time I modify runme.rb, the script will re-run.

Ruby Scripting: Kill Process by Port

Eric Berry — Thu, 01 Apr 2021 15:06:59 +0000

Usage

killports [PORT1] [PORT2] ...

Example: killports 3000 5000

Code

#!/Users/eberry/.asdf/shims/ruby

# See https://www.devdungeon.com/content/enhanced-shell-scripting-ruby

require "amazing_print"

def echo_success(message, port, pid=nil)
  puts [
    "👍🏻",
    port.to_s.yellow,
    pid.nil? ? nil : pid.to_s.cyan,
    message.to_s.white
  ].compact.join(" ")
end

def echo_failed(message, port, pid=nil)
  puts [
    "👎🏻",
    port.to_s.yellow,
    pid.nil? ? nil : pid.to_s.cyan,
    message.to_s.red
  ].compact.join(" ")
end

ARGV.each { |arg|
  port = arg.chomp
  pid = `lsof -t -i tcp:#{port}`.chomp
  if pid.to_i > 0
    _result = `sudo kill #{pid}`

    if $?.success?
      echo_success("killed", port, pid)
    else
      echo_failed("no such process", port, pid)
    end
  else
    echo_success("was not in use", port)
  end
}

if ARGV.empty?
  puts "Usage: ".yellow + "killports [PORT1] [PORT2] ..."
end

exit(0)