Skip to main content
Enable data apps on your self-hosted Lightdash instance by configuring a sandbox provider, a coding-agent provider, and object storage. For creating apps, sharing them, and permissions, see Data apps. Sandbox providers are configured separately and cover several runtimes — E2B, AWS Lambda MicroVMs, Azure Container Apps, and Google Cloud Run. See sandboxes for the full provider setup; this page covers everything else data apps need. For custom chart types, see Chart Studio to configure authoring or Chart library to install published chart types without a sandbox.

Prerequisites

  • Enterprise license - LIGHTDASH_LICENSE_KEY must be set on your instance.
  • S3-compatible storage - a bucket Lightdash can write to for app source and built artifacts. If your instance isn’t already using S3, set that up first.
  • A configured sandbox provider - see sandboxes.
  • A coding-agent provider - Anthropic, OpenAI, or an AWS Bedrock account with access to the model used by your selected agent. It serves every user’s builds, so it can’t be tied to one person’s subscription — see building with your own subscription.
  • A headless browser (optional) - needed for the app image in Slack build notifications and link previews. See enabling the headless browser.

Configuration

Enable the runtime in your deployment:
Data apps use your instance’s S3 configuration. Set APPS_S3_BUCKET if you want a dedicated bucket for app source and built artifacts. See the data apps runtime variables for storage overrides and the full configuration reference. Choose one of the coding-agent and provider combinations below.

Claude through Anthropic (default)

Configure Claude with an Anthropic API key:
This uses Anthropic directly when AI_DEFAULT_PROVIDER is not bedrock. For gateway routing, set ANTHROPIC_BASE_URL to the base before /v1. With ANTHROPIC_BASE_URL, Lightdash uses ANTHROPIC_API_KEY as a bearer token and allows the gateway hostname through the sandbox firewall. The gateway must implement Anthropic Messages. See Corporate LLM gateways for authentication and API-path requirements, including separate gateway routes for Data apps.

Codex through OpenAI

Configure Codex with an OpenAI API key:
Codex uses OpenAI directly when AI_DEFAULT_PROVIDER is not bedrock; app generation does not require an Anthropic key in this mode. For gateway routing, set OPENAI_BASE_URL to a gateway that supports the Responses API and the configured Codex model IDs.

Claude or Codex through Bedrock

Set AI_DEFAULT_PROVIDER=bedrock and choose APPS_CODING_AGENT=claude or APPS_CODING_AGENT=codex. Configure the region, credentials, and model access for that agent using the AWS Bedrock variables. The sandbox firewall allows the provider endpoints required for the selected agent and region. When BEDROCK_BASE_URL is set, the gateway must support the protocol used by each selected consumer. Claude uses Bedrock’s streaming Invoke API, while Codex uses the OpenAI Responses API through a custom gateway provider. Codex requires BEDROCK_API_KEY in gateway mode and sends model IDs with the openai. prefix; the gateway must register or translate those names. See the required gateway APIs matrix. AI_DEFAULT_PROVIDER is an instance-wide setting. Setting it to bedrock also routes AI agents through Bedrock. APPS_CODING_AGENT changes only the coding agent used by data apps and Chart Studio.

Building with your own subscription

The coding-agent credential you configure here builds apps for every user on the instance, so it has to be a credential that can serve all of them: a direct ANTHROPIC_API_KEY or OPENAI_API_KEY, an Anthropic- or OpenAI-compatible gateway, or Bedrock credentials. A credential tied to one person’s individual subscription, such as a Claude Code CLAUDE_CODE_OAUTH_TOKEN, isn’t supported here. To build with your own AI coding agent and your own subscription instead, use local data app development: you edit the app with your own agent and credentials, and the server only runs a deterministic Vite build (no AI) when you upload.

Gateway networking

The Lightdash backend and the Data app sandbox make separate connections to the gateway. E2B and Azure Sandboxes receive the configured gateway hostname in their dynamic egress allowlist. AWS Lambda MicroVMs use a pre-provisioned egress connector instead, so LAMBDA_MICROVM_EGRESS_CONNECTOR_ARN must permit the gateway hostname. Docker and Cloud Run follow their existing runtime network policy. See LLM gateway egress. Restart the backend after configuring the runtime and provider. Follow Creating a new app to verify generation.

Private-network external connections

External connections block private and internal network addresses by default. To let a data app call a trusted internal HTTPS API, set APP_RUNTIME_EXTERNAL_CONNECTION_ALLOWED_PRIVATE_HOST_CIDRS in the Lightdash backend’s deployment environment:
This example allows private addresses in 10.20.0.0/16 for api.internal.example and only 10.30.1.5 for auth.internal.example. Use the hostnames and narrowest address ranges needed by your services. Restart the backend after changing the variable; malformed entries cause a configuration error at startup.
  • Each entry pairs an exact hostname with an IPv4 or IPv6 CIDR. Do not include a URL scheme, port, path, or wildcard. Hostnames are case-insensitive and a trailing DNS dot is ignored.
  • Repeat a hostname to approve multiple ranges, for example api.internal.example@10.20.0.0/16,api.internal.example@fd12:3456::/48.
  • A private destination must match both the hostname and one of its CIDRs. Lightdash checks every DNS answer and rejects the request if any private address is outside the approved ranges. Public addresses keep their existing behavior.
  • For OAuth 2.0 client credentials, approve the token endpoint’s hostname and private address range separately if it differs from the API host.
  • The backend must already have network access and DNS resolution for both services. HTTPS remains required, including a valid certificate trusted by the backend. This setting does not create network routes or disable certificate verification.
After restarting, create the connection under Project Settings → Data app connections with the API’s HTTPS base URL, authentication, and allowed methods and paths. Use the wizard’s test request to verify it before linking an app. See testing a connection.
This is an instance-wide trust policy for external connections across all projects. A hostname entry covers every HTTPS port, and explicitly approved ranges can include sensitive internal services, loopback, or cloud metadata addresses. Only approve destinations you trust with data from linked apps, and keep connection methods and paths appropriately restricted.
Leaving the variable unset or empty preserves the existing private-network block. The exception applies only to requests through external connections, including connection tests and OAuth client-credentials token requests. Connection permissions, credential handling, DNS pinning, redirect blocking, request limits, and rate limits remain in place. Direct browser image loading, sandbox networking, and other backend requests are unaffected. If a test returns blocked_ip, check the exact hostname and every address it resolves to from the backend against the configured CIDRs. For Failed to obtain OAuth access token, also check the token endpoint’s entry, network access, certificate, and client credentials.

Chart Studio

Chart Studio builds custom chart types on the same runtime, with its own switch. It turns on for every organization once the instance has an Enterprise license and a configured sandbox provider. It doesn’t need APPS_RUNTIME_ENABLED, so you can offer Chart Studio while leaving data apps off. Builds use the same coding-agent provider and bucket as data apps.

Chart library

Enable the chart library on your self-hosted Lightdash instance, or configure a private mirror for a restricted network. For browsing, installing, and using chart types, see Chart library. Lightdash reads the library from a static website. The public library lives at https://lightdash.github.io/lightdash-library. Instances that cannot reach it can read a mirror of the same files from inside their own network instead.

Chart library prerequisites

  • Enterprise license - LIGHTDASH_LICENSE_KEY must be set on your instance.
  • Outbound access to the library - the backend fetches the library over https. The browser never talks to the library directly; images and other assets are proxied through the backend.
The library does not need data apps or Chart Studio configured. To also let people edit chart types, configure the Chart Studio runtime.

Enable the chart library

Add the flag to your deployment and restart the backend:
If LIGHTDASH_ENABLE_FEATURE_FLAGS already contains flags, append chart-type-registry to the comma-separated list. See feature flags. Open the chart library to verify that the backend can fetch the index. If the library cannot be reached, the tab is hidden and already-installed chart types keep working.

Chart library configuration

Mirror the chart library

A deployment with no route to the public internet can serve the library from inside its network. The library is a static tree of files, so any artifact proxy or object store that can mirror a website works, for example a remote repository in your artifact manager that caches https://lightdash.github.io/lightdash-library, or a bucket you sync the tree into. Mirror the tree as published. Lightdash reads index.json at the base URL and the chart files beneath it (charts/<slug>/<version>/...), and it verifies every downloaded artifact against the checksums in the index, so a mirror cannot alter chart code without the install failing. Then point the instance at the mirror:
  • LIGHTDASH_CHART_REGISTRY_ALLOW_PRIVATE_HOSTS is needed whenever the mirror’s hostname resolves to a private address. It lifts only that check. The mirror must still be served over https with a certificate the backend trusts, redirects are refused, and the connection stays pinned to the resolved address. Do not use LIGHTDASH_CHART_REGISTRY_ALLOW_INSECURE for a mirror.
  • LIGHTDASH_CHART_REGISTRY_AUTHORIZATION_HEADER holds the complete header value. Treat it as a secret: deliver it from your secret store rather than writing it into plain configuration. On Kubernetes, add the key to the Secret your deployment already injects, or use an extraEnv entry with a secretKeyRef.
  • If the mirror uses a certificate from an internal certificate authority, give the backend the CA bundle with NODE_EXTRA_CA_CERTS. Lightdash does not offer a way to skip certificate validation for the library.
  • Artifact proxies often rewrite the content type of binary files to application/octet-stream. Lightdash detects PNG, JPEG, WebP and GIF screenshots from their contents, so the library still renders previews behind such a proxy.
Restart the backend after changing any of these variables.

Turn off the chart library

Set LIGHTDASH_CHART_REGISTRY_URL to an empty string. The Chart library tab disappears and no library requests are made. Chart types already installed keep working, and Chart Studio is unaffected.

Troubleshoot the chart library

The Chart library tab doesn’t appear. Check that LIGHTDASH_LICENSE_KEY is set, chart-type-registry is in LIGHTDASH_ENABLE_FEATURE_FLAGS, and the signed-in user can install chart types in the project. If all of that is in place, the backend could not fetch the library index: check the backend logs for the request to LIGHTDASH_CHART_REGISTRY_URL. The logs say the library host resolves to a private address. The mirror is on an internal address and LIGHTDASH_CHART_REGISTRY_ALLOW_PRIVATE_HOSTS is not set. The logs show a certificate error against the mirror. The backend does not trust the mirror’s certificate. Add the issuing CA bundle with NODE_EXTRA_CA_CERTS. Installs fail with a checksum mismatch. The mirror served a file that differs from the published one. Check that the mirror serves the tree unchanged and is not injecting or rewriting content.

Provider usage

Your sandbox and model providers bill your accounts directly. Monitor usage and configure limits with those providers before rolling out data apps.

Troubleshooting

The “Data apps” entry doesn’t appear in the New menu. Check that APPS_RUNTIME_ENABLED=true, LIGHTDASH_LICENSE_KEY is set, and the signed-in user has the create:DataApp scope. Chart Studio doesn’t appear in the Browse menu. Check that LIGHTDASH_LICENSE_KEY is set and your sandbox provider has all its required variables, for example E2B_API_KEY with E2B. APPS_RUNTIME_ENABLED isn’t needed. Builds fail immediately with a sandbox creation error. Check your sandbox provider’s credentials and template configuration — see sandboxes. Builds fail mid-generation with an Anthropic error. For direct Anthropic, check account usage limits and confirm ANTHROPIC_API_KEY is valid. With ANTHROPIC_BASE_URL, confirm the sandbox can reach the gateway and that it accepts bearer authentication at /v1/messages. Codex builds fail with an OpenAI authentication or model error. Confirm APPS_CODING_AGENT=codex. For OpenAI, verify OPENAI_API_KEY; if OPENAI_BASE_URL is set, the gateway must support the Responses API and the model IDs shown in the Data app model picker. For a Bedrock gateway, verify BEDROCK_API_KEY, /responses support, and the openai.-prefixed model ID. App queries fail with a warehouse network-policy or IP allowlist error. A data app’s queries run through the Lightdash backend like any chart query, not from the sandbox or the viewer’s browser. The blocked IP is the outbound address of your Lightdash backend, or of your warehouse worker pods if you run them. Allowlist that address, or the NAT gateway the traffic leaves through, in the warehouse’s network policy. Builds fail mid-generation with a Bedrock error. Confirm BEDROCK_REGION is set to a region where the selected agent’s model is available, and that either BEDROCK_API_KEY or the BEDROCK_ACCESS_KEY_ID / BEDROCK_SECRET_ACCESS_KEY pair is valid. If you use IAM credentials, the principal must have permission to invoke the selected model. With BEDROCK_BASE_URL, confirm the gateway supports the selected agent’s API and is allowed by the sandbox network policy. Codex requires an exact OpenAI Bedrock model ID with the openai. prefix.