Skip to main content
Version: Current

AWS EKS Deployment Verification

Complete these checks in Staging before promoting a release. Record the account, cluster, namespace, release, chart/image versions, results, and acceptance owner. Use the same environment variables as the installation guide:

NAMESPACE="aicc-staging"
RELEASE="aicc"
VALUES="values-staging.yaml"
kubectl config current-context
./scripts/aicc-eks.sh status --namespace "$NAMESPACE" --release "$RELEASE"
kubectl -n "$NAMESPACE" get pods -l "app.kubernetes.io/instance=$RELEASE"
kubectl -n "$NAMESPACE" get pvc
kubectl -n "$NAMESPACE" get ingress "$RELEASE"
kubectl -n "$NAMESPACE" get events --sort-by=.lastTimestamp

Infrastructure and release​

CheckAcceptance
ArtifactsSix application images, Redis, and matching OCI chart exist in customer ECR; image scanning is approved
DeploymentsReady replicas match desired replicas; Pods are Running and Ready, without persistent restart loops
Persistent volumeShared PVC is Bound, uses the intended EFS class, and has ReadWriteMany access
IngressALB address exists; certificate, DNS, access scheme, security groups, and HTTPS hostname are correct
DependenciesRequired databases, Redis, optional ingestion stores, and external services are reachable
IsolationEnvironment values, keys, databases, namespaces, and storage paths are independent

The status command is diagnostic: its successful exit does not certify Pod readiness, HTTPS reachability, or application setup. Inspect READY/WANTED counts, readiness columns, events, and the response actually reported.

Application acceptance​

TestAcceptance
First-run setupDatabase/schema initialization and first administrator setup complete; license is activated
Sign-inAdministrator can reach the dashboard through the HTTPS hostname
Representative executionAn agreed agent completes with expected results and execution history
Background workScheduling and worker processing function without stalled executions
Real-time communicationSignalR WebSocket connection and updates operate through ingress
UploadAn approved 500 MB test file uploads successfully through the complete ingress path
Optional ingestionIngestion and its PostgreSQL, Qdrant, and Neo4j connections work
Optional voiceBrowser microphone works over HTTPS and a two-way call succeeds through the configured TURN relay
Optional integrations/archivalConfigured external integrations and archival policies operate as intended

Use test data and an agreed upload destination. The 500 MB test is an acceptance check, not proof that every file type or the application's full 1 GB upload limit has been validated. Test the required workload limits separately.

API /health/live and frontend /index.html support monitoring. Liveness alone does not validate database configuration or business execution. Before setup completes, /api/setup/status may return HTTP 400; establish initialization state using the setup wizard.

Persistence and recovery​

In Staging, save an identifiable, non-sensitive application setting, restart the API, and verify that it survives:

kubectl -n "$NAMESPACE" rollout restart deployment/"$RELEASE-api"
kubectl -n "$NAMESPACE" rollout status deployment/"$RELEASE-api" --timeout=15m

Confirm that the same configuration survives Pod recreation and the tested upgrade. Validate shared access across the intended node placement. Do not restart Production workloads merely to complete this example without an agreed maintenance window.

Create the configuration backup and separately verify database, required EFS paths, S3 where used, and matching master-key backups outside the cluster. Test restoration and record achieved recovery objectives. Complete the Enterprise Operations acceptance criteria.

Promotion​

Promote the approved artifacts with Production-specific configuration, complete setup and licensing, and repeat applicable acceptance checks. Retain evidence before making Production available. Use Troubleshooting for failed checks; do not bypass a failed prerequisite merely to finish installation.