Deployment And DNS Architecture

This page explains how applications, users, agents, and private network clients reach Gateway in production. It covers DNS, listener placement, private transport, and the relationship between Gateway's data plane and Eden's control plane.

Migration execution is covered by Live Migrations. Use this page to decide where Gateway sits in the network and which names clients should connect to; use the Live Migrations pages for migration phases, validation, rollback, and commit behavior.

Architecture

What DNS Owns

DNS should give clients a stable name for the Gateway entry point. It should not encode migration phases, backend credentials, policy decisions, or cutover state.

The goal is a single client-facing change: applications move from direct backend names to Gateway-managed names, then Gateway can apply endpoint governance, native gateway routing, policy, validation, and migration controls behind that stable name.

Entry Patterns

Deployment Models

Gateway In The Customer VPC

Run Gateway as a VM, container, or Kubernetes service in the same private network as the applications and backends.

This is the default production shape when low latency and private backend reachability matter. Application traffic stays inside the customer network, and backends do not need to become publicly reachable.

Gateway Behind An Internal Load Balancer

Use an internal load balancer when multiple Gateway nodes should share one client-facing name.

Use this shape for high availability, node replacement, rolling upgrades, and endpoint placement across multiple Eden nodes. Keep control-plane storage and endpoint node placement consistent across the fleet.

Sidecar Or Local Listener

Use a sidecar when the application should connect to localhost or when DNS changes are hard to coordinate. This is useful for per-workload placement, development, or tightly controlled environments.

Eden VPN

Use Eden VPN when private users or agents need native protocol access through Gateway without being on the same network as the backend. VPN routes expose selected Gateway listeners, but endpoint RBAC and endpoint-level security remain the final authorization layer.

DNS Configuration

Private A Record

Use an A record when a stable internal IP, internal load balancer address, or Kubernetes service IP is the target.

redis.internal A 10.0.2.100

Private CNAME

Use a CNAME when the client-facing backend name should stay stable while Gateway is addressed through an internal service or load balancer name. This is the common shape when the platform team owns eden-gateway.internal and application teams own service aliases such as redis.internal, claims-db.internal, or warehouse.internal.

redis.internal.      30  IN  CNAME  eve-redis-listener.internal.
claims-db.internal.  30  IN  CNAME  eve-postgres-listener.internal.

The CNAME target should resolve only inside the private network or split-horizon DNS zone. It should point at the Gateway listener, internal load balancer, Kubernetes service, or node address that terminates the governed protocol connection.

eve-redis-listener.internal.     30  IN  A  10.0.2.100
eve-postgres-listener.internal.  30  IN  A  10.0.2.101

After publishing the record, validate both name resolution and protocol reachability from the same network segment as the workload:

dig +short redis.internal
redis-cli -h redis.internal -p 6379 PING

Keep the TTL low during onboarding or rollback rehearsal. Once the traffic path is stable, the CNAME can remain in place while Gateway changes backend routes, endpoint policy, masking, mirror mode, or Live migration state behind the same client-facing name.

Application Configuration

When DNS cannot be changed, update the application target directly:

REDIS_HOST: eden-gateway.internal
REDIS_PORT: 6379

DATABASE_HOST: eve-postgres-listener.internal
DATABASE_PORT: 5432

For sidecars, the target is usually local:

REDIS_HOST: localhost
REDIS_PORT: 6379

DATABASE_HOST: localhost
DATABASE_PORT: 5432

Operational Guidance

• Keep DNS TTLs low during onboarding, rollback rehearsal, or node replacement.
• Confirm endpoint health before moving client traffic to Gateway.
• Grant least-privilege endpoint RBAC before exposing a listener.
• Export telemetry before production rollout.
• Keep rollback paths explicit: DNS rollback for client entry points, Gateway route rollback for gateway-managed routes, and Live Migrations rollback for migration workflows.
• Prefer private DNS and internal load balancers for backend protocol traffic.
• Use separate names for separate operational intent, such as production traffic, validation traffic, and developer access.

Link Graph