Cannot deploy an agent from a monorepo
Hello,
We have a monorepo (using Turborepo and pnpm), and we'd like our Node.js-based LiveKit agent to live there so that we can import shared code from packages that live in the same monorepo. It looks roughly like this:
<repo>
apps/my-livekit-agent
package.json
livekit.toml
Dockerfile
src/agent.ts # imports from @repo/app-types/shared
packages/app-types
package.json
src/shared.ts
The Dockerfile is set up such that the agent container image builds successfully when I run docker build -f apps/my-livekit-agent . from the root of the monorepo. (This is also how we build and deploy other services.)
Unfortunately, the LiveKit CLI lk agent deploy command does not seem to allow this setup in any way, preventing us from deploying our agent to LiveKit Cloud. The CLI seems to require that the package.json with the @livekit/agents dependency, the livekit.toml file, the Dockerfile, and the entire container build context are all in one and the same directory and there isn't a way to push your own container image either.
I assume this issue is a feature request, but let me know if I'm missing something!
-Dennis
I ended up being able to successfully deploy my agent by:
- Temporarily copying
apps/my-livekit-agent/livekit.tomlandapps/my-livekit-agent/Dockerfileto the root of my repo - Running
lk agent deploy --skip-sdk-check(I discovered this flag by reading the CLI source code) - Removing the
COPY .gitignorecommand from myDockerfilesince that was missing in the tarball uploaded to LiveKit for some reason (despite having my own.dockerignorethat should allow it to be included)
Would still appreciate if this could be made easier, and made to be consistent with docker build behavior!
Oh thanks for sharing the --skip-sdk-check ---> Could we add this to the CLI --help command? I wasted a lot of time on this same issue
But more generally, support for https://docs.astral.sh/uv/concepts/projects/workspaces/ /monorepos would be very useful
The --skip-sdk-check might work for the CLI, but I don't think it's exposed for deployment from GitHub actions. I wonder if it would be better to just add a dependency to the root package.json even though it really doesn't belong there.
From a quick scan of the CLI source code, it looks like there was the intent to also scan the lock files to see if the dependency was present, but it doesn't look like the regular expression correctly parses the pnpm-lock.yaml file, at least for workspace lock files. Ideailly this would be able to detect the presence of the dependency being used in a workspace package