Deploy Redpanda

Redpanda + Console

High-performance Kafka API streaming platform with web console, on Railway

Deploy and Host

Redpanda (Kafka-compatible streaming data platform) with Redpanda Console (web UI) on Railway. Single click spins up both services with internal networking already wired — no broker env-var hunting, no manual listener configuration.

About Hosting

Redpanda is a Kafka-compatible streaming data platform written in C++. It's a drop-in replacement for Apache Kafka with lower latency, simpler ops, and no ZooKeeper dependency. This template deploys a single-node Redpanda broker with a web-based management console so you can inspect topics, produce/consume messages, and monitor schemas from one UI.

Why Deploy

Self-hosting Redpanda on Railway gives you full control over your streaming data. Run event-driven architectures, real-time pipelines, or CQRS/ES systems without the operational overhead of managing Kafka clusters. The broker runs a single-node KRaft cluster (no external ZooKeeper), and the console connects to it automatically over the private network — just open the web UI and start streaming.

Common Use Cases

• Event-driven microservices with async message passing
• Real-time analytics pipelines and data ingestion
• Change data capture (CDC) from databases to downstream consumers
• CQRS/Event Sourcing systems with append-only streams
• IoT telemetry and time-series data ingestion
• Replacing managed Kafka services to reduce cost and egress

Dependencies for Redpanda + Console

Deployment Dependencies

Railway builds both services from their Dockerfiles (Dockerfile for console, broker/Dockerfile for broker). No volumes, no persistent storage — the broker runs on Railway's ephemeral container filesystem (KRaft single-node metadata is rebuilt on each boot; production deployments should attach a volume for durability). All credentials and connection strings are auto-generated via Railway placeholders (${{broker.RAILWAY_PRIVATE_DOMAIN}}, ${{RAILWAY_PUBLIC_DOMAIN}}).

Features

• Kafka wire-compatible — drop-in replacement for Apache Kafka with the Kafka protocol.
• Dual named listeners — an INTERNAL listener over the Railway private network (for Console + same-project services) and an EXTERNAL listener exposed to the internet through Railway's L4 (raw TCP) proxy.
• Auto-configured broker — single-node KRaft, no manual setup. Internal + external listeners resolve from runtime env (private domain + TCP-proxy vars).
• Built-in Schema Registry on :8081, enabling per-topic schema views in the console.
• Auto-topic creation enabled by default — produce to any topic name immediately.
• Web console health endpoint (/health) gated on the broker being reachable.

Quick Start

1. Deploy using the button above. Railway creates the console and broker services in one project and wires the internal network.
   • The broker needs ~30–60s to start a KRaft single node.
   • The console blocks (bounded) until the broker accepts TCP, then serves its UI.
2. Open the console. The console service gets a public *.up.railway.app domain. Open it and you'll see an empty cluster — no topics yet (auto-create is on).
3. Produce / consume. Connect any Kafka client using the bootstrap server shown in the console (the external TCP-proxy endpoint), or the private broker.railway.internal:9092 from same-project services.

# Example: any Kafka client against the EXTERNAL (public) listener
kafka-console-producer --bootstrap-server : \
  --topic my-topic
kafka-console-consumer --bootstrap-server : \
  --topic my-topic --from-beginning

Environment

Console (root service)

The broker (broker/) service is fully auto-configured via hardcoded ENV defaults in broker/Dockerfile — single-node KRaft, dual listeners, health shim on :8080. No deploy-form variables needed.

Prerequisites

• A Railway account with a workspace (this deploy targets the INAPP workspace).
• Nothing to pre-install — both redpandadata/redpanda and redpandadata/console are pulled directly from Docker Hub.
• For external Kafka clients: a Kafka client library (librdkafka, kafka-clients, confluent-kafka, etc.). No broker-side client installs are required.

Architecture

Two services in one Railway project, talking over the project's private network:

                     Railway private network
 ┌──────────────────────────────────────────────────────────────┐
 │                                                              │
 │   ┌─────────────────────┐       ┌──────────────────────┐     │
 │   │     broker          │       │     console          │     │
 │   │                     │       │                      │     │
 │   │  INTERNAL :9092 ◄───┼───►   │  KAFKA_BROKERS       │     │
 │   │  EXTERNAL :9093     │       │  SCHEMA_REGISTRY_URL  │     │
 │   │  Schema  :8081  ◄───┼───►   │                      │     │
 │   │  Health  :8080      │       │  HTTP :8080  ◄──► public     │
 │   │  Admin   :9644      │       │                      │     │
 │   └─────────────────────┘       └──────────────────────┘     │
 │                                                              │
 └──────────────────────────────────────────────────────────────┘
             ▲
             │ Railway L4 TCP proxy (EXTERNAL listener)
             ▼
     Internet Kafka clients

• INTERNAL listener (:9092) — binds 0.0.0.0:9092, advertises broker.railway.internal:9092. Used by the Console and any same-project service.
• EXTERNAL listener (:9093) — binds 0.0.0.0:9093, advertises the Railway TCP-proxy endpoint (RAILWAY_TCP_PROXY_DOMAIN:RAILWAY_TCP_PROXY_PORT) so internet Kafka clients can reach it.
• Schema Registry (:8081) — built into the broker, used by Console for per-topic schema views.
• Health shim (:8080) — Perl script reflecting /v1/status/ready on the Admin API. Railway's healthcheck hits this port.
• Admin API (:9644) — internal only, used by the health shim.

Configuration Reference

See Also

• Redpanda docs
• Redpanda Console docs
• Railway TCP proxy