Thanks — I hear you: you want each managed LiveKit agent in LiveKit Cloud to be traceable back to the exact source-code version it was built from, without using the secret-key hack that forces a restart. I looked into how agent deployments work and what metadata you can attach. Short answer • You cannot customize the auto-generated deployment version string (for example,

v20260318163612

). • There is no built-in way to attach arbitrary, queryable deployment-level metadata (like a git SHA) that you can later query from the CLI/dashboard. What that means • The timestamp-style version is managed by the LiveKit agent deployment system and cannot be overridden. • There is no documented API/CLI/dashboard field for user-defined deployment metadata you could query later. Practical alternatives you can use now • Embed the commit SHA (or build tag) into your application at build time so the running agent can report it: ◦ Add the commit hash to a constant or environment variable baked into the agent binary/image during your CI build. The agent can then log this value at startup or expose it via any app-level health/status endpoint. • Put the version into the Docker image metadata or tag: ◦ Tag images with your git SHA or semantic version and record that tag in your CI/CD records. The LiveKit Cloud build logs or your registry will then show which image corresponds to the deployment. • Emit the version in logs at startup: ◦ Have the agent log its

build/commit

on boot. You can search logs (via

lk agent logs

or your logging system) to map running agents to commits. • Use Job-level metadata for per-invocation context: ◦ If you dispatch work to agents, include metadata with each job (accessible in the agent via

JobContext.job.metadata

). This is per-job, not per-deployment, but can help tie specific runs to code versions. • Secrets as a last resort (what you already know): ◦ Storing a

sha_<hash>

secret will make the value available to the agent, but updating secrets with

lk agent update-secrets --overwrite

triggers a restart, which you rightly want to avoid. If any of these alternatives would work for you, I can help with concrete steps: • Show an example of embedding a git SHA into a build and logging it from your agent. • Show how to tag Docker images and link tags to LiveKit Cloud build logs. • Show how to add and read metadata from

JobContext.job.metadata

if you want per-run traceability. Which direction sounds best for your workflow — embedding in the build image, emitting startup logs, or using job metadata? Sources: Agents Framework | livekit/livekit_composite | DeepWiki | examples/drive-thru | livekit/livekit_composite | DeepWiki | Server-side | livekit/livekit_composite | DeepWiki | Job lifecycle | LiveKit Documentation | Agent dispatch | LiveKit Documentation, with interactive elements