Deployments

Open /app/deployments to see releases your pipeline reported: status, commit, environment, and timestamps from the provider — never invented. Until the first report arrives, the page stays empty on purpose.

Deployment Intelligence is included on Pro and above. Reporting via POST /api/v1/deployments also requires API access (Enterprise) or your workspace's configured project secret key for CI hooks.

From an empty Deployments page to your first observed release. Report success only when the hosting provider marks the production deployment ready — a green build alone is not enough.

1. 1

   Step 1: Open Deployments

   Choose Deployments in the sidebar. Until CI reports a release the explorer stays empty — same pattern as Logs: toolbar on top, bordered list below, no sample rows.

   

2. 2

   Step 2: Understand how reporting works

   A deployment is recorded only after the hosting provider reports a final state. Mydle's own production pipeline reports Vercel Ready / Error / Canceled via CI. Other workspaces use the Reporting API (or a project-key CI hook) the same way.

   

   In the product open Deployments → Sources in the toolbar for the same screen. Pointing a provider webhook (for example a Vercel webhook) directly at Mydle is not supported.

3. 3

   Step 3: Create an API key (self-serve CI)

   For your own pipelines, open Settings → API and create a Read & write project secret key (sk_live_…). Store it as a CI secret — never in the browser.

4. 4

   Step 4: Report a finished deployment

   After the host confirms the release, send a JSON POST. Use the provider's deployment ID as externalId so retries are recorded once; a redeploy of the same commit needs a new ID.

   curl -X POST https://www.mydle.app/api/v1/deployments \
     -H "Authorization: Bearer $MYDLE_PROJECT_SECRET_KEY" \
     -H "Content-Type: application/json" \
     -d '{
       "title": "Production deploy",
       "status": "succeeded",
       "externalId": "dpl_01example",
       "gitSha": "3d12110abcdef",
       "branch": "main",
       "environment": "production",
       "environmentKind": "production"
     }'

   Provider hooks also accept POST /api/deployments/hooks/<provider> with the same project secret key (Bearer). See the repository npm run deploy:prod flow for how Mydle reports its own Vercel production deploys.

5. 5

   Step 5: See the release in Deployments

   Refresh /app/deployments. The release appears with status, commit, and timestamps from the report. Open a row for release health and related evidence when those signals exist.

Deployments are reported from your CI after the hosting provider confirms the final state. Report success only when the provider marks the production deployment ready — a passing build or workflow is not a production deployment.

Pointing a provider webhook (for example a Vercel webhook) directly at Mydle is not supported. Dedicated provider integrations and self-serve reporting outside the Reporting API are not available yet.

On plans with API access (Enterprise), POST /api/v1/deployments with a Read & write API key from Settings → API (Authorization: Bearer …). The key decides the workspace. Body fields:

• title, status (succeeded, failed, cancelled, …)
• externalId — the provider's deployment ID. Reporting the same ID again returns the existing record; a redeploy of the same commit has a new ID and a separate record.
• projectId (must belong to the key's workspace), gitSha, branch, version, environment, environmentKind, startedAt, finishedAt, buildUrl

Missing fields show as em dashes — Mydle never fabricates commits or timestamps.

For Vercel, trigger a job on GitHub's deployment_status event, read the deployment from the Vercel API, and report only terminal states (Ready → succeeded, Error → failed, Canceled → cancelled). Do not report from the build workflow's own result.

Report from a job that runs after the deployment step and only once the target confirms the release, using the same API and API key.

Any provider works through the Reporting API. Send at least a title and ideally status, gitSha, and externalId.

When a provider marks a deploy as rollback (isRollback or status rolled_back), the release page shows previous deployment linkage and post-window evidence. Recovered alerts or fewer trace errors appear only if observed after the rollback — otherwise Unknown.

Detail pages soft-compose Related Resources: browser sessions, logs, traces, alerts, incidents, API requests, and audit events in the project / post-deploy window when IDs or time links exist. Empty sections stay hidden.

For two hours after a deploy, health checks use the deployment's project only: monitors (via open alerts in-window), browser session errors, trace errors (share of errored or timed-out traces), incidents, and alerts. Pass / fail / unknown only — no composite score, and no claim that the deploy caused a result. Deployments without a project stay Unknown, and a check whose query fails says so instead of passing. Results are provisional until the window closes.

Compose-only on existing Monitoring, Browser, Logs, Tracing, Incidents, Alerts, AI, Billing, and Auth engines. Storage lives in deployment tables; overview and detail UIs are thin composers. See docs/architecture/deployments.md in the repository for the canonical model.