Installing the Grafbase Enterprise Platform

The Grafbase Enterprise Platform is distributed as a Helm chart that can be installed on any Kubernetes cluster. Please contact sales to get the needed credentials to access the charts and container images.

Before you start the installation, make sure you have the following prerequisites:

  • A Kubernetes cluster with at least 4 CPU and 8 GB of memory.
  • Helm 3 installed on your local machine.
  • Helmfile installed on your local machine.
  • Kubernetes CLI installed on your local machine.

The Grafbase Helm chart is hosted on our private repository. To install the Grafbase Enterprise Platform, you need to add the repository to your Helm configuration:

helm registry login helm.grafbase.com --username <username> --password-stdin

The next step is to create a Kubernetes namespace for the Enterprise Platform. When done, you can start defining the helmfile configuration:

releases: - name: enterprise-platform chart: oci://helm.grafbase.com/enterprise-platform/stable/enterprise-platform version: <version> namespace: default createNamespace: true values: - ./values.yaml.gotmpl secrets: - ./secrets.yaml

The values.yaml.gotmpl and secrets.yaml files should be created in the same directory as the helmfile configuration. The values.yaml.gotmpl file should contain the configuration for the Grafbase Enterprise Platform, and the secrets.yaml file should contain the secrets for the platform.

The first thing is to define the services that you want to install to the Grafbase Enterprise Platform cluster. To start, you can enable all services to play with the cluster:

global: zitadel: enabled: true postgres: enabled: true clickhouse: enabled: true minio: enabled: true kafka: enabled: true telemetrySink: enabled: true otelCollector: enabled: true dashboard: enabled: true

In a production environment, you might want to disable some services that you don't need. In general it is advised to have at least the following services enabled:

Additionally, you might want to enable the following services:

By default, the Grafbase CLI uses the Grafbase Cloud Platform. To use the Grafbase Enterprise Platform, you need to configure the CLI to use your platform. You can do this by defining the URL to your local installation in the CLI login command:

grafbase login --url https://<your-enterprise-platform-url>

After logging in, you can use the CLI to interact with your Grafbase Enterprise Platform installation.

The Grafbase Gateway uses the Enterprise Platform to store telemetry data for the analytics and tracing dashboards.

Additionally, the Enterprise Platform is responsible for composing subgraph schemas. The latest federated graph schema (supergraph schema) for a graph can be fetched using the Grafbase CLI:

Assuming you have logged in interactively with grafbase login using the --url argument to point to your own instance of the enterprise platform, you can run:

grafbase schema account-name/graph-name@branch-name

In a non-interactive environment (like CI), you can use the GRAFBASE_API_URL and GRAFBASE_ACCESS_TOKEN environment variables:

GRAFBASE_ACCESS_TOKEN="..." GRAFBASE_API_URL=https://api.grafbase.com/graphql grafbase schema account-name/graph-name@branch-name

Replace api.grafbase.com with the address of your instance of the enterprise platform, as well as the account and graph name in the example above. The branch name is optional, and will default to the production branch of the graph. The token in GRAFBASE_ACCESS_TOKEN must be authorized for the specific graph or have full access to the organization.

You can then start the Gateway with the downloaded schema:

grafbase schema account-name/graph-name@branch-name > schema.graphql GRAFBASE_OTEL_URL=https://custom-telemetry-sink-deployment.dev grafbase-gateway --schema ./schema.graphql --config grafbase.toml

Note that you must change the telemetry sink URL by setting the GRAFBASE_OTEL_URL environment variable in the Grafbase Gateway deployment to the URL of the Telemetry Sink chart.

The Gateway watches the schema file for changes, so if you update it in your filesystem, or for example as part of a Kubernetes ConfigMap, the gateway will automatically pick up the new schema and serve new requests with it, without restarting or losing state.