## What Generates version 2.0 of the Airbyte platform documentation using Docusaurus's built-in versioning system. This creates a frozen snapshot of the current documentation that users can reference. Requested by ian.alton@airbyte.io via [Slack thread](https://airbytehq-team.slack.com/archives/D08FX8EC9L0/p1760490197805979?thread_ts=1760490197.805979). Link to Devin run: https://app.devin.ai/sessions/689693593bac44f4903f476aa17b872e ## How - Ran `pnpm run docusaurus docs:version:platform 2.0` in the docusaurus directory - This automatically: - Created `platform_versioned_docs/version-2.0/` containing a snapshot of all current platform docs - Created `platform_versioned_sidebars/version-2.0-sidebars.json` with the sidebar navigation structure - Updated `platform_versions.json` to add "2.0" to the version list - Ran prettier to format the JSON files - Verified the documentation builds successfully locally (build completed in ~3 minutes with only pre-existing broken anchor warnings) ## Review guide 1. **Verify timing**: Confirm this is the correct time to release version 2.0 of the documentation 2. **Version order**: Check `docusaurus/platform_versions.json` - verify "2.0" is first in the array (newest version first) 3. **Build verification**: Ensure CI/Vercel builds pass without errors 4. **Spot check**: Optionally review 2-3 files in `docusaurus/platform_versioned_docs/version-2.0/` to ensure content looks reasonable Note: This is a standard Docusaurus versioning operation that creates a frozen snapshot of the current "next" documentation. The generated files are extensive (500+ files) but follow Docusaurus conventions. ## User Impact Users will see version 2.0 available in the version dropdown on docs.airbyte.com. This provides a stable reference point for platform documentation at this point in time. Existing versions (1.6, 1.7, 1.8) remain unchanged. ## Can this PR be safely reverted and rolled back? - [x] YES 💚 This is an additive change that doesn't modify existing versioned docs. Reverting would simply remove version 2.0 from the version list and delete the associated documentation files. Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Co-authored-by: ian.alton@airbyte.io <ian.alton@airbyte.io>
2.4 KiB
products
| products |
|---|
| oss-community, oss-enterprise |
import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem';
External Database
For production deployments, we recommend using a dedicated database instance for better reliability, and backups (such as AWS RDS or GCP Cloud SQL) instead of the default internal Postgres database (airbyte/db) that Airbyte spins up within the Kubernetes cluster.
The following instructions assume that you've already configured a Postgres instance:
Secrets
apiVersion: v1
kind: Secret
metadata:
name: airbyte-config-secrets
type: Opaque
stringData:
# Database Secrets
database-user: ## e.g. airbyte
database-password: ## e.g. password
Values
Add external database details to your values.yaml file. This disables the default internal Postgres database (airbyte/db), and configures your external Postgres database. You can override all of the values below by setting them in the airbyte-config-secrets or set them directly in the values.yaml file. The database password is a special case in that it must be set in the airbyte-config-secrets.
postgresql:
enabled: false
global:
database:
type: external
# -- Secret name where database credentials are stored
secretName: "" # e.g. "airbyte-config-secrets"
# -- The database host
host: ""
# -- The database port
port: ""
# -- The database name
database: ""
# -- The key within `secretName` where database user is stored
userSecretKey: "" # e.g. "database-user"
# -- The key within `secretName` where password is stored
passwordSecretKey: "" # e.g."database-password"
postgresql:
enabled: false
global:
database:
type: external
# -- Secret name where database credentials are stored
secretName: "" # e.g. "airbyte-config-secrets"
# -- The database host
host: ""
# -- The database port
port: ""
# -- The database name
name: ""
# -- The key within `secretName` where database user is stored
userSecretKey: "" # e.g. "database-user"
# -- The key within `secretName` where password is stored
passwordSecretKey: "" # e.g."database-password"