things to keep in mind while deploying livekit age...
# ask-ai
c
things to keep in mind while deploying livekit agent to gcp cloud run service
t
Thanks for reaching out, Arjun. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Deploying LiveKit agents to GCP Cloud Run is definitely something you can do, though it’s not explicitly documented or officially supported just yet. Let me walk you through some important points to keep in mind: • Networking: LiveKit agents rely on persistent WebSocket connections and don’t actually need HTTP ingress. Since Cloud Run is designed around HTTP, you might need to add a simple HTTP handler to handle health checks smoothly. • Container Requirements: You can use the
lk agent dockerfile
command to create your Dockerfile. It’s a good idea to preload all dependencies and models to help reduce cold start times. • Environment Variables: Make sure to securely inject the necessary variables like
LIVEKIT_URL
and
LIVEKIT_API_KEY
using GCP Secret Manager to keep everything safe. • Cold Starts: Setting a minimum number of instances helps avoid delays, and don’t forget to allocate enough CPU and memory based on what your workload needs. • Graceful Termination: Just a heads-up, Cloud Run might not fully support long-running sessions, so there’s a chance sessions could be interrupted during scaling or shutdown. For production, I’d warmly recommend using LiveKit Cloud—it comes with built-in scaling, observability, and makes managing agents a breeze. If you prefer self-hosting, Kubernetes or Render are great alternatives with more detailed documentation. If you decide to go with Cloud Run, I’d love to hear more about your specific needs, like how long your sessions last or the size of your models. That way, I can offer advice tailored just for you. Sources: Deploying to custom environments | LiveKit Docs | Deployment and scaling | LiveKit Docs | cmd/lk/agent.go | kubernetes/agent-manifest.yaml | Deploying to production | LiveKit Docs
c
we have bought the below livekit plan for 50 dollars: Ship For shipping your project to real users. Can we deploy our agent on livekit cloud on this plan without any extra charges?
t
Absolutely! With the $50 Ship plan, you can happily deploy your agent on LiveKit Cloud without any extra charges, up to these limits: • Agent Deployments: You get 2 agent deployments included. • Session Minutes: Enjoy 5,000 agent session minutes each month. If you go over, it's just $0.01 per additional minute. • Performance: Agents on paid plans stay warm, so you’ll experience instant response times. As long as your usage stays within these limits, there won’t be any extra costs. If you have any questions or need a hand with anything else, I’m here to help! Sources: LiveKit Pricing | Deploy and scale agents on LiveKit Cloud
c
what is meant by "You get 2 agent deployments included."
t
Just to clarify, when we say "2 agent deployments included," it means that with the Ship plan, you’re able to deploy and host up to 2 unique AI agents on LiveKit Cloud. Each deployment is like its own agent instance—think of it as a voice or video agent that manages real-time interactions. These deployments come with: • Hosting on LiveKit Cloud with dedicated resources like CPU and memory. • Helpful metrics to keep an eye on performance, such as latency and errors. • The ability to instantly roll back to a previous version if needed. If you find yourself needing more than 2 deployments, no worries—you can always upgrade to a higher plan like Scale or Enterprise. Feel free to reach out if you have any more questions or want to chat about the best option for you! Sources: An open source stack for real-time multimodal AI | LiveKit Pricing
c
when we say "2 agent deployments included," does it mean at any given point of time at most 2 agents could join the room and user could talk to them?
t
Hi there! I wanted to clarify that "2 agent deployments included" doesn’t mean only 2 agents can join a room at the same time. It actually refers to the number of different agent types or services you can deploy and host on LiveKit Cloud. For example, you might have two different AI agents—one for customer support and another for transcription. The Ship plan includes: • Agent Deployments: You can deploy up to 2 distinct agent types. • Concurrent Agent Sessions: Up to 20 agent instances can be running at the same time across your project. • Room Participants: The total number of participants (users + agents) in a room is flexible and not limited by the "2 agent deployments" quota. If you have any more questions or need a hand with anything else, please don’t hesitate to reach out—I’m here to help! Sources: livekit-protocol/src/livekit.rs | LiveKit Pricing | Connecting to LiveKit | LiveKit Docs
c
Give me a detailed step-by-step guide on how to deploy on livekit cloud when I am on Ship plan.
t
Hi there! Just to make sure we're on the same page, do you already have your agent set up locally and ready to go for deployment? Also, are you using the LiveKit CLI to deploy, or would you like me to help you get that set up? I'm here to guide you through every step!
c
yes, i have agent setup locally and ready to deploy. Will be deploying it the first time.
t
I'm excited to help you get started with deploying your agent on LiveKit Cloud! Here's a friendly, step-by-step guide to walk you through the process: 1. Prerequisites: ◦ Make sure you have LiveKit CLI installed (version 2.5 or later). ◦ Create a LiveKit Cloud project and confirm you have access. ◦ Have your agent project ready, whether it’s in Python, Node.js, or another language. 1. Navigate to Your Project Directory: Simply run
cd your-agent-project
to head to your agent’s folder. 2. Authenticate with LiveKit Cloud: Run
lk cloud auth
to connect your LiveKit Cloud account. If you’re managing multiple projects, you can set your default project by running
lk project set-default "<project-name>"
. 3. Deploy the Agent: Run
lk agent create
. This command will: ◦ Register your agent with LiveKit Cloud. ◦ Create a
livekit.toml
configuration file for you. ◦ Generate a
Dockerfile
if you don’t already have one. ◦ Build and deploy your agent smoothly to LiveKit Cloud. 1. Monitor Deployment: ◦ Keep an eye on logs with
lk agent logs
. ◦ See build-specific logs using
lk agent logs --log-type=build
. ◦ Check your agent’s status anytime with
lk agent status
. 1. Test Your Agent: ◦ Try out the Agent Playground to experiment and ensure everything’s working well. ◦ Then, integrate it with your application or telephony system as needed. If you have any questions or run into any bumps along the way, please don’t hesitate to reach out—I’m here to help you every step of the way! Sources: Deploying to production | LiveKit Docs | Vision Agent Quickstart | LiveKit Docs | Voice AI quickstart | LiveKit Docs | Agent deployment CLI reference | LiveKit Docs | Agent deployment CLI reference | LiveKit Docs
c
How to do this step: ◦ Build and deploy your agent smoothly to LiveKit Cloud.
t
To help you build and deploy your agent to LiveKit Cloud with ease, here’s a friendly step-by-step guide: 1. Navigate to Your Project Directory: Simply run
cd your-agent-project
to head over to the root folder of your agent project. 2. Authenticate with LiveKit Cloud: Run
lk cloud auth
to connect your LiveKit Cloud project. If you have multiple projects, you can list them with
lk project list
and set the default one by running
lk project set-default "<project-name>"
. This helps keep things organized! 3. Deploy the Agent: Run
lk agent create
. This will:If you want to include secrets during deployment, you can do so like this:
Copy code
lk agent create \
--secrets OPENAI_API_KEY=sk-xxx,GOOGLE_API_KEY=<http://ya29.xxx|ya29.xxx> \
--secrets-file ./secrets.env \
.
◦ Register your agent with LiveKit Cloud for you. ◦ Create important files like
Dockerfile
and
livekit.toml
if they aren’t already there. ◦ Upload your code, build a container image, and deploy it seamlessly. 1. Monitor Deployment: Keep an eye on how things are going by checking the status and logs with: ◦
lk agent status
lk agent logs
If anything feels unclear or if you’d like a hand with any of these steps, please don’t hesitate to reach out—I’m here to help! Sources: Deploying to production | LiveKit Docs | Agent deployment CLI reference | LiveKit Docs | Voice AI quickstart | LiveKit Docs
c
I have a config file which needs to be initialised, and for it to initialised it will take
_ENV
variable set to staging or prod. while executing lk agent create got this:
Copy code
=> [ 9/10] RUN chown -R appuser:appuser /app                              16.9s
 => ERROR [10/10] RUN uv run "main.py" download-files                       4.1s
------
 > [10/10] RUN uv run "main.py" download-files:
3.399 Traceback (most recent call last):
3.400   File "/app/main.py", line 18, in <module>
3.400     from context_injector import ContextInjector
3.400   File "/app/context_injector.py", line 2, in <module>
3.400     from db import db_repositories
3.400   File "/app/db/__init__.py", line 1, in <module>
3.400     from db.db_helper import DatabaseHelper
3.400   File "/app/db/db_helper.py", line 1, in <module>
3.400     from db.connection import MongoConnection
3.400   File "/app/db/connection.py", line 2, in <module>
3.400     from config.config import CONFIG as config
3.400   File "/app/config/config.py", line 45, in <module>
3.400     CONFIG: Config = create_config_from_env(Config)
3.400                      ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^
3.400   File "/app/config/config.py", line 31, in create_config_from_env
3.400     raise ValueError(f"Missing environment variable for: {field}")
3.400 ValueError: Missing environment variable for: environment
------
build failed for <http://ord.ocir.io/axyci3pr8vxm/production-cloud-agents-2:p-3lsd80z9ghi-ca-nrwiu47jke6k-v20250915050552|ord.ocir.io/axyci3pr8vxm/production-cloud-agents-2:p-3lsd80z9ghi-ca-nrwiu47jke6k-v20250915050552>: failed to solve: process "/bin/sh -c uv run \"main.py\" download-files" did not complete successfully: exit code: 1
t
It looks like the error is happening because the environment variable
_ENV
isn’t set during your build process. No worries though — you can fix this by setting the environment variable when you deploy, using either the
--secrets
or
--secrets-file
flags. Here’s a simple way to do it: 1. Inline Secrets: Just run your deployment command with the
--secrets
flag like this:
lk agent create --secrets _ENV=staging .
2. Secrets File: Create a file (for example,
secrets.env
) and add this line: `_ENV=staging`Then deploy using:
lk agent create --secrets-file ./secrets.env .
And just so you know, if you use both methods, the inline secrets will override the file. If you have any questions or want me to walk you through it, I’m here to help! Sources: Agent deployment CLI reference | LiveKit Docs | cmd/lk/agent.go | Secrets management | LiveKit Docs
c
lk agent create --secrets _ENV=staging . Using project [proshort] Using agent configuration [livekit.toml] Creating new agent Detected project type [python.uv] Using existing Dockerfile twirp error resource_exhausted: maximum number of agents reached (2/2)
t
It looks like you’ve hit the "maximum number of agents reached (2/2)" message because your LiveKit Ship plan allows for up to 2 agent deployments. No worries though! Here are a few friendly options to help you move forward: 1. Remove Existing Agents: You can stop or delete one of your current agent deployments to make room for a new one. Just use this command:
lk agent delete <agent-name>
2. Check Current Usage: Try running
lk agent status
to see which agents are active and manage them as needed. 3. Upgrade Your Plan: If you find you need more than 2 agent deployments, upgrading to the Scale plan might be a great fit—it offers 4 deployments! Or, you can reach out to LiveKit for a custom plan tailored just for you. If you want, I’m here to help guide you through any of these steps—just let me know! Sources: Quotas and limits | LiveKit Docs | cmd/lk/agent.go
c
while executing lk agent create, how to decide the entrypoint
t
When you're deploying a LiveKit agent using
lk agent create
, the entrypoint is determined in a few thoughtful ways to make things smoother for you: 1. Automatic Detection: The CLI kindly scans your project directory for files with supported extensions like
.py
for Python or
.js
for JavaScript. It looks out for common filenames such as
__main__.py
,
main.py
, or
agent.py
. If there are multiple matches, it’ll gently ask you to choose the right one. 2. Entrypoint Function: The file you select should have an
entrypoint
function that takes a
JobContext
parameter. This function acts as the main starting point for your agent’s execution. 3. Registration: You’ll register this entrypoint in your main file using
cli.run_app()
, passing the
WorkerOptions
with
entrypoint_fnc=entrypoint
. This helps everything run smoothly. 4. Default Behavior: If the CLI doesn’t find a suitable file, it falls back to a default entrypoint for the detected language (like
app.py
for Python), so you’re still covered. If you’d like, I’m here to help you set up your entrypoint or troubleshoot any issues you might be facing. Just let me know! Sources: pkg/agentfs/docker.go | agent/main.py | python-agent-example-app/main.py
c
whydoes the docker file contains: RUN uv run "main.py" download-files The root cause of the error isn't missing environment variables in the build; it's that the build process is being asked to do something it shouldn't: load your entire application's configuration just to download some model files.
t
Thank you for sharing your Dockerfile command! The
RUN uv run "main.py" download-files
step is designed to pre-download models or dependencies during the build, which helps your app start up faster in production. I understand that if this is causing some hiccups, it might be because your application is loading its full configuration when it doesn’t really need to during the build process. Here’s a friendly guide to help you smooth things out: 1. Refactor the
download-files
Command:
Try to make sure the
download-files
part in
main.py
is kept simple and separate from the full app configuration. For instance, consider using a lightweight script or argument parsing so it can handle downloads without initializing everything. 2. Optimize the Dockerfile: You can structure it like this to keep things clear and efficient:`# Pre-download models RUN uv run main.py download-files`Just double-check that this step only grabs the files it needs and doesn’t rely on runtime environment variables such as
_ENV
. 3. Use Secrets for Environment Variables: If your process does need
_ENV
, it’s best to pass it during deployment with:`lk agent create --secrets _ENV=staging .` Please feel free to reach out if you’d like a hand with refactoring or tweaking your Dockerfile—I’m here to help! Sources: Builds and Dockerfiles | LiveKit Docs | pkg/agentfs/examples/node.Dockerfile | agent/Dockerfile | python-agent-example-app/Dockerfile | Builds and Dockerfiles | LiveKit Docs
c
Copy code
Try to make sure the download-files part in main.py is kept simple and separate from the full app configuration. For instance, consider using a lightweight script or argument parsing so it can handle downloads without initializing everything.
i don't even have download-files word written in main.py. from where exactly this is being done, can you create a new file and give me it's code