DeployAngel MCP server

DeployAngel for Python

<!-- mcp-name: com.deployangel/deployangel --> <!-- mcp-name: io.github.DeployAngel/deployangel -->

The DeployAngel agent for Django, FastAPI, Starlette, and Flask, with Celery and RQ jobs. It watches what your app does in production and reports one small aggregated payload per process per minute. DeployAngel uses that to verify every deployment, and to tell you (or your coding agent) when a release is cleared and you can stop watching it.

Install

Requires Python 3.10 or later. The package has no dependencies of its own.

pip install deployangel

Set this in production, for every process (web servers and job workers alike):

DEPLOYANGEL_TOKEN=da_live_...           # an ingestion token with the telemetry scope

On Heroku, the DeployAngel add-on sets it for you.

Django

Supports Django 4.2 or later.

# settings.py
INSTALLED_APPS = [
    # ...
    "deployangel.django",
]

That's all. The app puts DeployAngel's middleware at the top of MIDDLEWARE (list it yourself to place it), records requests under WSGI and ASGI, and instruments Celery when it's installed. Reporting is on when DEBUG is off.

FastAPI and Starlette

Supports FastAPI 0.100 and Starlette 0.27 or later.

import deployangel.fastapi

app = FastAPI()
deployangel.fastapi.init(app)      # deployangel.starlette.init(app) for Starlette

Call it where the app is created, before it serves requests.

Flask

Supports Flask 2.3 or later.

import deployangel.flask

app = Flask(__name__)
deployangel.flask.init_app(app)

Celery

Supports Celery 5.3 or later. In Django it's automatic. Elsewhere, call init where the Celery app is created, so worker processes start the agent:

import deployangel.celery

app = Celery("shop")
deployangel.celery.init(app)

RQ

Supports RQ 1.16 or later. Run workers with DeployAngel's worker class:

rq worker -w deployangel.rq.Worker               # or deployangel.rq.SimpleWorker
python manage.py rqworker --worker-class deployangel.rq.Worker   # django-rq

RQ runs each job in a forked process that exits as soon as the job ends, so the worker records each job after it finishes, from what RQ saved in Redis. That includes a failed job's traceback, but not the exception of an attempt RQ retries.

Which release is running

The agent must know which release it's running. It finds it in this order:

Shortened. The full README is on GitHub.