--- title: "Coming from the Web UI" slug: "dev-dataengine-reference-coming-from-the-ui" description: "Transition from VAST DataEngine UI to a code-first workflow with YAML keys, triggers, and pipelines. Learn to manage your pipelines effectively." tags: ["DataEngine"] updated: 2026-10-28T02:14:59Z published: 2026-10-28T02:14:59Z canonical: "docs.vastdata.com/dev-dataengine-reference-coming-from-the-ui" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.vastdata.com/llms.txt > Use this file to discover all available pages before exploring further. # Coming from the Web UI *Applies to VAST Cluster 5.5.* If your team started with VAST DataEngine in the VAST Web UI, with its forms and the Visual Builder, this page maps what you know to the code-first workflow. For every UI form it gives the `vastde` flag and the YAML key that set the same thing. It then covers the names that differ, how to move a pipeline you built in the UI into Git, and why one pipeline should have one place where it's edited. The UI and the CLI write the same objects through the same API. Nothing you built in the UI has to be rebuilt; it has to be exported once and then edited only from its files. ## Where the UI fits in a code-first workflow | Task | Code-first | Web UI | | --- | --- | --- | | Create and change triggers, functions and pipelines | YAML files in Git, applied with `vastde` | Read-only for anything managed from Git | | Deploy | `vastde pipelines deploy` | | | Watch runs: dashboard, logs, traces, revisions | `vastde logs`, `vastde traces`, `vastde metrics` | Useful, especially the trace tree and span logs. See [observability](/develop/docs/dev-dataengine-guides-observability). | | Registries, compute clusters, DataEngine setup | | Platform team. See [setup prerequisites](/develop/docs/dev-dataengine-operations-setup-prerequisites). | ## Triggers Create Trigger form. Flags are for `vastde triggers create element` or `triggers create schedule`; keys are for the [trigger file](/develop/docs/dev-dataengine-reference-function-and-trigger-files#element-trigger-file). | UI field | CLI flag | YAML key | | --- | --- | --- | | Trigger Name | `--name` | `name` | | Trigger Type: Element / Schedule | the subcommand: `create element` / `create schedule` | (the file's command) | | Description | `--description` | `description` | | Source Type: S3 / NFS | `--source-types S3` / `NFS4` | `source_types: [S3]` / `[NFS4]` | | Source View | `--source-bucket` (the view's bucket name) | `config.source_bucket_name` | | Event Type | `--event` (repeatable) | `config.events` | | Target Event Broker View (element), Target Kafka View (schedule) | `--broker-name`, with `--broker-type Internal` | `broker.name`, `broker.type: Internal` | | Topic | `--topic-name` | `topic_name` | | Element Name Filters: prefix, suffix | `--name-prefix`, `--name-suffix` | `config.name_filters.prefixes`, `.suffixes` | | (no UI field) | `--tag-prefix`, `--tag-suffix` | `config.tag_filters.prefixes`, `.suffixes` | | Schedule: Simple / Advanced (Quartz) | `--cron-schedule` | `config.cron_schedule` (5-field cron or Quartz) | | Custom Extensions | `--custom-extension key=value` (repeatable) | `custom_extensions` | | Tags | `--tags` | `tags` | In 5.5, removing a tag in the UI's Update Trigger dialog doesn't take effect. Use `vastde triggers update <name> --tags …`. ## Functions Create Function and Edit Function forms. Flags are for `vastde functions create` and `functions update`; keys are for the [function file](/develop/docs/dev-dataengine-reference-function-and-trigger-files#function-file). | UI field | CLI flag | YAML key | | --- | --- | --- | | Function Name | `--name` | `name` | | Description | `--description` | `description` | | Revision Alias | `--revision-alias` | `revision_alias` | | Revision No. (display only) | | (assigned by the server; `functions get -r` lists them) | | Revision Description | `--revision-description` | `revision_description` | | Container Registry | `--container-registry` (name or VRN) | `container_registry_vrn` | | Artifact Source | `--artifact-source` | `artifact_source` | | Image Tag | `--image-tag` | `image_tag` | | Full image path (display only) | | (registry + artifact source + image tag) | | Make local revision (Edit only) | No equivalent confirmed. Probably the inverse of `--publish`. | Probably `is_published: false` | | (no UI field) | `--architecture`, `--publish`, `--default-revision-number` | `architecture`, `is_published`, `default_revision_number` | Saving the Edit Function form creates a new revision. So does `functions update` when the image, registry, architecture, publish state, tags or alias change. See [revisions](/develop/docs/dev-dataengine-reference-function-and-trigger-files#revisions). ## Pipelines Create Pipeline form. Keys are for the [pipeline file](/develop/docs/dev-dataengine-reference-pipeline-yaml). | UI field | CLI flag | YAML key | | --- | --- | --- | | Pipeline Name | `--name` (create only) | `name`. Can't be changed later. | | Description | `--description` (create only) | `description` | | Kubernetes Cluster | (in the file) | `kubernetes_cluster_vrn: vast:dataengine:kubernetes-clusters:<name>`. Can't be changed later. | | Namespace | (in the file) | `namespace`: your tenant's DataEngine namespace on that cluster, `dataengine-ns-<tenant GUID>`. Can't be changed later. | | Pipeline Secret Keys (create, or Import Yaml File) | `--secret-file` creates the secret | `manifest.config.secrets` lists it by name | | Environment Variables (Add Variable, or Import ConfigMap) | (in the file) | `manifest.config.environment_variables` | | (tags) | `--tags` (create only) | `tags` | The UI's import files are not the CLI's. The UI's secret import is a flat map of keys under one top-level key, and Import ConfigMap is a flat `KEY: "value"` map. The CLI's `--secret-file` holds `name`, `kubernetes_cluster_vrn`, `namespace` and `entries: [{key, value}]`, and environment variables in the pipeline file are a list of `{name, value}`. ### Visual Builder | UI action | YAML | | --- | --- | | Drag a trigger into the builder | An entry in `manifest.triggers`: a local `name` and the trigger's `vrn` | | Drag a function into the builder | An entry in `manifest.function_deployments`: a local `name` and the function's `function_vrn` | | Connect two elements (a connection, or connector) | An entry in `manifest.links`: `source` and `destination` | | Event Trigger Label (Key, Value) on a function-to-function connector | `links[].conditional_trigger_labels: [{triggerLabelName, triggerLabelValue}]` | | Disconnect, or remove an element | Delete the link or entry from the file, then `update` | | Save Draft | `vastde pipelines create` or `pipelines update`, without deploying | | Deploy | `vastde pipelines deploy <name>`, or `pipelines create --deploy` | ### Function deployments The function deployment configuration panel in the Visual Builder. Keys are under the deployment's entry in `manifest.function_deployments`, except where noted. | UI field | YAML key | | --- | --- | | Revision Number | `revision` | | Secret Keys | `config.secrets` | | Concurrency: min, max | `resources.min_concurrency`, `resources.max_concurrency` | | CPU: min, max | `resources.min_cpu`, `resources.max_cpu` | | Memory: min, max | `resources.min_memory`, `resources.max_memory` | | Autoscaling RPS factor | `resources.autoscaling_rps_factor`, which the API marks deprecated and ignored. Use `resources.autoscaling`. | | Disk (Ephemeral) | `resources.storage` | | Timeout | `resources.timeout` (seconds) | | Retries | `links[].config.retries`, on the link, not the deployment | | Log level | `config.log_level` | | Method of Delivery: ordered / unordered | `links[].config.events_order`, on the link, not the deployment | | Batch Size | `config.event_batching.batch_max_size` (1–512) | | Batch Timeout (seconds or milliseconds) | `config.event_batching.batch_timeout_ms`, always in milliseconds | | Environment Variables | `config.environment_variables` | | (no UI field) | `resources.num_workers`, `resources.max_concurrent_requests_limit`, `resources.autoscaling` | ## Names that differ | In the UI | In the CLI and YAML | Notes | | --- | --- | --- | | ElementCreated, ElementDeleted, ElementTagCreated, ElementTagDeleted | `ObjectCreated:*`, `ObjectRemoved:*`, `ObjectTagging:Put`, `ObjectTagging:Delete` | The same four events. The events a function receives use the UI's names: `ObjectCreated:*` delivers type `vastdata.com:Element.ElementCreated`, so `event.subtype` is `ElementCreated`. See [events](/develop/docs/dev-dataengine-reference-events#element-events). | | Source Type NFS | `NFS4` | | | Connection, connector | Link (`manifest.links`) | | | Retries and Method of Delivery, set per function deployment | `retries` and `events_order`, set per link | Set them on the link whose `destination` is the deployment. | | Kubernetes Cluster (pipeline form), Compute Clusters (menu) | `kubernetes_cluster_vrn`, `vastde compute-clusters` | 5.5 renamed Kubernetes Clusters to Compute Clusters in the UI. The API and the VRN still say `kubernetes-clusters`. | | Target Event Broker View, Target Kafka View | `broker: {type: Internal, name: <view bucket>}` | | | Running (pipeline status) | `Ready` | The documented word and the API's value. | | Tags as key-value pairs | `tags` as plain strings | Each tag may contain only lowercase letters, digits and hyphens. | ## Moving a UI-built pipeline into Git Do this once per pipeline. 1. **Export the pipeline.** In the Visual Builder's YAML view, click Download to save `pipeline-manifest.yaml`. That's a complete pipeline file. Or build the file from the CLI as described in [exporting an existing pipeline](/develop/docs/dev-dataengine-reference-pipeline-yaml#exporting-an-existing-pipeline). 2. **Write the trigger and function files.** There's no export for these. Use `vastde triggers get <name> -o yaml` and `vastde functions get <name> -r -o yaml` to read the current values, and write [trigger and function files](/develop/docs/dev-dataengine-reference-function-and-trigger-files) from them. Don't copy read-only fields such as `guid`, `vrn` or `status`. 3. **Pin revisions.** Set `revision` on every function deployment to the revision that's running now, so that the file means exactly what's deployed. `vastde pipelines get <name> --manifest --deployed -o yaml` shows the deployed manifest. 4. **Check it applies.** Run `vastde pipelines update <name> --config <file>` and then `vastde pipelines get <name> --manifest -o yaml`, and compare it with your file's `manifest` section. Expect differences you didn't write: the cluster fills in a `resources` block (scaling, CPU and memory) for each function deployment, shows `revision: null` on unpinned ones, and leaves out an empty `config`. If the latest revision was deployed, the update creates a new revision; it doesn't change the running pipeline until you deploy. 5. **Commit the files.** Leave secret files out of Git. 6. **Switch the team over.** From now on, change the pipeline only by editing its files and running `update` and `deploy`, by hand or [from CI](/develop/docs/dev-dataengine-operations-ci-cd). Use the UI to watch it. ## One source of truth The UI and the CLI save pipelines through the same API, and that API has no version check: no ETag, no "this pipeline changed since you loaded it". The last writer wins, section by section of the manifest. - If someone edits a pipeline in the Visual Builder and saves, and someone else then runs `pipelines update` with the file from Git, the file's sections replace the UI's edits without a warning. - The other way round, a UI save replaces what the file put there. The next `update` from Git puts it back. - A section the file leaves out is kept, so a stale or partial file can leave a mix of both. - Saving in the UI doesn't deploy, but it can create a new revision, and the next deploy, from either side, deploys the latest revision. So pick one place to edit each pipeline. For pipelines you manage from Git, treat the UI as read-only: observe, inspect, read logs and traces, but don't save. ## Registries and compute clusters These forms are usually the platform team's work, not yours: linking a container registry, linking a Kubernetes cluster, creating a VAST compute cluster. If you need one, see [setup prerequisites](/develop/docs/dev-dataengine-operations-setup-prerequisites) for what to ask for. The CLI equivalents are listed here so that you can read a setup script. In 5.5 these commands take flags only, not a file. ### Container registry Link a container registry form, `vastde container-registries link`: | UI field | CLI flag | | --- | --- | | Primary kubernetes cluster | `--primary-cluster` (name or VRN), `--primary-namespace` | | Additional kubernetes clusters | `--additional-clusters`, `--additional-namespaces` | | Name | `--name` | | Base URL | `--url` | | Description | `--description` | | Authentication Method: User credentials | `--auth-type password`, `--username`, `--password` (and optional `--email`) | | Authentication Method: Kubernetes secret | `--auth-type secret`, `--secret` | | Authentication Method: None | `--auth-type none` (the default) | | Tags | `--tags` | A pipeline can deploy a function only if the function's registry is linked to the pipeline's compute cluster and namespace. See [what a deploy requires](/develop/docs/dev-dataengine-reference-pipeline-yaml#what-a-deploy-requires). ### External Kubernetes cluster Link Kubernetes Cluster form, `vastde compute-clusters link`: | UI field | CLI flag | | --- | --- | | Name | `--name` | | API Server URL | `--kube-api-url` | | Description | `--description` | | Certificates: CA certificate, client certificate, private key | `--ca-path`, `--client-cert-path`, `--client-key-path` (PEM files), or `--mtls-credentials-guid` for credentials that already exist; `--interactive` prompts for them | | Tags | `--tags` | | Select Namespaces | `--namespaces` | The cluster's VRN, which pipeline files use, is `vast:dataengine:kubernetes-clusters:<name>`. ### VAST compute cluster Creating a VAST compute cluster (Kubernetes on the cluster's own CNodes) is a cluster-admin task in the VAST Web UI or VAST CLI, with no `vastde` equivalent. When the platform team attaches your tenant to it, the cluster is linked to your tenant and gets your tenant's DataEngine namespace; you don't run `vastde compute-clusters link` for it. `vastde compute-clusters list` shows it. See [Managing VAST Compute Clusters](/docs-5-5/docs/managing-vast-compute-clusters) on the KB. ## See also - [Pipeline YAML](/develop/docs/dev-dataengine-reference-pipeline-yaml) - [Function and trigger files](/develop/docs/dev-dataengine-reference-function-and-trigger-files) - [Pipelines as code](/develop/docs/dev-dataengine-guides-pipelines-as-code) - [CI/CD](/develop/docs/dev-dataengine-operations-ci-cd) - [Setup prerequisites](/develop/docs/dev-dataengine-operations-setup-prerequisites) - [Building and Deploying a Pipeline on VAST DataEngine](/docs-5-5/docs/building-and-deploying-a-pipeline-on-vast-dataengine), [Creating a Trigger](/docs-5-5/docs/creating-a-trigger) and [Managing DataEngine Functions](/docs-5-5/docs/managing-dataengine-functions) on the KB