# How should lk agent deploy handle Node workspace agents in monorepos? **URL:** \ **Category:** Getting Started\ **Tags:** agent-deployment\ **Created:** [June 8, 2026, 8:08am UTC](https://community.livekit.io/t/how-should-lk-agent-deploy-handle-node-workspace-agents-in-monorepos/1372 "2026-06-08T08:08:53Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Dan\_Tran](https://avatars.discourse-cdn.com/v4/letter/d/b19c9b/32.png) [@Dan\_Tran](https://community.livekit.io/u/Dan_Tran)\ **Post date:** [June 8, 2026, 8:08am UTC](https://community.livekit.io/t/how-should-lk-agent-deploy-handle-node-workspace-agents-in-monorepos/1372/1 "2026-06-08T08:08:53Z")
What’s the recommended pattern for deploying a Node LiveKit agent from a Yarn monorepo? Our repo shape is: - root `package.json`, `yarn.lock`, `.yarnrc.yml` - root `Dockerfile` for our API service - multiple apps under `/apps` - `apps/livekit-worker/package.json` - `apps/livekit-worker/Dockerfile` - `apps/livekit-worker/livekit.toml` - shared config under `packages/tsconfig` The worker Dockerfile needs repo-root context so it can copy the root lockfile and shared workspace files. Running `lk agent deploy` from `apps/livekit-worker` uploads only the app folder, so Docker fails on `COPY apps/livekit-worker/…` and `COPY packages/tsconfig`. Running from repo root as-is is not viable because the root `Dockerfile` builds our API service, not the LiveKit worker. We tried `lk agent deploy --image livekit-worker:latest …`, but our project gets a 403 because Bring Your Own Container is Enterprise-only. Our current workaround is to generate a temporary deploy context that looks like a minimal repo root: - copy root `package.json`, `yarn.lock`, `.yarnrc.yml` - copy `apps/livekit-worker/package.json`, `tsconfig.json`, and `src` - copy `packages/tsconfig` - copy `apps/livekit-worker/Dockerfile` to temp-root `Dockerfile` - copy `apps/livekit-worker/livekit.toml` to temp-root `livekit.toml` - patch the temp-root `package.json` to include `@livekit/agents`, because the CLI preflight otherwise livekit says `@livekit/agents not found in any project files`, even though it exists in `apps/livekit-worker/package.json` - run `lk agent deploy --subdomain ` This works locally and gets us past the build-context issue, but it feels like a workaround. For non-Enterprise projects, is this the recommended long-term approach for monorepo/workspace agents? Or is there a supported way to: 1. pass a Dockerfile path separately from the deploy working directory, 2. have the CLI detect `livekit/agents` in workspace package manifests, or 3. point deploy at a workspace package while still using repo-root Docker context? ---
**Author:** ![darryncampbell](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/darryncampbell/32/20_2.png) [@darryncampbell](https://community.livekit.io/u/darryncampbell)\ **Post date:** [June 8, 2026, 9:34am UTC](https://community.livekit.io/t/how-should-lk-agent-deploy-handle-node-workspace-agents-in-monorepos/1372/2 "2026-06-08T09:34:12Z")
We had a similar question come up for Python a while back, [How to structure a Python project with multiple agents sharing code - #7 by Ashwin\_Dharne](https://community.livekit.io/t/how-to-structure-a-python-project-with-multiple-agents-sharing-code/86/7) and the solution there was to swap Dockerfiles around (in the root) during a deploy. I’m not an expert in yarn monorepos however, so quite possibly I’m missing something. ---
**Author:** ![system](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/system/32/26_2.png) [@system](https://community.livekit.io/u/system)\ **Post date:** [June 23, 2026, 9:34am UTC](https://community.livekit.io/t/how-should-lk-agent-deploy-handle-node-workspace-agents-in-monorepos/1372/3 "2026-06-23T09:34:55Z")
Closed on June 23, 2026, 9:34am UTC This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.