Do I need a Procfile to deploy a Python app on Render?

No. Render uses an explicit build command and start command that you set in the Dashboard or in a render.yaml Blueprint. There is no Procfile, no buildpack autodetection magic, and no per-process declaration file. If you're migrating from Heroku, translate each Procfile entry into a separate Render service: a web: line becomes a Web Service, a worker: line becomes a Background Worker, and a scheduled task becomes a Cron Job.

Should I use a Background Worker or a Render Workflow for async tasks?

Use a Background Worker when you already have a Celery, RQ, or Sidekiq-style codebase that polls a queue you manage yourself, typically backed by Render Key Value. Use a Render Workflow when you want Render to handle queuing, spin-up, retries, and per-task observability for you, and when individual tasks can run for up to 24 hours on their own instance. Workflows are a better fit for AI agents, ETL pipelines, and fan-out batch jobs. See Workflows versus job queues for the full comparison.

How do I run scheduled Python scripts on Render?

Create a Cron Job service. The schedule field takes a standard cron expression (in UTC), and the command can be any Linux command or executable bash script — for example, python jobs/daily_report.py. Render guarantees that at most one run of a cron job is active at a time and stops any run that exceeds 12 hours. Free instances are not available for Cron Jobs.

Why does my Python web service fail with 'No open ports detected'?

Your application is binding to 127.0.0.1 instead of 0.0.0.0, or it is listening on a hardcoded port that does not match the $PORT environment variable Render injects. Bind your HTTP server to 0.0.0.0 and read the port from os.environ.get("PORT", "10000"). For Gunicorn, use gunicorn app:app --bind 0.0.0.0:$PORT. For Uvicorn, use uvicorn main:app --host 0.0.0.0 --port $PORT. The default value of PORT is 10000. See Port binding for details.

Can I deploy a Python app from a private GitHub repository?

Yes. After you connect GitHub, GitLab, or Bitbucket to your workspace, Render can deploy from any public or private repo your account has access to. Render also supports auto-deploys on each push and pull request previews for connected repos. Public-URL deploys without provider credentials work too, but they don't get auto-deploys or PR previews.

Platform

5 AI Python apps to deploy on Render

June 27, 2026

Python is the default language of modern AI, and the shapes those AI apps take — real-time voice agents, MCP tool servers, autonomous research agents, retrieval-augmented (RAG) APIs, and web scrapers that feed LLMs — map directly to Render's core service types. The five AI apps below show what each of those deployments looks like in practice.

Render handles building, running, and scaling your application from a connected Git repository, with no DevOps configuration. Every example below has a matching starter at render.com/templates under the Python tag.

Every Python application you deploy on Render follows the same five-step pattern:

Code lives in a Git repository in GitHub, GitLab, or Bitbucket.
Render connects to the repo and watches the branch for changes.
A build command installs dependencies, typically pip install -r requirements.txt.
A start command runs the application, such as gunicorn app:app or python worker.py.
Environment variables configure runtime behavior like database URLs, API keys, feature flags.

Once you understand this pattern, you can apply it to every deployment scenario below. Render's native Python runtime provides the runtime for your application, installs your dependencies, and executes your start command.

The most ambitious AI apps are more than one process, and Render gives each layer a service type that fits. The Voice Agent template pairs a real-time voice agent with background orchestration: a caller talks to a browser-based LiveKit agent (OpenAI GPT-4o, Whisper, and TTS) to file an insurance claim, and the agent kicks off a Workflow that fans out policy verification, damage analysis, fraud checks, cost estimates, and a repair-shop lookup in parallel, streaming progress back to the UI.

Render Workflows are a durable primitive that coordinates multi-step background jobs across independent instances, with built-in retries, timeouts, and execution observability. The LiveKit agent itself runs as a Background Worker: a service type that runs a persistent process without exposing a public URL. The parallel claim steps run as a Workflow: each step is a registered task that Render runs on its own instance with its own retries, fanned out concurrently.

python

# claim_workflow.py
import asyncio
from render_sdk import Workflows

app = Workflows()

@app.task
async def process_claim(claim: dict) -> dict:
    policy, damage, fraud, cost, shop = await asyncio.gather(
        verify_policy(claim),
        analyze_damage(claim),
        check_fraud(claim),
        estimate_cost(claim),
        find_repair_shop(claim),
    )
    return {"approved": fraud["score"] < 0.5, "estimate": cost, "shop": shop}

All four services — React frontend and FastAPI API (both Web Services), the LiveKit Background Worker, and the Workflows orchestrator — are defined in a single render.yaml Blueprint, so the whole stack deploys together with shared environment variables for the LiveKit and OpenAI keys. That's Render's service-type model in one app: each piece of an AI system runs on the service type that fits it, wired together as code. The rest of this guide breaks those service types down one at a time.

Render Workflows is currently in beta. See the Render Workflows documentation for the full SDK reference.

An MCP server exposes your own tools and data to AI agents — Claude, Cursor, Codex — over the Model Context Protocol. It's a Web Service, the service type that listens for HTTP requests and returns responses. The start command tells Render how to run your application process.

The MCP Server Python template is built on FastMCP and the official MCP Python SDK, with Streamable HTTP transport, a health check, and bearer-token auth already wired up. You declare a tool with a decorator, and Render serves it at a public /mcp endpoint.

python

# server.py
import os
from fastmcp import FastMCP

mcp = FastMCP("my-tools")

@mcp.tool
def add(a: int, b: int) -> int:
    """Add two numbers."""
    return a + b

if __name__ == "__main__":
    mcp.run(transport="http", host="0.0.0.0", port=int(os.environ["PORT"]))

txt

# requirements.txt
fastmcp>=2.0

To deploy this, create a new Web Service, connect your repository, set the build command to pip install -r requirements.txt, and set the start command to python server.py. Render assigns a .onrender.com URL with automatic HTTPS and auto-generates a secure MCP_API_TOKEN so clients authenticate with a bearer token out of the box. This pattern of one file, one start command, and one URL is the foundation for every deployment that follows.

GPT Researcher is an open-source autonomous agent that plans a research task, aggregates 20+ web sources, and writes a cited report — all behind a FastAPI server. Like any agent that calls an LLM and a search API, it needs secrets at runtime. Environment variables are key-value pairs you define in Render's Environment settings, injected into your application's runtime to keep API keys out of your codebase.

python

# main.py (relevant excerpt)
from fastapi import FastAPI
from gpt_researcher import GPTResearcher

app = FastAPI()

@app.get("/research")
async def research(query: str):
    researcher = GPTResearcher(query=query)  # reads OPENAI_API_KEY and
    await researcher.conduct_research()        # TAVILY_API_KEY from the environment
    return {"report": await researcher.write_report()}

The agent reads OPENAI_API_KEY (for the LLM) and TAVILY_API_KEY (for web search) straight from the environment, so you set them once in Render's Environment settings and never commit a key. The build command is pip install -r requirements.txt and the start command is uvicorn main:app --host 0.0.0.0 --port $PORT. GPT Researcher uses Uvicorn, an ASGI server, and requires Python 3.11 or later. The helpful aspect is that the runtime configuration lives in Render, not in your repo, allowing you to rotate a key or point at a self-hosted model by changing an environment variable instead of your application code.

When an agent needs to ground its answers in your own data instead of hallucinating, you reach for retrieval-augmented generation (RAG). That means a vector database — and you can attach a Render Postgres instance with the pgvector extension, automated backups, and a connection string injected as an environment variable.

The Pydantic Agents template is a documentation Q&A assistant built with Pydantic AI for typed agents and tool calls, Logfire for tracing every LLM call, and FastAPI on top of Postgres + pgvector. It runs a seven-stage pipeline with hybrid semantic search and claim verification across thousands of documentation chunks.

python

# agent.py
import os
from pydantic_ai import Agent
from sqlalchemy import create_engine, text

engine = create_engine(os.environ["DATABASE_URL"])
agent = Agent("anthropic:claude-sonnet-4-5", system_prompt="Answer from the docs.")

@agent.tool_plain
def search_docs(query_embedding: list[float], limit: int = 5) -> list[str]:
    with engine.connect() as conn:
        rows = conn.execute(
            text("SELECT content FROM chunks ORDER BY embedding <=> :q LIMIT :k"),
            {"q": str(query_embedding), "k": limit},
        ).fetchall()
    return [r[0] for r in rows]

txt

# requirements.txt
pydantic-ai
logfire
fastapi==0.115.12
uvicorn==0.34.2
psycopg2-binary==2.9.10

When you create a Render Postgres instance, Render exposes both an internal connection URL (for services in the same region) and an external one. You reference it as DATABASE_URL and enable pgvector with CREATE EXTENSION vector. The <=> operator is pgvector's cosine-distance search. The start command is uvicorn main:app --host 0.0.0.0 --port $PORT, and Render provides the $PORT variable automatically (defaulting to 10000). See Render's database connection documentation for connection string formats.

An agent is only as good as the context you feed it, and the open web is messy. The Crawl4AI template is a FastAPI service built on Crawl4AI that crawls any URL, including JavaScript-rendered pages, and returns clean markdown ready to drop into GPT-4, Claude, or any other model. It's a Web Service, but unlike the examples above it ships as a Docker image instead of using Render's native Python runtime, because it bundles a headless Chromium browser via Playwright.

When a service needs system-level dependencies that pip install can't provide, like a browser, native libraries, or specific OS package, you can set its runtime to Docker and Render builds from your Dockerfile. The template's render.yaml does exactly that, so the browser binaries are baked into the image and you never manage them yourself.

yaml

# render.yaml
services:
  - type: web
    name: crawl4ai
    runtime: docker
    dockerfilePath: ./Dockerfile
    healthCheckPath: /health

With a Docker runtime, there's no separate build or start command; instead, your Dockerfile defines both. Render builds the image, runs the container, and serves the REST API (with interactive Swagger docs at /docs) at a .onrender.com URL. Point any of the agents above at it to turn raw URLs into model-ready context. See Render's Docker deployment guide for the full runtime reference.

Using development servers in production. Always use Gunicorn (WSGI) or Uvicorn (ASGI) in your start command.
Hardcoding secrets in source code. Use Render environment variables for API keys, database URLs, and tokens.
Missing the $PORT variable. Your web server must bind to 0.0.0.0:$PORT, not a hardcoded port. The default value of PORT is 10000 for all Render web services.
Forgetting requirements.txt updates. A missing dependency means your application crashes on import.
Choosing the wrong service type. A task queue worker is a Background Worker, not a Web Service. A scheduled script is a Cron Job. Service type determines billing, lifecycle, and networking.

Most of the examples listed here are intentionally minimal so you can lift them into a real project. Start from a Render template, modify the start command, set your environment variables, and push to your connected Git branch. You can use Infrastructure as Code via render.yaml to define multi-service architectures declaratively. The Render free tier supports free instances for Web Services, Render Postgres, and Render Key Value. Free instances are not available for Background Workers or Cron Jobs.

The mental model is the takeaway: code in Git, build command, start command, environment variables. Every Python application you deploy follows this pattern.

5 AI Python apps to deploy on Render

Why Python and Render belong together

The Render deployment mental model

Voice agent with Render Workflows

MCP server in Python

GPT Researcher autonomous agent

Pydantic AI RAG agent

URL-to-markdown scraper with Crawl4AI

Common deployment mistakes to avoid

Adapting these patterns

Frequently asked questions