Argo CD bootstrap: what installing the chart does, and what it does not

Start with the checked-in evidence

The public EKS repository installs the Argo CD Helm chart from the add-ons Terraform root and configures an internal ALB ingress. The reviewed source does not include an app-of-apps repository or a complete staging-to-production promotion workflow. Those would be additional delivery configuration.

• Document which resources Terraform owns and which Argo CD owns.
• Avoid letting both tools reconcile the same application resources.
• Check the repository contents before describing a bootstrap as complete GitOps delivery.

Resolve access before exposing a dashboard

The example sets server.insecure for the Argo CD server. This needs an explicit TLS termination and authentication design; an internal ingress is not a substitute for either. Review certificate handling, SSO or account permissions, and which network paths can reach the service.

• Verify encryption at the intended boundary and restrict dashboard access.
• Limit repository credentials and deployment permissions to the required scope.
• Confirm that the team can recover access without relying on one person.

Test the failure path as well as the happy path

A useful acceptance test changes one service, observes reconciliation and checks what happens when health checks fail. Decide whether rollback means reverting Git, selecting a previous artifact or following an application-specific recovery procedure. Database changes may need their own plan.

• Use a small staging application with a known healthy revision.
• Observe a failed rollout and verify the documented recovery procedure.
• Record the starting conditions before comparing deployment durations.

A handover your team can use

I would hand over ownership boundaries, the application onboarding procedure and the recovery steps alongside the chart configuration. The repository is evidence of the bootstrap layer, not proof of a particular release frequency or recovery time.

Checks to run in your environment

Read-only checks after installation; application resources appear only after they are configured.

kubectl -n argocd get deployments
kubectl -n argocd get applications

These are suggested verification steps, not a record of a production test run. Check prerequisites and resource access before using them.

Source and references

Project links point to the exact source revision reviewed for this note.

• Argo CD Helm installation at the reviewed commit
• Platform repository architecture
• Argo CD declarative setup documentation