github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-05-06 08:02:14 -05:00
Code Issues 14.5k Packages Projects Releases 120 Wiki Activity

[GH-ISSUE #11076] [Feature] - Configuration File Support for Server Settings #53820

New Issue
Open
opened 2026-04-29 04:48:52 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-04-29 04:48:52 -05:00
Owner
Copy Link

Originally created by @ondrovic on GitHub (Jun 15, 2025).
Original GitHub issue: https://github.com/ollama/ollama/issues/11076

Feature Request: Configuration File Support for Server Settings

Summary

Request for a standardized configuration file to manage Ollama server settings, particularly network binding configurations, as an alternative to environment variables.

Problem Statement

Currently, Ollama requires environment variables for all configuration options, including basic server settings like OLLAMA_HOST for network binding. This approach presents several usability and operational challenges:

Current Issues:

  1. Platform Inconsistency: Environment variable management differs significantly across operating systems (Windows system properties vs. Linux shell profiles vs. macOS launchd configurations)

  2. Poor Developer Experience: Setting up network access requires:

    • Manually configuring environment variables
    • Remembering to set them before each execution
    • Platform-specific knowledge for permanent configuration

  3. Deployment Complexity:

    • No standardized way to version-control server configurations
    • Difficult to manage multiple deployment environments
    • Requires custom scripts or platform-specific service configurations

  4. Discoverability: Users must consult documentation to find available configuration options rather than having a self-documenting configuration file

Proposed Solution

Implement a configuration file system that:

1. Standard Configuration File Format

  • Use a widely-adopted format (TOML, YAML, or JSON)
  • Follow OS-specific standard configuration paths:
    • Linux: ~/.config/ollama/config.toml or /etc/ollama/config.toml
    • macOS: ~/Library/Application Support/ollama/config.toml
    • Windows: %APPDATA%\ollama\config.toml

2. Hierarchical Configuration Precedence

Configuration lookup order (highest to lowest priority):

  1. Command-line flags
  2. Environment variables (maintaining backward compatibility)
  3. User configuration file (~/.config/ollama/config.toml)
  4. System-wide configuration file (/etc/ollama/config.toml)
  5. Built-in defaults

3. Example Configuration File

# Ollama Server Configuration

[server]
# Network binding configuration
# Set to "0.0.0.0:11434" to bind to all interfaces
# Set to "127.0.0.1:11434" for localhost only (default)
host = "0.0.0.0:11434"

# Allowed origins for CORS
origins = ["http://localhost:3000", "https://example.com"]

[models]
# Directory to store models
path = "~/.ollama/models"

# Model loading behavior
keep_alive = "5m"
max_loaded_models = 3
max_queue = 512

[performance]
# Number of parallel requests
num_parallel = 4

# GPU configuration
gpu_overhead = 0

[logging]
# Enable debug logging
debug = false

Benefits

For Users:

  • Simplified Setup: Single configuration file for all settings
  • Version Control: Configuration can be tracked in dotfiles/repositories
  • Self-Documenting: Configuration options visible with descriptions
  • Platform Agnostic: Same configuration works across operating systems

For System Administrators:

  • Standardized Deployment: Consistent configuration management
  • Environment Management: Easy to maintain dev/staging/production configs
  • Security: Centralized configuration with appropriate file permissions

For Developers:

  • Integration: Easier to build tooling around standardized configuration
  • Documentation: Configuration schema can be automatically generated
  • Testing: Simplified configuration for different test scenarios

Implementation Considerations

  1. Backward Compatibility: Environment variables should continue to work and take precedence over file configuration
  2. Configuration Validation: Validate configuration at startup with helpful error messages
  3. Hot Reloading: Consider supporting configuration reload without restart (future enhancement)
  4. Documentation: Update all relevant documentation to show both environment variable and configuration file approaches

Use Case Example

Current Workflow (Environment Variables):

# Windows - requires setting system environment variable or:
set OLLAMA_HOST=0.0.0.0:11434
ollama serve

# Linux/macOS - requires remembering to set every time or modifying shell profile
export OLLAMA_HOST=0.0.0.0:11434
ollama serve

Proposed Workflow (Configuration File):

# Create config once
echo 'host = "0.0.0.0:11434"' > ~/.config/ollama/config.toml

# Just run - works everywhere
ollama serve

Related Issues

This request builds upon previous configuration-related discussions:

  • Related to the broader configuration file request in #7089
  • Addresses deployment concerns mentioned in #3516
  • Complements model management configuration requests in #4883

Conclusion

A configuration file system would significantly improve Ollama's usability, particularly for network configuration scenarios, while maintaining full backward compatibility with the current environment variable approach. This enhancement would align Ollama with standard practices used by other server applications and development tools.

Originally created by @ondrovic on GitHub (Jun 15, 2025). Original GitHub issue: https://github.com/ollama/ollama/issues/11076 # Feature Request: Configuration File Support for Server Settings ## Summary Request for a standardized configuration file to manage Ollama server settings, particularly network binding configurations, as an alternative to environment variables. ## Problem Statement Currently, Ollama requires environment variables for all configuration options, including basic server settings like `OLLAMA_HOST` for network binding. This approach presents several usability and operational challenges: ### Current Issues: 1. **Platform Inconsistency**: Environment variable management differs significantly across operating systems (Windows system properties vs. Linux shell profiles vs. macOS launchd configurations) 2. **Poor Developer Experience**: Setting up network access requires: - Manually configuring environment variables - Remembering to set them before each execution - Platform-specific knowledge for permanent configuration 3. **Deployment Complexity**: - No standardized way to version-control server configurations - Difficult to manage multiple deployment environments - Requires custom scripts or platform-specific service configurations 4. **Discoverability**: Users must consult documentation to find available configuration options rather than having a self-documenting configuration file ## Proposed Solution Implement a configuration file system that: ### 1. **Standard Configuration File Format** - Use a widely-adopted format (TOML, YAML, or JSON) - Follow OS-specific standard configuration paths: - Linux: `~/.config/ollama/config.toml` or `/etc/ollama/config.toml` - macOS: `~/Library/Application Support/ollama/config.toml` - Windows: `%APPDATA%\ollama\config.toml` ### 2. **Hierarchical Configuration Precedence** Configuration lookup order (highest to lowest priority): 1. Command-line flags 2. Environment variables (maintaining backward compatibility) 3. User configuration file (`~/.config/ollama/config.toml`) 4. System-wide configuration file (`/etc/ollama/config.toml`) 5. Built-in defaults ### 3. **Example Configuration File** ```toml # Ollama Server Configuration [server] # Network binding configuration # Set to "0.0.0.0:11434" to bind to all interfaces # Set to "127.0.0.1:11434" for localhost only (default) host = "0.0.0.0:11434" # Allowed origins for CORS origins = ["http://localhost:3000", "https://example.com"] [models] # Directory to store models path = "~/.ollama/models" # Model loading behavior keep_alive = "5m" max_loaded_models = 3 max_queue = 512 [performance] # Number of parallel requests num_parallel = 4 # GPU configuration gpu_overhead = 0 [logging] # Enable debug logging debug = false ``` ## Benefits ### **For Users:** - **Simplified Setup**: Single configuration file for all settings - **Version Control**: Configuration can be tracked in dotfiles/repositories - **Self-Documenting**: Configuration options visible with descriptions - **Platform Agnostic**: Same configuration works across operating systems ### **For System Administrators:** - **Standardized Deployment**: Consistent configuration management - **Environment Management**: Easy to maintain dev/staging/production configs - **Security**: Centralized configuration with appropriate file permissions ### **For Developers:** - **Integration**: Easier to build tooling around standardized configuration - **Documentation**: Configuration schema can be automatically generated - **Testing**: Simplified configuration for different test scenarios ## Implementation Considerations 1. **Backward Compatibility**: Environment variables should continue to work and take precedence over file configuration 2. **Configuration Validation**: Validate configuration at startup with helpful error messages 3. **Hot Reloading**: Consider supporting configuration reload without restart (future enhancement) 4. **Documentation**: Update all relevant documentation to show both environment variable and configuration file approaches ## Use Case Example **Current Workflow (Environment Variables):** ```bash # Windows - requires setting system environment variable or: set OLLAMA_HOST=0.0.0.0:11434 ollama serve # Linux/macOS - requires remembering to set every time or modifying shell profile export OLLAMA_HOST=0.0.0.0:11434 ollama serve ``` **Proposed Workflow (Configuration File):** ```bash # Create config once echo 'host = "0.0.0.0:11434"' > ~/.config/ollama/config.toml # Just run - works everywhere ollama serve ``` ## Related Issues This request builds upon previous configuration-related discussions: - Related to the broader configuration file request in #7089 - Addresses deployment concerns mentioned in #3516 - Complements model management configuration requests in #4883 ## Conclusion A configuration file system would significantly improve Ollama's usability, particularly for network configuration scenarios, while maintaining full backward compatibility with the current environment variable approach. This enhancement would align Ollama with standard practices used by other server applications and development tools.
GiteaMirror added the feature request label 2026-04-29 04:48:52 -05:00
GiteaMirror commented 2026-04-29 04:48:54 -05:00
Author
Owner
Copy Link

@IngussNeilands commented on GitHub (Jun 30, 2025):

+1 for this

<!-- gh-comment-id:3019490112 --> @IngussNeilands commented on GitHub (Jun 30, 2025): +1 for this
GiteaMirror commented 2026-04-29 04:48:55 -05:00
Author
Owner
Copy Link

@cutlery commented on GitHub (Feb 22, 2026):

+1

<!-- gh-comment-id:3941634286 --> @cutlery commented on GitHub (Feb 22, 2026): +1
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label feature request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#53820
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?