TL;DR
MTP (Model Transfer Protocol) is an experimental feature in Ollama that enables direct model transfers between Ollama instances without re-downloading from the registry. Instead of each server pulling a 7GB model from ollama.com, one instance can push it directly to another over your local network. This matters for air-gapped environments, bandwidth-constrained deployments, and multi-node setups where you want consistent model versions across machines.
The basic workflow: enable MTP on your source server with OLLAMA_ORIGINS=* (or specific IPs), then use ollama push with a target URL instead of a registry path. Your receiving server must also allow the connection via OLLAMA_ORIGINS. Models transfer as GGUF blobs over HTTP, preserving quantization and adapter layers.
export OLLAMA_ORIGINS="http://192.168.1.50:11434"
ollama serve
# Target server
export OLLAMA_ORIGINS="http://192.168.1.40:11434"
ollama serve
# Push from source
ollama push llama3.2:7b http://192.168.1.50:11434/api/push
Common use cases include homelab clusters where you want identical model versions on multiple nodes, offline deployments where internet access is restricted, and development environments where you test model variations before promoting them. MTP does not replace the registry for public model distribution – it complements it for internal transfers.
Caution: MTP bypasses registry authentication and model verification. Only transfer models between servers you control. Validate model hashes after transfer if integrity matters. The feature remains experimental in 2026 and may change behavior between Ollama releases. Always test transfers in non-production environments first, especially when moving fine-tuned or custom models that lack registry checksums.
Network security matters: OLLAMA_ORIGINS=* allows any client to push models. Use specific IP addresses or CIDR ranges in production to limit exposure.
Understanding Ollama in Multi-User Contexts
Ollama runs as a single-process service that handles all incoming requests through its REST API on port 11434. When multiple users or applications connect simultaneously, Ollama queues requests and processes them sequentially by default. This works well for small teams or personal use, but understanding the concurrency model becomes critical as demand grows.
Each model loaded into memory consumes VRAM proportional to its size and quantization level. When a user requests llama3.2:3b while another is using mistral:7b, Ollama must either keep both models in memory or swap them. The service prioritizes keeping recently-used models loaded, but frequent model switching causes noticeable latency as models reload from disk.
# Check currently loaded models
curl http://localhost:11434/api/tags
# Monitor active requests (no built-in endpoint -- use system tools)
ss -tunap | grep 11434
Concurrent Request Handling
Ollama processes one inference request at a time per model. If three users simultaneously query the same model, requests queue behind each other. This differs from cloud services that spin up multiple instances. For teams running shared Ollama instances, this means response times increase linearly with concurrent users hitting the same model.
Network Access Configuration
By default, Ollama binds to localhost only. Multi-user deployments require explicit network exposure:
# Allow network access
export OLLAMA_HOST=0.0.0.0:11434
systemctl restart ollama
Set OLLAMA_ORIGINS to control which web applications can access the API from browsers. Without proper CORS configuration, web-based tools like Open WebUI cannot connect from different hosts.
Caution: Exposing Ollama to your network without authentication means any user can consume GPU resources and access all loaded models. Consider running behind a reverse proxy with authentication for production multi-user scenarios.
Reverse Proxy Setup for Ollama
Running Ollama behind a reverse proxy adds TLS termination, access control, and the ability to serve multiple AI services from a single domain. Nginx and Caddy both work well for this purpose.
Create a new site configuration that proxies requests to Ollama’s default port 11434:
server {
listen 443 ssl http2;
server_name ollama.example.com;
ssl_certificate /etc/letsencrypt/live/ollama.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/ollama.example.com/privkey.pem;
location / {
proxy_pass http://127.0.0.1:11434;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# Streaming support for model responses
proxy_buffering off;
proxy_read_timeout 300s;
}
}
The proxy_buffering off directive ensures streaming responses work correctly when generating long outputs.
Caddy Configuration
Caddy provides automatic HTTPS with a simpler configuration:
ollama.example.com {
reverse_proxy localhost:11434
}
CORS and Origin Control
If you plan to access Ollama from web applications, configure OLLAMA_ORIGINS to allow specific domains:
export OLLAMA_ORIGINS="https://chat.example.com,https://app.example.com"
systemctl restart ollama
This prevents unauthorized web applications from using your Ollama instance.
Authentication Layer
Add basic authentication in Nginx to restrict access:
location / {
auth_basic "Ollama Access";
auth_basic_user_file /etc/nginx/.htpasswd;
proxy_pass http://127.0.0.1:11434;
}
Generate credentials with htpasswd -c /etc/nginx/.htpasswd username.
Caution: Always test proxy configurations with nginx -t or caddy validate before reloading. Monitor logs during initial deployment to catch connection issues early.
Managing Multiple Models and Users
Ollama stores models in a local library that grows quickly when serving multiple users. By default, models live in /usr/share/ollama/.ollama/models on Linux, but you can relocate this with the OLLAMA_MODELS environment variable. Point it to a dedicated volume with sufficient space:
export OLLAMA_MODELS=/mnt/storage/ollama-models
systemctl restart ollama
List installed models with ollama list to audit what’s consuming disk space. Remove unused models with ollama rm llama2:13b to reclaim storage. Most teams find that keeping three to five actively-used models covers their needs without bloating the system.
Multi-User Access Patterns
Ollama’s REST API on port 11434 handles concurrent requests from multiple clients. Set OLLAMA_ORIGINS to control which web applications can access the API:
export OLLAMA_ORIGINS="https://chat.internal.company.com,https://docs.internal.company.com"
For shared environments, consider running Ollama behind a reverse proxy like Caddy or nginx. This lets you add authentication, rate limiting, and request logging without modifying Ollama itself. A basic Caddy configuration:
ollama.internal.company.com {
reverse_proxy localhost:11434
basicauth {
alice $2a$14$hashed_password_here
bob $2a$14$another_hashed_password
}
}
Resource Allocation
When multiple users share one Ollama instance, GPU memory becomes the bottleneck. The OLLAMA_NUM_GPU variable controls how many GPUs Ollama uses, but it doesn’t partition memory between users. Monitor GPU utilization with nvidia-smi and consider running separate Ollama instances on different ports for workload isolation. Each instance can serve a different model size based on team needs – smaller models for quick queries, larger models for complex analysis tasks.
Caution: Always validate AI-generated configuration snippets before applying them to production systems. Test changes in a development environment first.
Network Configuration and Security
Ollama listens on port 11434 by default. If you’re running it on a server accessible from other machines, configure your firewall to restrict access. On Ubuntu or Debian systems with ufw:
sudo ufw allow from 192.168.1.0/24 to any port 11434
sudo ufw enable
This limits Ollama access to your local subnet. For single-machine access only, bind Ollama to localhost by setting OLLAMA_HOST=127.0.0.1:11434 in your systemd service file or environment.
CORS and Origin Controls
The OLLAMA_ORIGINS environment variable controls which web origins can access the API. By default, Ollama accepts requests from any origin. Lock this down for production:
export OLLAMA_ORIGINS="http://localhost:3000,http://192.168.1.50:8080"
This allows only your Open WebUI instance and a specific internal application to make requests. Restart the Ollama service after changing environment variables.
TLS Termination with Nginx
For remote access, place Ollama behind a reverse proxy with TLS. Here’s a minimal nginx configuration:
server {
listen 443 ssl;
server_name ollama.internal.example.com;
ssl_certificate /etc/letsencrypt/live/ollama.internal.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/ollama.internal.example.com/privkey.pem;
location / {
proxy_pass http://127.0.0.1:11434;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
Keep Ollama bound to localhost and let nginx handle external connections. Add HTTP basic auth or client certificates for additional protection. Never expose port 11434 directly to the internet – the API has no built-in authentication and accepts any valid model inference request.
Installation and Configuration Steps
Start by installing Ollama on your Linux system using the official installation script:
curl -fsSL https://ollama.com/install.sh | sh
This script detects your distribution and installs the appropriate package. After installation completes, verify Ollama is running:
systemctl status ollama
The service should start automatically and listen on port 11434. Pull a model suitable for MTP tasks – codellama works well for protocol analysis:
ollama pull codellama:13b
Configuring Environment Variables
Create a systemd override to set environment variables for your Ollama service:
sudo mkdir -p /etc/systemd/system/ollama.service.d
sudo nano /etc/systemd/system/ollama.service.d/override.conf
Add configuration for GPU allocation and network access:
[Service]
Environment="OLLAMA_NUM_GPU=1"
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_ORIGINS=http://localhost:*,http://192.168.1.*"
The OLLAMA_NUM_GPU variable controls GPU layer offloading. Set OLLAMA_ORIGINS to allow connections from your local network if accessing Ollama from other machines.
Reload and restart the service:
sudo systemctl daemon-reload
sudo systemctl restart ollama
Testing the Installation
Verify Ollama responds to API requests:
curl http://localhost:11434/api/generate -d '{
"model": "codellama:13b",
"prompt": "Parse this MTP command: GET /storage1/DCIM/IMG_001.jpg",
"stream": false
}'
Caution: When using LLM-generated MTP commands or file paths in production scripts, always validate outputs against expected formats before executing filesystem operations. AI models can hallucinate invalid device paths or command structures that may cause data loss if executed blindly.
Verification and Testing
Start by confirming Ollama responds on port 11434. A simple curl request validates the service is running:
curl http://localhost:11434/api/tags
This returns a JSON list of installed models. If you get a connection refused error, check that the Ollama service is active with systemctl status ollama or verify OLLAMA_HOST is set correctly if you changed the default binding.
Model Response Validation
Test actual inference to confirm the model processes requests:
curl http://localhost:11434/api/generate -d '{
"model": "llama3.2:3b",
"prompt": "List three Linux distributions",
"stream": false
}'
The response should include a response field with generated text. Streaming responses work differently – they return newline-delimited JSON chunks. Parse these carefully in production code.
Performance Baseline
Run a timed test to establish baseline latency for your hardware:
time curl http://localhost:11434/api/generate -d '{
"model": "llama3.2:3b",
"prompt": "Explain containerization in one sentence",
"stream": false
}'
Note the real time value. Subsequent runs should show similar performance unless you changed OLLAMA_NUM_GPU or model parameters.
Integration Testing
If you built an MTP wrapper or automation script, test it with known-good inputs before production use. Verify error handling for malformed requests, timeout scenarios, and model unavailability. Many teams run a small test suite that validates:
- Correct model selection based on task type
- Proper handling of streaming vs non-streaming modes
- Timeout behavior when models take longer than expected
- Graceful degradation when Ollama is unreachable
Caution: Always validate AI-generated commands in a test environment before running them on production systems. Models can hallucinate package names, file paths, or dangerous command combinations.
