IaC: prediction-assistant
Infrastructure as Code: kalshi-assistant
How infrastructure is provisioned for the kalshi-assistant service. OpenTofu (Terraform) modules in pal-e-services onboard each new service, while pal-e-platform manages shared platform resources like DNS.
Diagram
Components
| Component | Purpose | Notes |
|---|---|---|
| k3s.tfvars | Declares kalshi-assistant as a service entry | Single source of truth for namespace name, Harbor project, ArgoCD app name, funnel hostname |
| namespace module | Creates k8s namespace | Idempotent; includes resource quotas and labels |
| harbor-robot module | Creates Harbor robot account and k8s pull secret | Scoped to the service's Harbor project; secret placed in namespace |
| argocd-app module | Registers ArgoCD Application CR | Points at pal-e-deployments repo path for this service |
| tailscale-funnel module | Provisions Tailscale funnel for HTTPS ingress | Maps public hostname to internal k8s service |
| godaddy-dns module | Manages DNS records via GoDaddy API | Lives in pal-e-platform; CNAME or A records pointing to Tailscale funnel |
Key Decisions
- OpenTofu over raw kubectl: Declarative state management prevents drift and enables reproducible onboarding. Every new service follows the same module pattern.
- Split repos (services vs platform): pal-e-services handles per-service resources; pal-e-platform handles shared infra (DNS, monitoring). Separation of concerns keeps blast radius small.
- tfvars-driven onboarding: Adding a new service means adding an entry to k3s.tfvars rather than writing new Terraform. This keeps onboarding fast and consistent.
- GoDaddy DNS via Terraform: DNS is managed as code alongside infrastructure, not manually in a web console. Changes are auditable in git.