Deploy Pipecat bots to Fly.io machines
bot_runner.py
web service and the bot.py
separately. To keep this example simple, we’ll use the same container image for both services.
fly.toml
to the root of your project directory. Here is a basic example:
bot.py
resources later, so you can set and scale these as you like (fly scale ...
)
.env
in your project root:
bot.py
.
FLY_APP_NAME
should match the name of your fly instance,
such as that declared in your fly.toml..env
will allow us to test in local development, but is not included in the deployment. You’ll need to set them as Fly app secrets, which you can do via the Fly dashboard or cli.
fly secrets set ...
Dockerfile
in the root of the project:
7860
to serve our bot_runner.py
FastAPI service.bot.py
requires.bot_runner.py
and listens for web requests.bot_runner.py
/start_bot
endpoint:
fly launch
or fly launch --org orgname
if you’re part of a team.
This will step you through some configuration, and build and deploy your Docker image.
Be sure to configure your app secrets with the necessary environment variables once the deployment has complete.
Assuming all goes well, you can update with any changes with fly deploy
.
POST
request to https://your-fly-url.fly.dev/start_bot
. All being well, this will return a room URL and token.
A nice feature of Fly is the ability to monitor your machines (with live logs) via their dashboard:
https://fly.io/apps/YOUR-APP_NAME/machines
This is really helpful for monitoring the status of your spawned machine, and debugging if things do not work as expected.
restart policy
to no
. This prevents the machine attempting to restart after the session has concluded and the process exits.POST
request to the bot_runner.py
. Be sure to configure a maximum number of instances, or authenticate requests to avoid costs getting out of control.
We also deployed our bot.py
on a machine with the same image as our bot_runner.py
. To optimize container file sizes and increase security, consider individual images that only deploy resources they require.