Feat: Add Ollama Cloud API support

[HzaRashid]

Adds support for Ollama's cloud API with API key authentication. Unit tests added to verify header generation and authentication behavior.

Summary by CodeRabbit

• New Features

  • Added Ollama API key authentication support for cloud-based API access with automatic header-based authorization.

• Tests

  • Expanded test coverage for Ollama authentication, model discovery, and URL validation scenarios.

[coderabbitai]

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Walkthrough

The pull request adds API key support to the Ollama component with header-based authentication, introduces a default API URL constant, expands test coverage for authentication and URL handling, and updates a dependency version in the News Aggregator starter project.

Changes

Cohort / File(s)	Change Summary
Starter Project Configuration src/backend/base/langflow/initial_setup/starter_projects/News Aggregator.json	Google dependency version downgraded from 0.8.5 to 0.6.15
Ollama Constants src/lfx/src/lfx/base/models/ollama_constants.py	Added new constant DEFAULT_OLLAMA_API_URL with value "https://ollama.com"
Ollama Component Enhancement src/lfx/src/lfx/components/ollama/ollama.py	Added api_key SecretStrInput field; introduced headers property for Bearer token authentication; updated base URL input display name to "Ollama API URL"; integrated header propagation into HTTP requests for model discovery and capability checks; made API key requirement conditional based on URL type
Ollama Component Tests src/backend/tests/unit/components/languagemodels/test_chatollama_component.py	Updated test assertions to inspect URLs via keyword arguments; added comprehensive tests for header/API key handling in cloud vs. local URLs; added tests for base URL transformations and container environment path handling; expanded coverage for model fetching with and without authentication; added tests for field visibility/availability toggling based on URL configuration

Sequence Diagram

sequenceDiagram
    participant User
    participant Component as ChatOllamaComponent
    participant API as Ollama API

    rect rgb(200, 220, 255)
    Note over User,API: Cloud URL with API Key
    User->>Component: set base_url=DEFAULT_OLLAMA_API_URL
    Component->>Component: update_build_config() triggers
    Component->>Component: api_key becomes required
    end

    rect rgb(220, 240, 220)
    Note over Component,API: Model Discovery with Auth
    Component->>Component: build headers with Bearer token
    Component->>API: GET /tags (with headers)
    API-->>Component: model list
    Component->>API: POST /show (with headers for each model)
    API-->>Component: model capabilities
    end

    rect rgb(240, 220, 220)
    Note over User,API: Local URL (no auth)
    User->>Component: set base_url=localhost:11434
    Component->>Component: api_key set to advanced/optional
    Component->>Component: headers property returns None
    Component->>API: GET /tags (without headers)
    API-->>Component: model list
    end

    rect rgb(200, 220, 255)
    Note over Component,API: Build Model with Client Config
    Component->>Component: headers present → include client_kwargs
    Component->>Component: build llm_params with client_kwargs
    User->>Component: create ChatOllama instance
    end

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

The changes involve introducing a new authentication feature across multiple interconnected files (constants, main component, and extensive test coverage), requiring careful verification of header propagation logic, conditional API key behavior based on URL type, and test assertions reflecting the updated HTTP client usage patterns. While individual pieces are straightforward, the coordination between authentication logic, URL handling, and field visibility toggling requires thorough understanding of the complete flow.

Possibly related PRs

• fix: Strip /v1 suffix from base URL and improve error handling in OllamaComponent #10112 — Modifies the same ChatOllamaComponent methods (build_model, get_models, is_valid_ollama_url) to handle /v1 URL suffix stripping and OpenAI-compatible behavior, likely intersecting with this PR's changes to the same methods for header propagation.

Suggested labels

enhancement, size:L, lgtm

Suggested reviewers

• edwinjosechittilappilly
• ogabrielluiz
• jordanrfrazier

Pre-merge checks and finishing touches

❌ Failed checks (1 error, 2 warnings)

Check name	Status	Explanation	Resolution
Test Coverage For New Implementations	❌ Error	The PR introduces significant new Ollama Cloud API functionality including a new api_key input field, a headers property for Bearer token authentication, and logic to dynamically control field visibility based on cloud vs. local URLs. While the test file has been substantially updated with 33 test methods covering headers generation, API key field behavior, and cloud/local URL variations, there is a critical gap: the test test_update_build_config_base_url_cloud at lines 688-711 sets up the scenario correctly with mocked responses and a build_config structure, but it completely lacks assertions to verify that the api_key field becomes required and visible (advanced=False) for cloud URLs. Additionally, the implementation lacks the normalize_ollama_url() helper function recommended by the review comments, meaning URL matching will fail for common user input variations like trailing slashes or /v1 suffixes. While test infrastructure and coverage exist for most features, the incomplete test assertions and missing URL normalization represent gaps that prevent validation of core cloud URL functionality.	Add assertions to the test at lines 688-711 to verify the expected behavior: assert updated_config["api_key"]["advanced"] is False and assert updated_config["api_key"]["required"] is True to confirm the api_key field is properly configured for cloud URLs. Additionally, implement the normalize_ollama_url() helper function in ollama_constants.py as suggested in the review comments, then apply URL normalization to the cloud URL comparison logic at line 273 in ollama.py to ensure robust matching regardless of trailing slashes or /v1 suffixes in user input. These changes will complete test coverage and make the implementation more resilient.
Test Quality And Coverage	⚠️ Warning	The test suite for Ollama Cloud API support shows moderate coverage of primary functionality with proper async testing patterns using @pytest.mark.asyncio and appropriate mocking techniques. However, it has critical quality gaps. Most significantly, the test test_update_build_config_base_url_cloud (lines 684-704) executes the component logic but contains zero assertions—it does not validate that the api_key field becomes required and visible (advanced=False), which is the core behavior being tested. With only 2 error-handling tests using pytest.raises across 33 total test functions, error path coverage is severely inadequate—there are no tests for network timeouts, malformed API responses, invalid credentials, or empty-string vs. None API key distinctions. URL normalization testing is incomplete: while /v1 suffix stripping is tested for build_model and is_valid_ollama_url, there are no tests covering user inputs like https://ollama.com/ (trailing slash) or https://ollama.com/v1 (cloud URL with suffix), which would bypass the direct equality check in update_build_config at line 273. The integration test for field visibility (test_update_build_config_api_key_field_triggers_refresh) uses mocks to avoid actual state mutation verification, making it a smoke test rather than confirming real component behavior.	To bring the test suite to production quality: (1) add missing assertions to test_update_build_config_base_url_cloud checking that api_key["advanced"] becomes False and api_key["required"] becomes True when cloud URL is set; (2) implement a normalize_ollama_url() helper function in ollama_constants.py that strips trailing slashes and /v1 suffixes, then add dedicated tests for URL variants like https://ollama.com/, https://ollama.com/v1, and https://ollama.com//; (3) expand error path testing from 2 to at least 8-10 tests covering timeouts, connection failures, invalid responses, and edge cases like empty-string API keys; (4) convert test_update_build_config_api_key_field_triggers_refresh to validate actual state changes in the component instance rather than only mocking downstream calls; and (5) add negative test cases explicitly confirming headers are omitted when expected and included when expected across all HTTP methods.
Excessive Mock Usage Warning	⚠️ Warning	The test file demonstrates appropriately targeted use of mocks primarily for external dependencies (httpx HTTP calls, ChatOllama client instantiation, file system paths, and socket operations), which aligns with established best practices. The tests instantiate real ChatOllamaComponent objects 31 times and verify actual component behavior through 49 state-based assertions rather than relying solely on mock call verification (only 5 mock.assert_called assertions). The mocking is strategically applied to external, unmanaged dependencies over which the component has no control, while core component logic is tested with real instances. However, the test file lacks missing assertions that were requested in review comments—specifically, the test at lines 688-711 (test_update_build_config_base_url_cloud) has no assertions verifying that api_key field visibility changes, and there is no URL normalization helper for testing variations of cloud URLs with trailing slashes or /v1 suffixes, which limits test robustness for real-world usage patterns.	While the overall mock usage pattern is appropriate and does not indicate excessive mocking, the check fails due to missing critical test assertions and normalization logic identified in prior review comments. Add the missing assertions to verify that update_build_config correctly toggles api_key field properties (advanced, required) for cloud URLs, and implement the URL normalization helper function as suggested to handle user-provided variations like https://ollama.com/, https://ollama.com/v1, and similar inputs that should resolve to the same canonical form for cloud URL detection.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The pull request title "Feat: Add Ollama Cloud API support" accurately reflects the main changes in the PR. The substantial modifications to the Ollama component (adding api_key field, headers property, cloud URL handling, and API key behavior based on URL type) directly align with this feature objective. The title is concise, clear, and specific enough that a reviewer scanning through history would immediately understand the primary purpose of this changeset. While the PR includes peripheral changes like a dependency version modification and test updates, these are supporting changes for the core feature described in the title.
Docstring Coverage	✅ Passed	Docstring coverage is 86.96% which is sufficient. The required threshold is 80.00%.
Test File Naming And Structure	✅ Passed	The test file test_chatollama_component.py follows backend test naming conventions with the test_*.py format and demonstrates proper pytest structure including a well-organized test class TestChatOllamaComponent, three pytest fixtures for setup (component_class, default_kwargs, file_names_mapping), and appropriate use of mocking with @patch decorators and AsyncMock/MagicMock objects. All 33 test functions have descriptive names (10+ characters) that clearly explain what is being tested, such as test_update_build_config_base_url_cloud, test_headers_with_cloud_url_and_api_key, and test_build_model_strips_v1_suffix_and_logs_warning. The test suite covers both positive scenarios (successful API calls, valid configurations) and negative scenarios (missing base_url, API failures), with comprehensive edge case coverage including URL transformations for Docker/Podman containers, trailing slash/v1 suffix handling, and variations across cloud vs. local URL configurations. The integration test is clearly marked with test_build_model_integration naming, and the 18 tests related to cloud/local URLs and 11 tests for headers/auth/API keys demonstrate intentional logical organization around functional areas.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 3

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/lfx/src/lfx/components/ollama/ollama.py (1)

270-287: Fix build_config refresh: use the edited URL, normalize, and avoid brittle equality

Two issues:

• Uses exact equality against DEFAULT_OLLAMA_API_URL; fails with trailing slashes or “/v1”.
• Validates/fetches models with self.base_url even when base_url is the field being edited.

Proposed patch:

@@
-        if field_name in {"model_name", "base_url", "tool_model_enabled", "api_key"}:
-            if field_name == "base_url":
-                # API key is required for cloud Ollama
-                if field_value != DEFAULT_OLLAMA_API_URL:
-                    build_config["api_key"]["advanced"] = True
-                    build_config["api_key"]["required"] = False
-                    build_config["api_key"]["value"] = None
-                else:
-                    build_config["api_key"]["advanced"] = False
-                    build_config["api_key"]["required"] = True
-            if await self.is_valid_ollama_url(self.base_url):
+        if field_name in {"model_name", "base_url", "tool_model_enabled", "api_key"}:
+            # Prefer the candidate URL under edit; normalize for comparison/requests
+            candidate_url = field_value if field_name == "base_url" else self.base_url
+            candidate_url = (candidate_url or "").rstrip("/").removesuffix("/v1")
+            cloud_base = DEFAULT_OLLAMA_API_URL.rstrip("/")
+            if field_name == "base_url":
+                # API key is required for cloud Ollama
+                if candidate_url == cloud_base:
+                    build_config["api_key"]["advanced"] = False
+                    build_config["api_key"]["required"] = True
+                else:
+                    build_config["api_key"]["advanced"] = True
+                    build_config["api_key"]["required"] = False
+                    build_config["api_key"]["value"] = None
+            if candidate_url and await self.is_valid_ollama_url(candidate_url):
                 tool_model_enabled = build_config["tool_model_enabled"].get("value", False) or self.tool_model_enabled
-                build_config["model_name"]["options"] = await self.get_models(
-                    self.base_url, tool_model_enabled=tool_model_enabled
-                )
+                build_config["model_name"]["options"] = await self.get_models(
+                    candidate_url, tool_model_enabled=tool_model_enabled
+                )
             else:
                 build_config["model_name"]["options"] = []

🧹 Nitpick comments (3)

src/lfx/src/lfx/components/ollama/ollama.py (3)

242-247: Headers passed for URL validation — OK

Using self.headers here is fine; local instances with no key will pass None. Consider adding a request timeout to avoid hangs.

Example:

async with httpx.AsyncClient(timeout=self.timeout or 10.0) as client:
    ...

---

328-334: Set explicit HTTP timeouts for model listing calls

Default httpx timeouts can be high; wire self.timeout (or a sane default) into AsyncClient or per‑request to avoid UI stalls.

Example:

async with httpx.AsyncClient(timeout=self.timeout or 15.0) as client:
    tags_response = await client.get(url=tags_url, headers=self.headers)
    ...

Also applies to: 347-351

---

371-376: Harden headers() for non‑string values

SecretStrInput can technically hold non‑str; guard the type and strip safely.

-    def headers(self) -> dict[str, str] | None:
-        """Get the headers for the Ollama API."""
-        if self.api_key and self.api_key.strip():
-            return {"Authorization": f"Bearer {self.api_key}"}
-        return None
+    def headers(self) -> dict[str, str] | None:
+        """Get the headers for the Ollama API."""
+        key = self.api_key if isinstance(self.api_key, str) else None
+        if key and key.strip():
+            return {"Authorization": f"Bearer {key.strip()}"}
+        return None

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d707176 and 1263c3c.

📒 Files selected for processing (4)

• src/backend/base/langflow/initial_setup/starter_projects/News Aggregator.json (1 hunks)
• src/backend/tests/unit/components/languagemodels/test_chatollama_component.py (4 hunks)
• src/lfx/src/lfx/base/models/ollama_constants.py (1 hunks)
• src/lfx/src/lfx/components/ollama/ollama.py (9 hunks)

🧰 Additional context used

📓 Path-based instructions (8)

src/backend/tests/unit/components/**/*.py

📄 CodeRabbit inference engine (.cursor/rules/backend_development.mdc)

src/backend/tests/unit/components/**/*.py: Mirror the component directory structure for unit tests in src/backend/tests/unit/components/
Use ComponentTestBaseWithClient or ComponentTestBaseWithoutClient as base classes for component unit tests
Provide file_names_mapping for backward compatibility in component tests
Create comprehensive unit tests for all new components

Files:

• src/backend/tests/unit/components/languagemodels/test_chatollama_component.py

{src/backend/**/*.py,tests/**/*.py,Makefile}

📄 CodeRabbit inference engine (.cursor/rules/backend_development.mdc)

{src/backend/**/*.py,tests/**/*.py,Makefile}: Run make format_backend to format Python code before linting or committing changes
Run make lint to perform linting checks on backend Python code

Files:

• src/backend/tests/unit/components/languagemodels/test_chatollama_component.py

src/backend/tests/unit/**/*.py

📄 CodeRabbit inference engine (.cursor/rules/backend_development.mdc)

Test component integration within flows using create_flow, build_flow, and get_build_events utilities

Files:

• src/backend/tests/unit/components/languagemodels/test_chatollama_component.py

src/backend/tests/**/*.py

📄 CodeRabbit inference engine (.cursor/rules/testing.mdc)

src/backend/tests/**/*.py: Unit tests for backend code must be located in the 'src/backend/tests/' directory, with component tests organized by component subdirectory under 'src/backend/tests/unit/components/'.
Test files should use the same filename as the component under test, with an appropriate test prefix or suffix (e.g., 'my_component.py' → 'test_my_component.py').
Use the 'client' fixture (an async httpx.AsyncClient) for API tests in backend Python tests, as defined in 'src/backend/tests/conftest.py'.
When writing component tests, inherit from the appropriate base class in 'src/backend/tests/base.py' (ComponentTestBase, ComponentTestBaseWithClient, or ComponentTestBaseWithoutClient) and provide the required fixtures: 'component_class', 'default_kwargs', and 'file_names_mapping'.
Each test in backend Python test files should have a clear docstring explaining its purpose, and complex setups or mocks should be well-commented.
Test both sync and async code paths in backend Python tests, using '@pytest.mark.asyncio' for async tests.
Mock external dependencies appropriately in backend Python tests to isolate unit tests from external services.
Test error handling and edge cases in backend Python tests, including using 'pytest.raises' and asserting error messages.
Validate input/output behavior and test component initialization and configuration in backend Python tests.
Use the 'no_blockbuster' pytest marker to skip the blockbuster plugin in tests when necessary.
Be aware of ContextVar propagation in async tests; test both direct event loop execution and 'asyncio.to_thread' scenarios to ensure proper context isolation.
Test error handling by mocking internal functions using monkeypatch in backend Python tests.
Test resource cleanup in backend Python tests by using fixtures that ensure proper initialization and cleanup of resources.
Test timeout and performance constraints in backend Python tests using 'asyncio.wait_for' and timing assertions.
Test Langflow's Messag...

Files:

• src/backend/tests/unit/components/languagemodels/test_chatollama_component.py

src/backend/**/*component*.py

📄 CodeRabbit inference engine (.cursor/rules/icons.mdc)

In your Python component class, set the icon attribute to a string matching the frontend icon mapping exactly (case-sensitive).

Files:

• src/backend/tests/unit/components/languagemodels/test_chatollama_component.py

src/backend/**/components/**/*.py

📄 CodeRabbit inference engine (.cursor/rules/icons.mdc)

In your Python component class, set the icon attribute to a string matching the frontend icon mapping exactly (case-sensitive).

Files:

• src/backend/tests/unit/components/languagemodels/test_chatollama_component.py

**/{test_*.py,*.test.ts,*.test.tsx}

📄 CodeRabbit inference engine (coderabbit-custom-pre-merge-checks-unique-id-file-non-traceable-F7F2B60C-1728-4C9A-8889-4F2235E186CA.txt)

**/{test_*.py,*.test.ts,*.test.tsx}: Check if tests have too many mock objects that obscure what’s actually being tested
Warn when mocks are used instead of testing real behavior and interactions
Suggest using real objects or simpler test doubles when mocks become excessive
Ensure mocks are used only for external dependencies, not core business logic
Recommend integration tests when unit tests become overly mocked
Check that test files follow the project’s naming conventions (backend: test_*.py; frontend: *.test.ts/tsx)
Verify that tests actually exercise the new or changed functionality, not placeholder assertions
Test files should have descriptive test function names explaining what is being tested
Organize tests logically with proper setup and teardown
Include edge cases and error conditions for comprehensive coverage
Verify tests cover both positive (success) and negative (failure) scenarios
Ensure tests are not mere smoke tests; they should validate behavior thoroughly
Ensure tests follow the project’s testing frameworks (pytest for backend, Playwright for frontend)

Files:

• src/backend/tests/unit/components/languagemodels/test_chatollama_component.py

**/test_*.py

📄 CodeRabbit inference engine (coderabbit-custom-pre-merge-checks-unique-id-file-non-traceable-F7F2B60C-1728-4C9A-8889-4F2235E186CA.txt)

**/test_*.py: Backend tests must be named test_*.py and use proper pytest structure (fixtures, assertions)
For async backend code, use proper pytest async patterns (e.g., pytest-asyncio)
For API endpoints, include tests for both success and error responses

Files:

• src/backend/tests/unit/components/languagemodels/test_chatollama_component.py

🧬 Code graph analysis (2)

src/backend/tests/unit/components/languagemodels/test_chatollama_component.py (2)

src/lfx/src/lfx/components/ollama/ollama.py (6)

• ChatOllamaComponent (28-376)
• headers (372-376)
• build_model (163-230)
• is_valid_ollama_url (232-249)
• get_models (299-369)
• update_build_config (251-297)

src/lfx/src/lfx/utils/util.py (1)

• transform_localhost_url (119-161)

src/lfx/src/lfx/components/ollama/ollama.py (1)

src/lfx/src/lfx/inputs/inputs.py (1)

• SecretStrInput (286-341)

🔇 Additional comments (15)

src/lfx/src/lfx/components/ollama/ollama.py (2)

41-66: API key input addition looks good

SecretStrInput is appropriate; naming and real_time_refresh align with the UI patterns. Icon string "Ollama" matches mapping.

---

214-216: Correctly plumbs headers into client via client_kwargs

This ensures ChatOllama receives Authorization when present without affecting local setups.

src/backend/tests/unit/components/languagemodels/test_chatollama_component.py (13)

406-408: Good: assert request URL via named kwarg

Switching to call_args[1]["url"] matches how httpx is called.

Also applies to: 435-437

---

462-495: Headers property tests — clear and correct

Validates None vs Authorization across cloud/local and api_key presence.

---

496-520: Cloud build_model passes headers via client_kwargs — OK

---

521-541: Cloud without API key — no client_kwargs — OK

---

542-560: Local build_model — no headers — OK

---

561-583: is_valid_ollama_url (cloud) includes headers — OK

---

584-603: is_valid_ollama_url (local) omits headers — OK

---

604-647: get_models (cloud) passes headers to GET and POST — OK

---

648-685: get_models (local) omits headers — OK

---

713-739: Local base_url clears/hides api_key — OK

---

741-766: Changing api_key triggers refresh — OK

---

767-774: Cloud URL isn’t transformed — OK

---

776-796: /v1 suffix stripped for cloud base_url — OK

[erichare]

Is this the right terminology for a local connection though?

[HzaRashid]

good question, I'm not sure. Just wanted to stay consistent with the other llm model provider components, e.g., anthropic.py has the following

...
display_name="Anthropic API URL",
...

But like you said Ollama is mainly used in a local environment at the moment. On the other hand this terminology helps to hint to the user that cloud Ollama is supported

[erichare]

Is it the case that headers will/ should never be provided with a local instance?

[HzaRashid]

sadly (or maybe not since local can be configured to require api keys?) the headers can be passed to a local instance if the api key is a non-empty string, but I have confirmed that it works just fine regardless.

[erichare]

This is also a fantastic PR. LGTM @HzaRashid . I'm approving, but i did make one NIT comment + one question

[HzaRashid]

This is also a fantastic PR. LGTM @HzaRashid . I'm approving, but i did make one NIT comment + one question

Thank you so much for reviewing it!