Dependency graph

Every certificate participates in a web of upstream and downstream relationships: ACME account → cert, zone → cert, cert → distributions → targets. The dependency graph visualizes that web and — more practically — powers the safety checks that refuse destructive operations when something downstream still relies on the target.

01Upstream (what the cert depends on)

• Issuer — one ACME account or one MSCA connection + template.
• DNS zones — every identifier on the cert resolves to a registered zone → DNS credential.
• Project variables referenced by attached distributions' path / action / target templates.
• Module credentials used by the attached distributions.
• Certificate policy (if enabled on the project) — not a reference, but an enforcement boundary that shapes what the cert can be.

02Downstream (what depends on the cert)

• Distributions — zero or more, each binding the cert to a module + target/group.
• Targets — the resolved set, via distributions.
• Bulk actions — if the cert is listed in an active bulk-action record, it's a downstream reference until that job completes.
• Approval requests — pending approval requests referencing this cert.

03The graph view

1. Open the certificate detail page.
2. Switch to the Dependencies tab.
3. A directed graph renders: the cert in the centre, upstream nodes on the left (issuer, zones, credentials), downstream on the right (distributions, targets). Edges are labelled with the relationship type.
4. Click any node to navigate to that resource.

04Safety checks

The same graph data drives soft-block safety checks throughout the UI:

• Deleting an ACME account is blocked while any certificate references it.
• Deleting a DNS credential is blocked while any zone references it, which is in turn blocked while any certificate depends on the zone.
• Deleting a target is blocked while any distribution references it.
• Deleting a module credential is blocked while any target references it.
• Deleting a certificate is blocked while any active distribution or bulk action references it.

The block is soft: the UI explains the blocking reference(s) and lets you jump to them. There is no force- delete. If you want to decommission an upstream resource, repoint the dependants first.

05Query via API

The graph is exposed as a single endpoint per resource:

GET /api/v1/projects/{projectId}/certificates/{id}/dependencies
GET /api/v1/projects/{projectId}/acme-accounts/{id}/dependencies
GET /api/v1/projects/{projectId}/targets/{id}/dependencies

Returns an adjacency list:

{
  "upstream": [
    {"type":"acme_account", "id":"...", "name":"letsencrypt-prod", "relation":"issuer"},
    {"type":"zone",          "id":"...", "name":"example.com",      "relation":"identifier_zone"}
  ],
  "downstream": [
    {"type":"distribution", "id":"...", "name":"web-fleet-ssh", "relation":"binds"}
  ]
}

06Common graph shapes

• Orphan cert: issuer + zones upstream, no distributions downstream. Surfaces as an attention signal in risk scoring.
• Shared target: one target referenced by many distributions (many certs land on one host). Deleting the target refuses until all are repointed.
• Multi-module cert: one cert with SSH + Kubernetes + Vault distributions — three downstream edges, three separate rollback stories.

07Troubleshooting

"Cannot delete — N references"

Open the dependency panel, click each blocking reference, repoint or delete. Once every reference is cleared, the delete succeeds.

Graph shows a reference that should be gone

Dependencies are computed on-read from current DB state — stale references come from real data. Check the named resource directly; often a soft-deleted record still carries the reference. Contact support with the resource IDs if the graph shows something the source-of-truth doesn't.