Skip to main content
Environments are an enterprise feature that lets you run the same pipeline definition in development, staging, production, or custom stages—without forking graphs. Each environment supplies its own configuration layer, especially variables and connection targets.
Environment limits, naming, and approval rules are configured by your Planasonix administrator. If you do not see environment selectors in run or schedule dialogs, your organization may be on an edition that uses projects alone for separation.

​
Why environments matter

  • Safety: Developers default to dev resources; production credentials stay scoped to production runs.
  • Consistency: One graph, one review story—changes propagate predictably when you promote.
  • Compliance: Separation of duties rules map cleanly to who can deploy to which stage.
Exact environment names, limits per organization, and approval rules are set by your Planasonix administrator.

​
Environment configuration

Each environment stores:
  • Variable overrides for paths, endpoints, database names, batch sizes, and feature flags.
  • Connection bindings where the same logical role (“analytics warehouse”) maps to different physical endpoints per stage.
  • Runtime policies such as max rows, allowed destinations, or notification channels (when enabled).
When you run or schedule a pipeline, you select the target environment (or inherit a default from the project). Planasonix resolves configuration using that environment’s layer.
Use permissive sampling, smaller warehouses, and synthetic data where possible. Turn on verbose logging for authors without impacting production SLAs.

​
Variable overrides per environment

Follow a predictable naming scheme for variables (s3_bucket, db_schema, api_base_url). Then:
  1. Set pipeline defaults to development-friendly values.
  2. Add staging and production overrides that point to the right infrastructure.
  3. Document any variable that must be set before first production run.
Prefer credential references or managed secrets over plain-text variables in production. Overrides should reference which secret to use, not embed passwords in the UI.
When only some nodes change, you still promote the whole graph definition; environment overrides ensure each stage talks to the correct systems. Avoid maintaining three separate pipelines unless compliance explicitly requires it.

​
Deployment workflows

1

Author in development

Edit the pipeline, preview data, and run against dev connections.
2

Validate in staging

Execute a full or sampled run with production-like schemas. Capture validation metrics (row counts, key uniqueness, hash totals).
3

Request approval (if required)

Use your change-management process; attach run IDs and diff links when Git integration is on.
4

Deploy to production

Enable schedules, triggers, or downstream orchestration in the production environment. Monitor the first cycles closely.

Variables

Centralize values that differ by stage.

Git integration

Tie releases to tagged commits.