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?