34282926a1
## 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>
3.8 KiB
products, sidebar_label
| products | sidebar_label |
|---|---|
| enterprise-flex | Get started |
import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem';
Get started with Enterprise Flex
Any Airbyte Cloud environment can upgrade to Enterprise Flex. To learn more about upgrading, talk to sales.
You'll likely use a combination of managed and self-managed data planes. Since Airbyte sets up managed data planes for you, they're preferable when they're an option. Limit the use of self-managed data planes only to those connections that require your self-managed infrastructure.
Determine which regions you need
Think about the data you need to sync and your data sovereignty and compliance requirements. Generally, these are things you want to consider:
- What data you want to sync, where it's stored today, and where you want it to be stored after syncing.
- Your national, sub-national, industry, and organization compliance and privacy requirements.
- Your data sovereignty needs.
- Your organization's security posture and data handling policies.
Based on this assessment, you should collect a list of how many, and which, regions you need.
Create a workspace for each region
Each workspace uses a single region, so create one workspace for each region. A good starting pattern is to create one managed workspace for non-sensitive data without compliance and sovereignty requirements, and an additional workspace for each region your connections need to run in. For example, create one Workspace to handle U.S. data, one Workspace to handle Australian data, etc.
Managed data planes
Managed data planes need no additional infrastructure. Begin adding sources, destinations, and connections in your workspace at your convenience.
Self-managed data planes
The following diagram illustrates a typical Enterprise Flex deployment running a self-managed data plane.
You can deploy a self-managed data plane in Airbyte two ways.
-
Deploy with Helm: A more traditional Kubernetes deployment using the Helm package manager. This method deploys your data plane to a Kubernetes cluster like an Amazon EKS cluster. It's the right choice for teams that have in-house Kubernetes expertise. Deploy with Helm >
-
Deploy with Airbox: Airbox is Airbyte's utility for simplified, single-node data plane deployments, like on a virtual machine. This utility abstracts away most of the nuance of a Kubernetes deployment. It's the right choice for teams with limited Kubernetes expertise. Deploy with Airbox >
Limitations and considerations
-
While data planes process data in their respective regions, some metadata remains in the control plane.
- Airbyte stores Cursor and Primary Key data in the control plane regardless of data plane location. If you have data that you can't store in the control plane, don't use it as a cursor or primary key.
-
The Connector Builder processes all data through the control plane, regardless of workspace settings. This limitation applies to the development and testing phase only; published connectors respect workspace data residency settings during syncs.
-
If you want to run multiple data planes in the same region for higher availability, both must be part of the same region in Airbyte and use the same secrets manager to ensure connection credentials are the same.
-
Data planes and the control plane must be configured to use the same secrets manager.
- This ensures that when you enter credentials in the UI, they are written to the secrets manager and available to the data plane when running syncs.
-
Data planes must be able to communicate with the control plane.
-
Data planes only send requests to the control plane and never require inbound requests.