deployangel 0.1.0__tar.gz

deployangel-0.1.0/.github/workflows/ci.yml

@@ -0,0 +1,80 @@
+name: CI
+
+on:
+  pull_request:
+  push:
+    branches: [ main ]
+
+jobs:
+  # The agent supports Python 3.10 and each framework's oldest listed version
+  # or later, so it runs on the oldest and newest of each.
+  test:
+    name: Python ${{ matrix.python }}, ${{ matrix.name }}
+    runs-on: ubuntu-latest
+    strategy:
+      fail-fast: false
+      matrix:
+        include:
+          - python: "3.10"
+            name: oldest frameworks
+            packages: >-
+              django==4.2.* djangorestframework==3.14.* django-celery-beat==2.5.*
+              fastapi==0.100.* flask==2.3.* celery==5.3.* rq==1.16.* "httpx<0.28" "pytest-asyncio<1"
+          - python: "3.12"
+            name: current LTS releases
+            packages: >-
+              django==5.2.* djangorestframework django-celery-beat
+              fastapi flask celery rq httpx pytest-asyncio
+          - python: "3.14"
+            name: newest frameworks
+            packages: >-
+              django djangorestframework django-celery-beat
+              fastapi flask celery rq httpx pytest-asyncio
+    services:
+      redis:
+        image: redis:7
+        ports: [ "6379:6379" ]
+    env:
+      RQ_REDIS_URL: redis://localhost:6379/15
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v7
+
+      - name: Set up Python
+        uses: actions/setup-python@v6
+        with:
+          python-version: ${{ matrix.python }}
+
+      - name: Install
+        run: pip install -e . ${{ matrix.packages }} fakeredis redis pytest
+
+      - name: Run tests
+        run: pytest
+
+      - name: Check overhead
+        run: python bench/overhead.py
+
+  # The agent itself imports nothing outside the standard library.
+  no-frameworks:
+    name: Without any framework installed
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v7
+      - uses: actions/setup-python@v6
+        with:
+          python-version: "3.10"
+      - run: pip install -e . pytest
+      - run: pytest tests/test_core.py tests/test_agent.py
+
+  package:
+    name: Build the package
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v7
+      - uses: actions/setup-python@v6
+        with:
+          python-version: "3.14"
+      - run: pip install build twine
+      - run: python -m build
+      - run: twine check --strict dist/*

deployangel-0.1.0/.github/workflows/release.yml

@@ -0,0 +1,110 @@
+name: Release
+
+# Pushing a version tag (v0.1.0) builds the package, publishes it to PyPI
+# once a maintainer approves the pypi environment, and then creates a GitHub
+# release whose notes are that version's section of CHANGELOG.md.
+#
+# PyPI trusts this workflow directly (trusted publishing), so there's no API
+# token anywhere: PyPI's publisher for the deployangel project names this
+# repository, release.yml, and the pypi environment.
+on:
+  push:
+    tags: [ "v*" ]
+
+permissions:
+  contents: read
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v7
+
+      - name: Set up Python
+        uses: actions/setup-python@v6
+        with:
+          python-version: "3.14"
+
+      - name: Check the tag, version, and CHANGELOG agree
+        env:
+          TAG: ${{ github.ref_name }}
+        run: |
+          version=$(sed -n 's/^VERSION = "\(.*\)"$/\1/p' src/deployangel/version.py)
+          if [ "v$version" != "$TAG" ]; then
+            echo "::error::Tag $TAG doesn't match version $version in src/deployangel/version.py."
+            exit 1
+          fi
+          if ! grep -q "^## $version " CHANGELOG.md; then
+            echo "::error::CHANGELOG.md has no section for $version."
+            exit 1
+          fi
+
+      - name: Build
+        run: |
+          pip install build twine
+          python -m build
+          twine check --strict dist/*
+
+      - uses: actions/upload-artifact@v7
+        with:
+          name: dist
+          path: dist/
+
+  publish:
+    needs: build
+    runs-on: ubuntu-latest
+    environment:
+      name: pypi
+      url: https://pypi.org/project/deployangel/
+    permissions:
+      id-token: write
+    steps:
+      - uses: actions/download-artifact@v8
+        with:
+          name: dist
+          path: dist/
+
+      - name: Publish to PyPI
+        uses: pypa/gh-action-pypi-publish@release/v1
+
+  release:
+    needs: publish
+    runs-on: ubuntu-latest
+    permissions:
+      contents: write
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v7
+
+      - uses: actions/download-artifact@v8
+        with:
+          name: dist
+          path: dist/
+
+      - name: Create release from CHANGELOG.md
+        env:
+          GH_TOKEN: ${{ github.token }}
+          TAG: ${{ github.ref_name }}
+        run: |
+          version="${TAG#v}"
+
+          if gh release view "$TAG" > /dev/null 2>&1; then
+            echo "A release for $TAG already exists."
+            exit 0
+          fi
+
+          # The lines under "## <version> (date)", up to the next heading,
+          # without leading or trailing blank lines.
+          awk -v v="$version" '
+            index($0, "## " v " ") == 1 { found = 1; next }
+            found && /^## / { exit }
+            found { lines[++n] = $0 }
+            END {
+              first = 1; while (first <= n && lines[first] == "") first++
+              last = n;  while (last >= first && lines[last] == "") last--
+              for (i = first; i <= last; i++) print lines[i]
+            }
+          ' CHANGELOG.md > notes.md
+
+          gh release create "$TAG" dist/* --title "deployangel (Python) $version" --notes-file notes.md

deployangel-0.1.0/.gitignore

@@ -0,0 +1,7 @@
+.venv/
+__pycache__/
+*.pyc
+*.egg-info/
+dist/
+build/
+.pytest_cache/

deployangel-0.1.0/AGENTS.md

@@ -0,0 +1,60 @@
+# DeployAngel agent for Python: working rules
+
+The `deployangel` package runs inside customers' production Python apps.
+These rules come before any feature.
+
+## Never harm the customer's app
+
+- No DeployAngel network calls during a request or job. Payloads go out from a
+  background thread, once a minute, with short timeouts.
+- Fail open: every public function catches its own errors. Nothing may raise
+  into, or block, the app.
+- Keep buffers bounded, and drop telemetry rather than block or fail.
+- Keep overhead very low: around 1% CPU or less, where practical
+  (`python bench/overhead.py`).
+- If DeployAngel is down, the customer's app must not notice.
+- No runtime dependencies: the standard library only. Framework imports stay
+  inside their integration module.
+
+## Send aggregates, never events
+
+- One payload per process per minute, whatever the traffic.
+- Only mergeable values: counts and histograms. Never percentiles or rates;
+  the cloud computes those after merging processes.
+- Bound every list in a payload (routes, exceptions, jobs, checkpoints).
+
+## Send as little as possible
+
+Never collect request bodies, parameters, cookies, authorization headers,
+session contents, SQL parameters, email addresses, other personal data, or raw
+logs. Record route patterns (`/users/<int:pk>/`), never raw paths, and
+sanitize exception messages. If a change would add a line to the README's
+"What it sends" section, that's a decision for the maintainer, not an
+implementation detail.
+
+## Keep the protocol framework-neutral
+
+The Agent Protocol speaks in HTTP, routes, exceptions, jobs, queues, and
+scheduled tasks, never in Django views, Celery tasks, or Flask blueprints. The
+integrations (`deployangel/django/`, `asgi.py`, `flask.py`, `celery.py`,
+`rq.py`) translate their framework into those concepts, and the Ruby agent
+speaks the same protocol. Protocol changes must work for both, and the
+DeployAngel cloud has to accept them first.
+
+## Compatibility and tests
+
+- Supports Python 3.10, Django 4.2, FastAPI 0.100, Starlette 0.27, Flask 2.3,
+  Celery 5.3, and RQ 1.16, or later. CI runs the oldest and newest of each
+  (`.github/workflows/ci.yml`), so don't use newer APIs without a fallback.
+- `pytest` must pass. Test the failure paths too: network errors, timeouts,
+  full buffers, and forks.
+- Update the README and CHANGELOG when what the agent sends, or how it's
+  configured, changes.
+
+## Releasing
+
+Bump `src/deployangel/version.py`, rename the CHANGELOG's "Unreleased"
+heading to `## X.Y.Z (date)`, commit "Release X.Y.Z", and push a `vX.Y.Z`
+tag. `.github/workflows/release.yml` builds the package, waits for a
+maintainer to approve the `pypi` environment, publishes to PyPI through
+trusted publishing (no API token), and then creates the GitHub release.

deployangel-0.1.0/CHANGELOG.md

@@ -0,0 +1,18 @@
+# Changelog
+
+## 0.1.0 (2026-10-06)
+
+- First release: the DeployAngel agent for Python, speaking Agent Protocol v1.
+- Django 4.2+ (WSGI and ASGI), FastAPI 0.100+, Starlette 0.27+, and Flask 2.3+:
+  requests by matched route pattern, status codes, latency histograms, and
+  unhandled exceptions; the route table with each view's file.
+- Celery 5.3+: every task attempt, retries and failures, queue latency, task
+  files, and Celery Beat schedules, from settings and from django-celery-beat.
+- RQ 1.16+: `deployangel.rq.Worker` and `SimpleWorker` record every job,
+  including failures from RQ's forked work horses.
+- Checkpoints (`deployangel.checkpoint`), handled exceptions
+  (`deployangel.notify`), critical flows, ignored routes, and turning
+  exception messages off.
+- Release identity from the same sources as the Ruby agent: configuration,
+  Heroku dyno metadata, Kamal, Render, Fly.io, Railway, Coolify, Dokku, a
+  `REVISION` file, and ECS.

deployangel-0.1.0/LICENSE.txt

@@ -0,0 +1,21 @@
+The MIT License (MIT)
+
+Copyright (c) 2026 Jordan Owens
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+THE SOFTWARE.

deployangel-0.1.0/PKG-INFO

@@ -0,0 +1,343 @@
+Metadata-Version: 2.5
+Name: deployangel
+Version: 0.1.0
+Summary: DeployAngel agent for Django, FastAPI, and Flask: verifies every deploy from aggregated HTTP, job, and exception telemetry, including Celery and RQ jobs and Celery Beat schedules.
+Project-URL: Homepage, https://deployangel.com
+Project-URL: Source, https://github.com/DeployAngel/deployangel-python
+Project-URL: Changelog, https://github.com/DeployAngel/deployangel-python/blob/main/CHANGELOG.md
+Author-email: Jordan Owens <jordan@deployangel.com>
+License-Expression: MIT
+License-File: LICENSE.txt
+Keywords: celery,deployment,django,fastapi,flask,monitoring,verification
+Classifier: Development Status :: 4 - Beta
+Classifier: Framework :: Celery
+Classifier: Framework :: Django
+Classifier: Framework :: FastAPI
+Classifier: Framework :: Flask
+Classifier: Intended Audience :: Developers
+Classifier: Programming Language :: Python :: 3
+Classifier: Topic :: System :: Monitoring
+Requires-Python: >=3.10
+Provides-Extra: celery
+Requires-Dist: celery>=5.3; extra == 'celery'
+Provides-Extra: django
+Requires-Dist: django>=4.2; extra == 'django'
+Provides-Extra: fastapi
+Requires-Dist: fastapi>=0.100; extra == 'fastapi'
+Provides-Extra: flask
+Requires-Dist: flask>=2.3; extra == 'flask'
+Provides-Extra: rq
+Requires-Dist: rq>=1.16; extra == 'rq'
+Provides-Extra: starlette
+Requires-Dist: starlette>=0.27; extra == 'starlette'
+Description-Content-Type: text/markdown
+
+# DeployAngel for Python
+
+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.
+
+```bash
+pip install deployangel
+```
+
+Set this in production, for every process (web servers and job workers alike):
+
+```bash
+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.
+
+```python
+# 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.
+
+```python
+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.
+
+```python
+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:
+
+```python
+import deployangel.celery
+
+app = Celery("shop")
+deployangel.celery.init(app)
+```
+
+### RQ
+
+Supports RQ 1.16 or later. Run workers with DeployAngel's worker class:
+
+```bash
+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:
+
+1. `DEPLOYANGEL_REVISION` (the commit SHA) and `DEPLOYANGEL_RELEASE_VERSION`, if you set them
+2. Heroku dyno metadata. Enable it with `heroku labs:enable runtime-dyno-metadata`
+   and `heroku labs:enable runtime-dyno-build-metadata`; both take effect on the
+   next deploy
+3. Kamal: `KAMAL_VERSION`
+4. Render: `RENDER_GIT_COMMIT`
+5. Fly.io: the deploy's image tag, from `FLY_IMAGE_REF`. Fly.io sets no commit, so
+   pass one in for commit-level change tracking (`ENV DEPLOYANGEL_REVISION=$GIT_SHA`
+   in the Dockerfile, with `--build-arg GIT_SHA=$(git rev-parse HEAD)`)
+6. Railway: `RAILWAY_GIT_COMMIT_SHA`, or `RAILWAY_DEPLOYMENT_ID`
+7. Coolify: `SOURCE_COMMIT`. Dokku: `GIT_REV`
+8. a `REVISION` file in the app's root
+9. ECS, including Fargate: the container's image, from the metadata endpoint ECS
+   provides (one local request at boot)
+
+For other Docker deploys, bake the commit into the image with
+`ARG GIT_SHA` and `ENV DEPLOYANGEL_REVISION=$GIT_SHA`. On DigitalOcean App
+Platform, set `DEPLOYANGEL_REVISION: ${_self.COMMIT_HASH}` in the app spec.
+
+## What it sends
+
+- HTTP request counts, 4xx/5xx counts by status code, unhandled exceptions,
+  and a latency histogram, both per app and per route.
+- Routes are recorded as the pattern the framework matched
+  (`GET /users/<int:pk>/`, `GET /items/{item_id}`), never the raw path. At
+  most 100 routes are sent per payload; the rest are folded into `__other__`.
+- Background jobs: attempts, failed attempts, discarded jobs, duration, and
+  queue latency, per task. For queue latency, Celery task messages carry one
+  extra header, `deployangel_published_at`, the time they were sent.
+- Release identity, runtime versions, and a per-process instance ID.
+- Exceptions: a stable fingerprint, the exception class, the first line of the
+  message, and application frames only (file paths and function names). In
+  the message, numbers, IDs, emails, UUIDs, long hex strings, quoted values,
+  and the request's host are replaced with placeholders. Other words are kept:
+  `Payment failed for Jane Doe` is sent as it is. If your app's messages might
+  hold personal or health data, [turn messages off](#exception-messages).
+- Once per process: the route table (with each view's module and file), task
+  names and files, recurring schedules declared for Celery Beat (in settings
+  or in django-celery-beat's tables), critical flows, and file digests
+  (relative paths and hashes, never file contents) so DeployAngel can tell
+  which routes changed in a release. Disable digests with
+  `DEPLOYANGEL_FILE_DIGESTS=false`.
+
+It does not send request bodies, parameters, headers, cookies, SQL, logs, or
+user data.
+
+## Data and pricing
+
+- Everything goes to DeployAngel's hosted service, which runs on DigitalOcean
+  in the United States. There's no self-hosted version, and no choice of
+  region.
+- Telemetry is kept for 21 days, and release history for 7, 30, or 90 days
+  depending on the plan. The [privacy policy](https://deployangel.com/privacy)
+  has the details and the services DeployAngel uses.
+- DeployAngel is free during the beta, with notice before paid plans start.
+  See [pricing](https://deployangel.com/pricing).
+
+## Safety
+
+- Nothing runs on the network during a request or job. Recording only updates
+  in-memory counters.
+- Payloads are sent from a background thread, once a minute, with short
+  timeouts.
+- When DeployAngel is unreachable, the buffer is bounded (10 payloads, kept as
+  gzipped JSON) and the oldest are dropped. Your app is never blocked or failed.
+- Safe across forks (Gunicorn, Celery's prefork pool, uWSGI), and the minute
+  in progress is flushed at shutdown. Under uWSGI, enable threads
+  (`enable-threads = true`).
+
+`python bench/overhead.py` measures this. On an Apple M-series laptop with
+Python 3.14, recording a request adds about 1.7 µs, and with every route, job,
+checkpoint, and exception list at its cap the agent holds about 0.5 MB,
+including 10 unsent minutes.
+
+## Configuration
+
+Environment variables are enough for most apps. In Django, settings go in a
+`DEPLOYANGEL` dict; elsewhere, call `deployangel.configure` before `init`:
+
+```python
+# settings.py
+DEPLOYANGEL = {
+    "environments": ["production", "staging"],   # default: production only
+}
+
+# or anywhere else
+deployangel.configure(environments=["production", "staging"])
+```
+
+The agent reports in the environments listed. Python frameworks don't name an
+environment, so it's `DEPLOYANGEL_ENVIRONMENT` if set, otherwise
+`development` when the framework's debug mode is on and `production` when
+it's off. `DEPLOYANGEL_ENABLED=true|false` forces reporting on or off
+anywhere. `DEPLOYANGEL_URL` overrides the API endpoint (default
+`https://api.deployangel.com`).
+
+File paths are relative to the app's root, the working directory by default
+(on Heroku and in most containers, the repository's root). Set
+`DEPLOYANGEL_ROOT` if your processes start somewhere else.
+
+Critical flows (for example sign-up or password reset) are always listed in
+clearance reports:
+
+```python
+DEPLOYANGEL = {
+    "critical_flows": {"password_reset": ["POST /password-reset/", "job:accounts.tasks.send_reset_email"]},
+}
+```
+
+Health checks aren't recorded: load balancers and uptime monitors call them
+all the time and they always answer fast, so they would make your app look
+busier and healthier than its real pages. The agent recognizes
+django-health-check, django-alive, and django-watchman wherever they're
+mounted, and any route at a conventional path (`/up`, `/health`, `/healthz`,
+`/healthcheck`, `/health_check`, `/livez`, `/readyz`, `/statusz`, `/ping`,
+`/ht`, `/alive`). If yours is somewhere else, list it the way the dashboard
+shows it. HEAD requests to it are left out too:
+
+```python
+DEPLOYANGEL = {"ignored_routes": ["GET /status/"]}
+```
+
+### Exception messages
+
+To send exceptions without any message, only their class, fingerprint, and
+application frames:
+
+```python
+DEPLOYANGEL = {"exception_messages": False}   # or DEPLOYANGEL_EXCEPTION_MESSAGES=false
+```
+
+Grouping, new-exception detection, and verdicts work the same, since the
+fingerprint never uses the message. You lose the message text in the
+dashboard, notifications, and AI investigation.
+
+### Handled exceptions
+
+Exceptions your code catches aren't seen. To report one for context (handled
+exceptions never fail a release):
+
+```python
+try:
+    sync_inventory()
+except UpstreamError as error:
+    deployangel.notify(error)
+```
+
+### Recurring jobs
+
+DeployAngel expects declared recurring tasks on schedule. It reads Celery
+Beat's `beat_schedule` (crontabs, and intervals, which repeat from when Beat
+starts) in the zone Celery uses, and, when `django_celery_beat` is installed,
+its enabled periodic tasks. Solar schedules aren't read, and neither are
+RQ's schedulers, whose jobs live only in Redis. DeployAngel also learns
+recurring jobs from their history.
+
+## Checkpoints
+
+Errors and latency don't catch work that silently stops happening. Count the
+business events that matter with one line:
+
+```python
+deployangel.checkpoint("order.created")
+deployangel.checkpoint("webhook.stripe.processed", count=len(events))
+```
+
+DeployAngel learns each checkpoint's normal rate relative to your traffic and
+fails a release after which it drops sharply or stops, even when every request
+and job still succeeds. Only drops are flagged, and a checkpoint without enough
+traffic never blocks a release from being cleared. Checkpoints can also be part
+of a critical flow (`checkpoint:order.created`).
+
+It's safe to call anywhere: it never raises, never touches the network, and is
+ignored outside reporting environments. Names use letters, numbers, and
+`. _ : -` (up to 100 characters); keep them to a fixed set rather than
+including IDs, since only 100 distinct names are counted per minute.
+
+## Registering deploys
+
+DeployAngel notices a new release when the agent first reports it, and
+verifies it from there, with nothing to set up. On Heroku, the add-on also
+registers every release for you.
+
+To register deploys from CI, which also catches a release that never boots,
+post the commit with an API token created for **CI deploys** in the dashboard:
+
+```bash
+curl -fsS https://api.deployangel.com/api/v1/deployments \
+  -H "Authorization: Bearer $DEPLOYANGEL_API_TOKEN" \
+  -H "Content-Type: application/json" \
+  -d "{\"commit\": \"$GIT_SHA\"}"
+```
+
+The `deployangel` command line tool and MCP server for coding agents
+(`deployangel verify --wait`) ship with the
+[Ruby gem](https://github.com/DeployAngel/deployangel-ruby) for now.
+`gem install deployangel` installs them; they need Ruby, but not Rails or
+your app.
+
+## Development
+
+```bash
+python -m venv .venv
+.venv/bin/pip install -e . django djangorestframework django-celery-beat fastapi httpx flask celery rq fakeredis pytest pytest-asyncio
+.venv/bin/pytest
+```
+
+`RQ_REDIS_URL=redis://localhost:6379/15` also runs RQ's forking worker
+against a real Redis.
+
+The agent speaks DeployAngel Agent Protocol v1: one gzipped JSON payload per
+process per minute to `POST /api/v1/telemetry`, and the application's metadata
+once per process to `POST /api/v1/application_metadata`.
+`src/deployangel/core/protocol.py` and `src/deployangel/metadata.py` build
+them.