Server & Environment Inventory¶
Use this page before any infrastructure, deployment, rollback, or troubleshooting operation. It tells you where a command is allowed to run and which layer owns each resource.
Environment matrix¶
This table describes the configured/intended topology as defined by the Terraform code and Helm values in this repository - not confirmed running infrastructure. Dev/staging/production Hetzner resources have not been verified as live/reachable from this repository; do not assume a row exists as real infrastructure until you have confirmed it directly (
terraform plan/state showagainst the real backend, or a reachablekubectl/helmcontext). In particular, AkshayaBazaar's own public domain has not been registered yet, so thestaging/productionrows below are currently not deployable to a real, reachable hostname - see Deployment → Staging "Deployment is currently blocked".
| Environment | Compute | Data | Kubernetes namespace | Helm values | Terraform directory | Deployment owner |
|---|---|---|---|---|---|---|
| local | Developer workstation / Docker Desktop | Local MySQL + Redis | local k3d cluster (staging namespace) |
helm/akshayabazaar/values-local-staging.yaml |
none | Developer |
| dev | Shared Hetzner platform node | Dev data VM when provisioned | akshayabazaar-dev |
values-dev.yaml |
terraform/environments/dev/ |
CI/Jenkins |
| staging | Shared Hetzner K3s platform node | Dedicated staging data VM | akshayabazaar-staging |
values-staging.yaml |
terraform/environments/staging/ |
CI/Jenkins |
| production | Shared Hetzner K3s platform node | Dedicated production data VM | akshayabazaar-production |
values-production.yaml |
terraform/environments/production/ |
Approved production deployment |
The K3s platform node is shared by staging and production, while data VMs, Kubernetes namespaces, secrets, R2 buckets, and environment configuration stay separate - once actually provisioned.
Private network allocation¶
The current Terraform topology documents these private-network roles:
Do not place credentials, public IP addresses, SSH private keys, or database passwords in this page. Obtain live addresses from Terraform output, the Hetzner console, approved inventory, or the target environment's secure configuration at execution time.
Pre-flight identification¶
Before running a mutating command, record these five values in your change ticket or terminal notes:
Repository: <repo>
Git ref: <branch/tag/commit>
Environment: <local|dev|staging|production>
K8s namespace: <namespace or N/A>
Terraform stack: <directory or N/A>
Then verify the active context.
Kubernetes¶
Terraform¶
terraform plan is the mandatory review point. Never move from a plan produced for one environment to an apply in another directory.
Docker / local¶
Environment separation rules¶
- Local is never treated as production-like simply because it uses a
stagingnamespace internally. - Staging and production must use separate Helm values and namespaces.
- Production data credentials are never copied into staging/local configuration.
- Cloudflare zone-wide settings are owned by the production Terraform stack; changing them may affect more than one hostname.
- Terraform state and variables are environment-specific; do not reuse a production plan file in staging or vice versa.
- A rollback must target the same environment and namespace as the failed deployment.
Server access checklist¶
Before SSH or remote administration:
- Confirm the target resource from Terraform output or Hetzner inventory.
- Confirm you are using the expected SSH identity from the workstation/secret manager.
- Prefer read-only checks first (
uptime,df -h,systemctl status,kubectl get). - Capture current application/image versions before changing anything.
- Never paste private keys, passwords, tokens, or full connection strings into tickets, chat, screenshots, or this portal.