> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vers.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Put apiv1env vars



## OpenAPI

````yaml /api-reference/openapi.json put /api/v1/env_vars
openapi: 3.1.0
info:
  title: Orchestrator Control Plane API
  description: ''
  license:
    name: ''
  version: 0.1.0
servers: []
security: []
paths:
  /api/v1/env_vars:
    put:
      tags:
        - env_vars
      operationId: set_env_vars
      requestBody:
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/SetEnvVarsRequest'
        required: true
      responses:
        '200':
          description: Environment variables updated
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/EnvVarsResponse'
        '400':
          description: Validation error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ErrorResponse'
        '401':
          description: Unauthorized
        '500':
          description: Internal server error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ErrorResponse'
      security:
        - bearer_auth: []
components:
  schemas:
    SetEnvVarsRequest:
      type: object
      description: >-
        Request body for PUT /env_vars — sets (upserts) one or more environment
        variables.


        # Lifecycle model


        Environment variables are written to `/etc/environment` inside a VM
        **once

        at boot time** via a vsock `WriteFile` request. They are **not**
        live-synced

        to running VMs. This is intentional: VMs are ephemeral (create → use →

        destroy/branch), so env var changes naturally take effect on the next
        VM.


        The `replace` flag exists so callers can atomically express "I want
        exactly

        these variables and nothing else" without having to DELETE each stale
        key

        individually. Without it, the only way to remove a variable from future
        VMs

        is a separate `DELETE /env_vars/{key}` call per key.
      required:
        - vars
      properties:
        replace:
          type: boolean
          description: >-
            If true, delete all existing variables before writing the new set.

            This gives "set exactly these vars" semantics. Default: false
            (upsert).
        vars:
          type: object
          description: >-
            Key-value pairs to set. Keys must be valid shell identifiers

            (`^[A-Za-z_][A-Za-z0-9_]*$`, max 256 chars). Values max 8192 chars.


            When `replace` is false (default): existing keys are overwritten,
            keys

            not mentioned are left untouched (upsert semantics).


            When `replace` is true: all existing variables are deleted first,
            then

            only the provided vars are stored (replace-all semantics).
          additionalProperties:
            type: string
          propertyNames:
            type: string
    EnvVarsResponse:
      type: object
      description: Response body for GET /env_vars and PUT /env_vars.
      required:
        - vars
      properties:
        vars:
          type: object
          description: All environment variables currently set for the authenticated user.
          additionalProperties:
            type: string
          propertyNames:
            type: string
    ErrorResponse:
      type: object
      properties:
        error:
          type: string
          description: Reason of error
        success:
          type: boolean
          description: 'Is always: false'
  securitySchemes:
    bearer_auth:
      type: http
      scheme: bearer
      bearerFormat: Token

````