zeekayandHanzo AI
ed8108ff64
lux.network is the chain — RPC, blocks, anything a third party could run for themselves. lux.cloud is what we host. The exchange adapter reads the chain and serves derived aggregates, so it is the second kind; api-exchange.lux.network read as protocol infrastructure. The whole host maps to the adapter, deliberately. Hanging it off api.lux.cloud as a path looked tidier, but that host's / already belongs to cloud:8000, so only the enumerated paths would reach the exchange and /v1/quote, /v1/swappable_tokens and the Connect-RPC /data.v1.* routes would answer from the wrong service. One host, one backend, no path list to keep in sync. Testnet and devnet are exchange-test / exchange-dev under the same lux.cloud wildcard, NOT exchange.lux-test.cloud — we do not own that domain, and pointing two networks at a name we cannot serve would have failed as a resolution error with nothing to point at. All three verified live: 200 with real tokens. The old api-exchange.lux.network Ingress stays until the built app stops asking for it. It was hand-applied and never declared here; only its /proxy/ IngressRoute was. Co-authored-by: Hanzo Dev <[email protected]>
25 lines
564 B
YAML
25 lines
564 B
YAML
apiVersion: networking.k8s.io/v1
|
|
kind: Ingress
|
|
metadata:
|
|
name: exchange-dev-lux-cloud
|
|
namespace: lux-devnet
|
|
annotations:
|
|
cert-manager.io/cluster-issuer: letsencrypt-prod
|
|
spec:
|
|
ingressClassName: ingress
|
|
rules:
|
|
- host: exchange-dev.lux.cloud
|
|
http:
|
|
paths:
|
|
- path: /
|
|
pathType: Prefix
|
|
backend:
|
|
service:
|
|
name: exchange-api
|
|
port:
|
|
number: 4000
|
|
tls:
|
|
- hosts:
|
|
- exchange-dev.lux.cloud
|
|
secretName: exchange-dev-lux-cloud-tls
|