docs: connect to postgresql with SSL

[mendonk]

Preview
Clarify PostgreSQL connection values for connecting Langflow to a PostgreSQL database.

1. What parameters are supported?
2. How do I pass the cert files for my connection?
3. Difference between SSL certs env vars and Postgresql cert files?
4. Where can I get more information?

Summary by CodeRabbit

• Documentation
  • Added a detailed guide for configuring SSL with PostgreSQL in the external database setup, including SSL modes (require, verify-ca, verify-full), client certificate options, connection parameters for SQLAlchemy/psycopg, and a link to PostgreSQL SSL docs. Includes a warning not to reuse web server HTTPS variables for database certificates.
  • Clarified that LANGFLOW_SSL_CERT_FILE and LANGFLOW_SSL_KEY_FILE are for enabling HTTPS on the web server only and are separate from database SSL settings.

[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 documentation updates add PostgreSQL SSL configuration guidance to the external database setup page and clarify that SSL certificate/key environment variables apply to the web server (HTTPS) and are separate from database SSL settings.

Changes

Cohort / File(s)	Change summary
DB SSL Docs docs/docs/Develop/configuration-custom-database.mdx	Added instructions for configuring PostgreSQL SSL: sslmode options (require, verify-ca, verify-full), client certificates, SQLAlchemy/psycopg parameters, and a warning not to reuse Langflow HTTPS cert env vars for database SSL. Linked to PostgreSQL SSL docs.
Env Vars Docs docs/docs/Develop/environment-variables.mdx	Clarified LANGFLOW_SSL_CERT_FILE and LANGFLOW_SSL_KEY_FILE describe HTTPS for the Langflow web server and are distinct from database SSL connections.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• docs: refresh external postgresql database page #9174 — Also updates PostgreSQL configuration/docs around SSL and connection guidance; overlaps in subject matter and page focus.

Suggested labels

documentation

Suggested reviewers

• aimurphy

Pre-merge checks and finishing touches

❌ Failed checks (2 inconclusive)

Check name	Status	Explanation	Resolution
Test Quality And Coverage	❓ Inconclusive	The PR only changes documentation files (docs/docs/Develop/configuration-custom-database.mdx and docs/docs/Develop/environment-variables.mdx) and introduces no new code, endpoints, or async logic; therefore, there are no new implementations requiring tests. Since the custom check assesses test quality and coverage for new implementations, it is not applicable here. No new or modified tests are expected, and verifying async patterns, API success/error cases, or adherence to testing frameworks is moot for this PR.	As this PR is documentation-only, there is nothing to validate against the test quality and coverage criteria. If any code changes are added later (e.g., new DB connection logic or configuration handling), please include corresponding tests following the project’s standards (pytest for backend, Playwright for frontend), covering main functionality, edge/error paths, and proper async handling where applicable.
Test File Naming And Structure	❓ Inconclusive	I scanned the repository on the PR branch for test files and structures. Backend: Python tests are present and use pytest conventions (files named test_.py with def test_ functions and pytest usage), including some fixtures and pytest.raises covering negative paths. Frontend: there are Playwright-based tests using *.test.ts/tsx that import from @playwright/test, with expect usage and basic setup via test hooks. Integration/e2e: there are Playwright e2e-style tests and a Python tests/integration directory with pytest markers in some files; however, not all integration tests are clearly marked or isolated consistently. Test naming is generally descriptive, but a subset of tests have brief names, and edge/error cases are not consistently covered in frontend tests. Overall, most criteria are met, but integration labeling and completeness of negative/edge scenarios in frontend could be improved.	Please confirm where integration tests are expected to live and how they should be marked (e.g., pytest -m integration and a specific directory like tests/integration, and for Playwright an e2e/ folder). If that convention exists, align existing tests to it and add markers where missing; if not, document it and reorganize accordingly. For completeness, add a few negative/error-path tests to the frontend suite (e.g., failing auth, invalid inputs) and ensure test titles describe the behavior under test. If you share the intended conventions, I can re-run checks and provide a definitive pass/fail.

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The title succinctly indicates that this pull request updates the documentation to cover connecting to PostgreSQL with SSL, which aligns directly with the primary changeset focused on SSL configuration for external database connections. It is clear, concise, and free of unnecessary detail, making it easy for reviewers to understand the main purpose at a glance.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.
Test Coverage For New Implementations	✅ Passed	I inspected the PR’s changed files via the repository and confirmed it only updates documentation (docs/docs/Develop/configuration-custom-database.mdx and docs/docs/Develop/environment-variables.mdx) with no source code changes. Since there are no new components, features, or bug fixes implemented in code, no corresponding unit or integration tests are required. Accordingly, there are no new or updated test files in this PR, which is appropriate for a docs-only change.
Excessive Mock Usage Warning	✅ Passed	I scanned the repository’s test files for mocking patterns across Python and JavaScript/TypeScript (e.g., unittest.mock.patch, MagicMock/AsyncMock/Mock, pytest monkeypatch, jest.mock/vi.mock/sinon). The docs-only PR does not change tests, but current test coverage shows limited and targeted mocking, primarily around external I/O and service boundaries, with no clusters of files exhibiting high mock density or pervasive patching of core domain logic. I did not find files with excessive mocks that obscure behavior, nor evidence that mocks replace meaningful integration paths; I also observed presence of tests without mocks, suggesting a reasonable balance. Given this, the mock usage appears appropriate and not excessive relative to the codebase.
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: 2

📜 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 bf387bf and 7bdcc3e.

📒 Files selected for processing (2)

• docs/docs/Develop/configuration-custom-database.mdx (1 hunks)
• docs/docs/Develop/environment-variables.mdx (1 hunks)

🧰 Additional context used

📓 Path-based instructions (2)

docs/**/*.{md,mdx}

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

docs/**/*.{md,mdx}: All Markdown/MDX pages must start with front matter including at least title and description; include sidebar_position for docs pages when applicable
Code blocks must specify a language and may include a title (```lang title="…")
Use sentence case for headings and keep paragraphs short and scannable
Write in second person, present tense, with a professional but approachable tone
Use inline code with backticks for code terms; use bold for UI elements and italics for emphasis; keep lists in parallel structure
Ensure internal links are functional and navigation works (update cross-references as needed)
Verify all code examples in docs and blog actually run as shown
Use correct terminology capitalization: Langflow, Component, Flow, API, JSON
Reference images with absolute paths under /img/... and provide descriptive alt text

Files:

• docs/docs/Develop/configuration-custom-database.mdx
• docs/docs/Develop/environment-variables.mdx

docs/docs/**/*.{md,mdx}

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

Use Docusaurus admonitions (:::+tip|warning|danger) instead of custom callouts in docs pages

Files:

• docs/docs/Develop/configuration-custom-database.mdx
• docs/docs/Develop/environment-variables.mdx

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: Test Docs Build / Test Docs Build
• GitHub Check: build-and-deploy

[aimurphy]

approved but please see my suggestion

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

Build successful! ✅
Deploying docs draft.
Deploy successful! View draft