Deployment Acceptance Criteria: Required Healthy Services, Required Accessible Interfaces, and License Status Confirmation Items

During partner delivery, deployment completion does not equal acceptance completion. Acceptance criteria must answer three questions: Are all services alive? Are critical paths accessible? Is the License in a valid state?

Although public sources do not directly provide a “partner acceptance checklist template,” the Enterprise official documentation is sufficient to support the minimum acceptance framework: first, the official documentation publicly lists core resource and domain requirements; second, it specifies several key entry points that should be accessible after deployment; third, it states that the License status must be verified after activation and refresh. Therefore, this can be written as “minimum acceptance criteria confirmable from public sources.”

1. Acceptance Framework Confirmed by Public Sources

1. Service Accessibility Is Itself an Acceptance Item

The Enterprise documentation explicitly requires configuring domains for console, api, app, upload, enterprise, trigger, and others, stating that these entry points should be accessible after deployment. Therefore, domain and entry point reachability should be considered the first layer of acceptance.

2. Resource and Dependency Status Should Be Included in Acceptance

The Resources Checklist publicly lists dependencies including PostgreSQL, Redis, vector database, and object storage. Therefore, acceptance should not only check whether the UI page opens but also confirm that these dependencies are in a normal working state.

3. License Activation Status Must Be Confirmed Separately

The official License documentation explicitly states that a restart of the enterprise service is required after activation or refresh. Therefore, a License is not “done once entered” – its status must be verified as truly active.

2. Service Health Items

At minimum, confirm:

Web / API / Worker / Enterprise are normal
Database, Redis, object storage, and vector database are normal
Ingress / domain resolution is normal

3. Interface Availability Items

Login is functional
Model invocation is functional
Knowledge base upload is functional
Published application API is callable

4. License Confirmation Items

Status is valid
Active version is correct
Status persists after restart

No particularly strong direct matches on note.com at this time. Enterprise official deployment and License documentation is the more appropriate basis.

zenn.dev / Official Documentation / Other Public Pages

Kubernetes - Dify Enterprise Docs | https://enterprise-docs.dify.ai/en-us/deployment/prerequisites/kubernetes
Deployment FAQ - Dify Enterprise Docs | https://enterprise-docs.dify.ai/en-us/deployment/faq/deploying
Resources Checklist - Dify Enterprise Docs | https://enterprise-docs.dify.ai/versions/3-7-x/en-us/deployment/resources-checklist
License Activation - Dify Enterprise Docs | https://enterprise-docs.dify.ai/versions/3-0-x/en-us/deployment/license-activation

Confirmed Information from Public Sources

Domain / entry point reachability, dependency resource health, and License activation form the minimum acceptance framework
Public sources are sufficient to support “minimum acceptance criteria” but do not include your internal customer project-specific acceptance form formats

MKC — Dify Japan Content System