Environment variables
Environment variables used in an e6data In-VPC deployment and by client connectors.
Environment variables appear in two places: the In-VPC deployment commands, and client-side connector configuration.
Deployment variables (In-VPC)
The In-VPC deployment commands reference these from your environment as you work through the build. The common ones:
WORKSPACE_NAME
The workspace name (also the Kubernetes namespace)
TENANT_NAME
Your tenant identifier (from onboarding)
CLUSTER_NAME
Your Kubernetes cluster name
REGION / LOCATION
Cloud region
RESOURCE_GROUP
(Azure) Resource group
SUBSCRIPTION_ID
(Azure) Azure subscription ID
AWS_ACCOUNT_ID
(AWS) Your AWS account ID
AZURE_STORAGE_ACCOUNT_NAME / STORAGE_ACCOUNT
(Azure) ADLS Gen2 account for metadata
AGENT_API_BASE_URL
Control plane URL the console polls (from onboarding)
AUTHZ_SUPER_ADMINS
Comma-separated super-admin emails for the console
JWT_ISSUER / JWT_JWKS_URI / JWT_AUDIENCE
Auth configuration for the QueryRouter (from onboarding)
GREPTIME_ENDPOINT / GREPTIME_DATABASE / GREPTIME_USERNAME / GREPTIME_PASSWORD
Monitoring credentials (if enabled)
Client connector variables
When connecting from scripts, CI, or applications, keep credentials out of source by reading them from the environment. Common conventions used in the examples:
E6DATA_TOKEN
A personal access token for REST/driver scripts
E6DATA_API_KEY / E6DATA_SERVICE_ACCOUNT_KEY
A service account key for CI/automation
E6DATA_HOST
The workspace endpoint host
E6DATA_USERNAME
Your e6data email
E6DATA_DATABASE, E6DATA_CATALOG, E6DATA_CLUSTER
Target database, catalog, and cluster
These names are conventions in the example code, not fixed by the platform - use whatever your tooling expects, but never hardcode token values. See Token security best practices.
See also
Last updated
Was this helpful?