The core issue you're facing is advertised addresses. When Redpanda boots, it needs to tell clients:

1. Internal clients (Console): "I'm at redpanda:9092" (Railway's internal DNS)
2. External clients (Your apps): "I'm at your-domain.railway.app:19092" (Railway's TCP proxy)

This is done via the REDPANDA_ADVERTISED_KAFKA_ADDR variable with dual listeners:

REDPANDA_ADVERTISED_KAFKA_ADDR=internal://redpanda:9092,

external://your-railway-domain.railway.app:19092

Critical Environment Variables for Redpanda

# The bind addresses (what Redpanda listens on) REDPANDA_KAFKA_ADDR=0.0.0.0:9092 REDPANDA_ADVERTISED_KAFKA_ADDR=internal://redpanda:9092,external://your-railway-domain.railway.app:19092

# Broker-to-broker communication REDPANDA_RPC_ADDR=0.0.0.0:33145 REDPANDA_ADVERTISED_RPC_ADDR=redpanda:33145

# Single-node tuning REDPANDA_SMP=1 REDPANDA_MEMORY=512M REDPANDA_RESERVE_MEMORY=205M

Console Configuration (Simple)

Console just needs to know the internal address:

KAFKA_BROKERS=redpanda:9092 PORT=8080

That's it—Railway's internal networking handles DNS resolution automatically.

Deployment Workflow

1. Create Redpanda service → Set env vars above → Expose ports 9092, 19092, 9644, 33145
2. Enable TCP Proxy → Add TCP proxy for port 19092 (gets public Railway domain)
3. Create Console service → Use redpandadata/console:latest → Expose port 8080
4. Set Console env vars → KAFKA_BROKERS=redpanda:9092
5. Generate HTTP domain → Railway auto-creates domain for Console's port 8080
6. Test internally → From Console terminal: rpk cluster info -b redpanda:9092
7. Test externally → Use Railway's TCP proxy URL from your local machine