Thanks — I understand you have agent code in

packages/agent

in a monorepo and want to deploy it. Below are concise, actionable ways to deploy that target the subdirectory. Quick overview: use the LiveKit CLI (

lk agent

) or the LiveKit GitHub Action and point the tool at your agent’s working directory (

packages/agent

). Also ensure your env/secrets and any model/dependency files are available to the working directory before deploy. 1) Local CLI deploy (recommended for testing) 1. cd into the agent folder: ◦ cd packages/agent 1. Ensure your project is initialized and dependencies are installed: ◦ Run your language-specific setup (e.g.,

npm install

/

pip install -r requirements.txt

) and confirm any model files are downloaded. 1. Ensure your secrets are available (example

.env

in

packages/agent

): ◦ LIVEKIT_API_KEY, LIVEKIT_API_SECRET, LIVEKIT_URL, plus any other required keys. 1. Deploy using the working-directory flag (run from repo root or anywhere): ◦ lk agent create --working-directory packages/agent --secrets-file packages/agent/.env 2) CI/CD with GitHub Actions • Use the LiveKit deploy action and set WORKING_DIRECTORY to

packages/agent

. Example step:

- name: Deploy LiveKit Cloud Agent
  uses: livekit/deploy-action@v2
  env:
    LIVEKIT_URL: ${{ secrets.LIVEKIT_URL }}
    LIVEKIT_API_KEY: ${{ secrets.LIVEKIT_API_KEY }}
    LIVEKIT_API_SECRET: ${{ secrets.LIVEKIT_API_SECRET }}
    SECRET_LIST: ${{ secrets.SECRET_LIST }}
  with:
    OPERATION: deploy
    WORKING_DIRECTORY: packages/agent

• Ensure your action installs dependencies and downloads model files before the deploy step. 3) livekit.toml and config • The CLI will generate a

livekit.toml

in the working directory. Confirm it contains the project subdomain and agent id. • Keep secrets out of the agent’s secret list if they are injected automatically (e.g., LiveKit API keys are injected). 4) Important checklist before deploy • Dependencies installed and build step (if needed). • Model files (VAD, noise-cancel models, etc.) downloaded where the agent expects them. •

.env

or secrets configured and referenced by the

--secrets-file

or CI secrets. • Correct

WORKING_DIRECTORY

for CI or

--working-directory

for CLI. If you’d like, tell me: • Which runtime/language your agent uses (Node/Python/etc.), and • Whether you want a full GitHub Actions workflow example or a one-off CLI script. I can then give a tailored example that matches your setup. Sources: Deploy LiveKit Agents with GitHub Actions | LiveKit | Examples | livekit/livekit_composite | DeepWiki | Voice AI quickstart | LiveKit Documentation

Thanks — I see you ran

lk agent create --working-directory packages/agent

and got the error that

--working-directory

isn’t a valid flag. You’re right to call that out. Short answer: the LiveKit CLI does not support a

--working-directory

flag for

lk agent create

. Run the command from inside your agent package instead, or wrap it in a shell subshell so the CLI sees the correct working directory. How to fix it (pick one): 1) Run from the agent folder • cd packages/agent • lk agent create 2) Run from repo root without changing your shell • (cd packages/agent && lk agent create) 3) In CI (GitHub Actions) • Add a step that changes directory or sets the working-directory before calling the action/CLI. Example: ◦ name: Set up and deploy agent run: | cd packages/agent install deps, download models, etc. lk agent create Checklist before running `lk agent create`: • Dependencies installed / build step completed in

packages/agent

• Model files downloaded where the agent expects them • Secrets available (via

.env

or CI secrets) in the agent directory •

livekit.toml

,

package.json

/

requirements.txt

present in

packages/agent

If you want, tell me: • Which language/runtime your agent uses (Node or Python), and • Whether you’d like a complete GitHub Actions workflow that cd’s into

packages/agent

and performs the deploy. I can provide a tailored example for your stack. Sources: Deploy LiveKit Agents with GitHub Actions | LiveKit | Agents (Node.js) | livekit/livekit_composite | DeepWiki

Thanks — I see the error: the Docker build fails at the line that copies

package.json

and

pnpm-lock.yaml

because

pnpm-lock.yaml

isn’t present in the build context. I’ll walk you through quick, focused checks and fixes so you can get

lk agent create

to succeed. 1) Confirm the lockfile exists in packages/agent • From your repo root run:

ls packages/agent/package.json packages/agent/pnpm-lock.yaml

If

pnpm-lock.yaml

is missing, generate it:

cd packages/agent
  pnpm install

Then re-run

ls

to confirm the file is present. 2) Verify .dockerignore isn’t excluding the lockfile • Open

packages/agent/.dockerignore

and ensure it does NOT exclude

pnpm-lock.yaml

or

package.json

. • Example: do not have a line that unintentionally excludes

*.yaml

or the lockfile. You can explicitly allow them:

node_modules
  dist
  .env*
  !package.json
  !pnpm-lock.yaml

3) Check the Dockerfile COPY line and build context • The Dockerfile COPY you saw (

COPY package.json pnpm-lock.yaml ./

) expects those files in the build context root. Since you ran

lk agent create

from

packages/agent

, the CLI uses that directory as context—so the files must be inside

packages/agent

. • If your monorepo has package.json/lockfile at a different path (e.g., workspace root), move or duplicate the agent’s package.json and

pnpm-lock.yaml

into

packages/agent

, or modify the Dockerfile to copy from the correct relative location (but copying from outside the build context is not allowed). 4) Re-run the CLI build • From inside the agent directory:

cd packages/agent
  lk agent create

• Or from repo root without changing shell:

(cd packages/agent && lk agent create)

5) Optional: let the CLI regenerate a Dockerfile (if you suspect your Dockerfile is incorrect) • Use:

lk agent create --force-dockerfile

This replaces the Dockerfile with the CLI’s template that correctly handles dependency installation (useful if your custom Dockerfile has mistakes). Summary • The error is caused by the Dockerfile trying to copy

pnpm-lock.yaml

which is not found in the build context. • Ensure

pnpm-lock.yaml

exists under

packages/agent

, that

.dockerignore

doesn’t exclude it, and run

lk agent create

from that directory. If you’d like, tell me: • Do you manage dependencies at the agent folder (each package has its own package.json) or at the monorepo root (workspaces)? I can then give a concrete Dockerfile snippet or a recommended monorepo layout and a small GitHub Actions step that cd’s into

packages/agent

and builds/deploys. Sources: Examples | livekit/livekit_composite | DeepWiki | Agents (Node.js) | livekit/livekit_composite | DeepWiki | Voice AI quickstart | LiveKit Documentation

Thanks — that helps. The key point: Docker’s build context (what the Dockerfile can COPY) is limited to the directory you run the build from. Since your build context is

packages/agent

, files that live at the repo root (like the root

pnpm-lock.yaml

) are not accessible, so the

COPY package.json pnpm-lock.yaml ./

step fails. Here are safe options you can pick from, with pros/cons. Tell me which fits your repo and I’ll give exact commands or a Dockerfile snippet. Options • Add a lockfile inside packages/agent (recommended, simplest) ◦ Generate a per-package lockfile so the Docker build can find it: i. cd packages/agent ii. run

pnpm install

(or

pnpm install --workspace-no-build --lockfile-dir .

if using workspaces; run the command your pnpm version supports) to create

pnpm-lock.yaml

inside

packages/agent

. ◦ Pros: Minimal changes, works with current Dockerfile COPY. ◦ Con: Duplicates lockfile across repo (but locks dependencies for that package). • Copy the root lockfile into the agent directory as part of your build step ◦ Before running

lk agent create

, copy or symlink the root lockfile: ▪︎ cp pnpm-lock.yaml packages/agent/ ◦ Or in CI, add a step that copies the root lockfile into

packages/agent

before

lk agent create

. ◦ Pros: Keeps single source of truth if automated in CI. ◦ Con: Manual copy unless automated. • Build with a root build context and adjust Dockerfile (advanced) ◦ Change build context to monorepo root so Docker can access root lockfile, and modify Dockerfile paths to build only the agent: ▪︎ Build from repo root (but note: LiveKit CLI expects to run from agent dir; you’d need to customize how you create the image). ◦ Pros: No duplicate files. ◦ Con: More complex; CLI tooling may assume agent directory as context. • Modify Dockerfile to read deps from root via multi-stage or relative paths (not allowed if outside context) ◦ You cannot COPY files outside the build context. So this only works if you run the build from the monorepo root as the context. • Use npm lockfile instead (if simpler) ◦ If you prefer npm, ensure

package-lock.json

exists in packages/agent and adjust Dockerfile to COPY that file instead. ◦ Pros: Aligns with npm-based workflows. ◦ Con: Requires switching package manager or generating an npm lockfile for that package. Quick checklist to avoid further failures • Ensure

packages/agent/pnpm-lock.yaml

exists or is copied there before

lk agent create

. • Confirm

.dockerignore

does not exclude the lockfile. • Run

pnpm install

from

packages/agent

so

node_modules

and lockfile match that package (or use

--frozen-lockfile

in CI). • After lockfile is present, run

cd packages/agent && lk agent create

(or wrap with subshell). If you tell me: • Are you using pnpm workspaces (yes/no)? • Do you prefer the simplest fix (copy/generate lockfile in packages/agent) or a CI/root-context solution? I’ll give the exact commands or a CI step tailored to your preference.

Do this. 1) From repo root, copy the lockfile into the agent folder:

cp pnpm-lock.yaml packages/agent/

2) Enter the agent folder, install deps, and create the agent:

cd packages/agent
pnpm install
lk agent create

CI example (GitHub Actions) — step before deploy:

- name: Prepare agent dir
  run: |
    cp pnpm-lock.yaml packages/agent/
    cd packages/agent
    pnpm install
- name: Deploy agent
  run: |
    cd packages/agent
    lk agent create

That’s it. If you want, I can provide a one-liner that copies + runs the deploy from the repo root.

Do this. 1) Copy the root lockfile into the agent folder (no

|| true

):

cp pnpm-lock.yaml packages/agent/

2) In the agent folder, regenerate a lockfile that matches your pnpm config:

cd packages/agent
pnpm install --no-frozen-lockfile

3) Ensure lockfile is included in the build context (check .dockerignore): • Remove any lines that exclude

pnpm-lock.yaml

or explicitly allow it:

node_modules
  dist
  .env*
  !pnpm-lock.yaml
  !package.json

4) Re-run the deploy:

lk agent create

CI one-liner (from repo root):

cp pnpm-lock.yaml packages/agent/ && (cd packages/agent && pnpm install --frozen-lockfile && lk agent create)

Notes: • If you want pnpm to respect your local catalogs config in CI, first update the repo lockfile at the root with

pnpm install --no-frozen-lockfile

, commit it, then use the CI one-liner above.