> For the complete documentation index, see [llms.txt](https://docs.zerve.ai/self-managed/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zerve.ai/self-managed/configuration/code-execution.md). # Code Execution The `execution` block of the [Execution Environment Manifest](/self-managed/configuration/execution-environment-manifest.md) defines where and how Zerve runs user code. ```yaml execution: defaultComputeOption: k8s # required — used unless a run overrides it computeOptions: # required — the enabled backends - k8s capabilities: # optional — feature sets to enable - jobs languages: # optional, default: [python] - python - r k8s: { ... } # required when `k8s` is in computeOptions armada: { ... } # required when `armada` is in computeOptions ``` Snippets below start at the manifest root, so in your values file they go under `executor.execEnvManifest`. Fields marked `(ref)` accept a [reference value](/self-managed/configuration/execution-environment-manifest.md#reference-values) instead of a literal. Supported `computeOptions` values are: * `k8s` * `armada` Both may be listed; `defaultComputeOption` then determines where a run is submitted unless the user selects otherwise. **`capabilities`:** * `jobs` — run Notebook blocks, each as a job on the selected backend. Always include this. **`languages`** determines the languages offered in the Environment picker. Each one requires a matching entry under [`build.imageConfigs`](/self-managed/configuration/builds.md#language-runtimes). As with builds, runs are submitted to the runtime namespace provisioned by the chart, so `namespace` below must match `executor.runtimeNamespace.name` in your values file (`zerve-runtime` by default). Builds and runs can share the same namespace. ## Choosing a backend {% tabs %} {% tab title="Kubernetes" %} ```yaml execution: k8s: cluster: endpoint: https://kubernetes.default.svc # (ref) required token: # (ref) required ref: file path: /var/run/secrets/kubernetes.io/serviceaccount/token caPath: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt # optional verify: true # optional — set false to skip API server cert checks namespace: zerve-runtime # required — namespace where run pods land serviceAccountName: default # optional, default: "default" nodeSelector: # optional workload-type: executor imagePullSecrets: # optional - name: regcred fluentbitImage: nexus.example.com/ghcr.io/fluent/fluent-bit:5.0 # optional ephemeralVolumeConfig: # optional, default: emptyDir type: empty_dir ``` If builds run on the same cluster, define the `cluster` block once as a YAML anchor in [`build.builder`](/self-managed/configuration/builds.md#choosing-a-builder) and reference it here. {% endtab %} {% tab title="Armada" %} Same field set as the Armada builder. See [Choosing a builder](/self-managed/configuration/builds.md#choosing-a-builder) for the `server` and `tolerations` fields, and reference the server block with a YAML anchor instead of repeating it. ```yaml execution: armada: server: *armadaServer # required queue: zerve # required namespace: zerve-runtime # required priority: 1.0 # optional, default: 1.0 serviceAccountName: default # optional, default: "default" nodeSelector: { } # optional imagePullSecrets: # optional — must already exist in `namespace` - name: regcred tolerations: # optional - key: dedicated operator: Equal value: armada-execution fluentbitImage: nexus.example.com/ghcr.io/fluent/fluent-bit:5.0 # optional ephemeralVolumeConfig: # optional, default: emptyDir type: empty_dir ``` `*armadaServer` refers to the `&armadaServer` anchor in the `build.builder.armada.server` block of the same manifest. If the Armada builder is not used, define the `server` block here instead. {% endtab %} {% endtabs %} ## Ephemeral storage for runs Run pods receive an ephemeral volume mounted at `/tmp`, sized according to the compute option selected by the user. Two backing types are available: ```yaml ephemeralVolumeConfig: type: empty_dir # default — node-local storage, capped at the requested size ``` ```yaml ephemeralVolumeConfig: type: generic storageClassName: standard # optional — omit to use the cluster's default class ``` `empty_dir` is the fastest option, but consumes node ephemeral storage, so runs requesting a large volume require nodes sized accordingly. `generic` provisions a `ReadWriteOnce` PVC per run, which decouples the volume from node disk at the cost of provisioning latency. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.zerve.ai/self-managed/configuration/code-execution.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.