Deploy Package

Ship agents as an API server, a Docker image, or a cloud service with praisonai-deploy

praisonai-deploy turns an agents.yaml file into a running service — a local API server, a Docker image, or a cloud deployment on AWS, Azure, GCP, Fly, Railway, Render, or any registered plugin provider.

from praisonai_deploy import Deploy

deploy = Deploy.from_yaml("agents.yaml")
result = deploy.deploy()
status = deploy.status()

Install

pip install praisonai-deploy

pip install "praisonai-deploy[api]"

pip install "praisonai[deploy]"

praisonai-deploy is a tier-2 package (C14, publish slot #8). It drives host CLIs — docker, aws, az, and gcloud — directly. No boto3, Azure, or Google Cloud SDKs are required.

Quick Start

1. Pick a deployment type

   Every deployment is one of three types.

   from praisonai_deploy import Deploy
   
   deploy = Deploy.from_yaml("agents.yaml")

2. Deploy

   result = deploy.deploy()
   print(result.url)

3. Check status

   status = deploy.status()
   print(status.state)  # running / stopped / pending / failed / not_found / unknown

Which Type?

Choose a deployment type based on where the agent runs.

PraisonAI ships six providers out of the box (aws, azure, gcp, fly, railway, render). You can add your own by publishing a package that registers under the praisonai.deploy.providers entry-point group — see Custom cloud providers.

Provider Coverage of CloudConfig

Not every provider applies every CloudConfig field. Fields a provider cannot apply are logged and echoed in DeployResult.metadata["unapplied"] (PraisonAI PR #4876).

✅ applied · ⚠️ not applied (logged + metadata["unapplied"])

See Fly, Railway, and Render for the per-provider details and workarounds.

User Flow

A full deploy goes from validation to teardown.

praisonai deploy validate --file agents.yaml   # strict schema check — catches typos and missing sections
praisonai deploy doctor --all                  # docker/aws/az/gcloud present?
praisonai deploy plan --file agents.yaml       # dry-run
praisonai deploy run --file agents.yaml        # execute
praisonai deploy status --file agents.yaml     # poll state
praisonai deploy destroy --file agents.yaml --yes  # teardown

What’s New

Fixes bundled in this release:

• /chat message forwarding now correctly forwards the user message.
• Docker builds use the correct build context, environment variables, and ports, and replace existing containers on rebuild.
• Foreground API deploys block until the process exits.
• The CLI docker shortcut merges the YAML deploy: section into invocation flags.
• MCP deploy.status accepts an explicit config_path argument.
• praisonai deploy api (foreground and --background) now spawns the Flask server with the same Python interpreter as the CLI (sys.executable), so it works on Windows and any multi-Python / venv setup. The previous bare python invocation could resolve to a different interpreter and fail with ModuleNotFoundError: No module named 'flask'.
• The generated Flask API server subprocess now inherits the parent environment (e.g. OPENAI_API_KEY), so the auto-generated /chat endpoint reaches the agent runtime without extra wiring.
• Docker deploys now honor an optional sibling deploy.api block — set api.auth_enabled: false to expose the generated /chat endpoint unauthenticated. Previously the block was silently dropped and the container defaulted to auth-on (PR #3609).
• Generated Docker containers now run Gunicorn with --timeout 120 --graceful-timeout 30. Cold-start /chat calls (agent import + first model round-trip) used to exceed Gunicorn’s 30 s default and get SIGKILL’d mid-request; the new defaults tolerate the cold-start latency and shut workers down cleanly on restart (PR #3630).

Best Practices

Related