Deploy and Host FoundationDB on Railway

FoundationDB is a distributed, ordered key-value store originally built and now open-sourced by Apple. It offers strict serializable ACID transactions across the entire keyspace, automatic sharding and replication, and is famously the database that powers Apple's iCloud — alongside Snowflake's metadata layer, IBM Db2 on Cloud, and storage backends like JanusGraph and Tigris.

About Hosting FoundationDB

FoundationDB is normally operated as a multi-machine cluster — a coordinator quorum, replicated storage roles, dedicated transaction logs — which is overkill for development environments, side projects, or small production workloads. This template runs a single-node FoundationDB instance from the official upstream Docker image, with a persistent volume so your data survives redeploys and container replacements. A small entrypoint discovers the container's current IPv4 on every boot, rewrites the coordinator address in the cluster file, and on the very first boot only runs configure new single ssd-2 to initialise the database. One click, no compilation, no configuration files to hand-edit, cold start to a usable database in roughly 10 seconds.

Common Use Cases

Transactional key-value backend for a Railway-hosted app that wants real ACID guarantees without operating a cluster
Local-feeling development environment against a real FoundationDB — same client libraries, same wire protocol, no SQLite stand-ins
Metadata or coordination store for systems built on FDB layers (Stalwart Mail Server, JanusGraph, Tigris, custom record-layer apps)

Dependencies for FoundationDB Hosting

A Railway persistent volume mounted at /var/fdb/data (provisioned automatically by this template)
Railway private networking so other services in the same project can resolve the coordinator over internal DNS

Implementation Details

Built from foundationdb/foundationdb:7.3.63. The entrypoint script handles every pDB normally expects an operator to do: it picks the current container IPv4, writes acluster file whose coordinator address matches --public-address, starts fdbserver with the SSD storage engine,etects a fresh volume and runs configure new single ssd-2. A storage-file marker on the volume prevents re-initialisation on later boots, so your data is safe across redeploys, scaling events, and Railway-side container replacements.

Client services in the same project connect by referencing a single variable — ${{FoundationDB.FDB_CONNECTION_STRING}} — which resolves to a full cluster string using Railway's private DNS. No port forwarding, no Compose files, no manual cluster-file plumbing.

Why Deploy FoundationDB on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying FoundationDB on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway. can you help it add it here as faq or stuff so peopel can see it directly also in rialway

Yes — here's a fixed, FAQ-extended version. I also patched a small typo in Implementation Details ("every pDB" → readable sentence) where text looks to have been clobbered: er replacements. A small entrypoint discovers the container's current IPv4 on every boot, rewrites the coordinator address in the cluster file, and on the very first boot only runs configure new single ssd-2 to initialise the database. One click, no compilation, no configuration files to hand-edit, cold start to a usable database in roughly 10 seconds.

Common Use Cases

Transactional key-value backend for a Railway-hosted app that wants real ACID guarantees without operating a cluster
Local-feeling development environment against a real FoundationDB — same client libraries, same wire protocol, no SQLite stand-ins
Metadata or coordination store for systems built on FDB layers (Stalwart Mail Server, JanusGraph, Tigris, custom record-layer apps)

Dependencies for FoundationDB Hosting

A Railway persistent volume mounted at /var/fdb/data (provisioned automatically by this template)
Railway private networking so other services in the same project can resolve the coordinator over internal DNS

Deployment Dependencies

Implementation Details

Built from foundationdb/foundationdb:7.3.63. The entrypoint script handles every piece of work FDB normally expects an operator to do: it picks the current container IPv4, writes a cluster file whose coordinator address matches --public-address, starts fdbserver with the SSD storage engine, and on the very first boot detects a fresh volume and runs configure new single ssd-2. A storage-file marker on the volume prevents re-initialisation on later boots, so yours, scaling events, and Railway-side container replacements. Deploy FoundationDB on Railway?

By deploying FoundationDB on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

FAQ

Does my data survive redeploys?

Yes. All FoundationDB state lives on a persistent Railway volume mounted at /var/fdb/data. Redeploys, container replacements, and even scaling events keep the volume attached. The entrypoint detects existing storage files on boot and refuses to re-initialise, so configure new is only ever run once — on the very first boot of a fresh volume.

Can I connect from outside Railway, e.g. my laptop?

Yes. The template enables Railway's TCP Proxy by default and runs in external mode, advertising the public proxy host and port as FoundationDB's canonical address. Copy the cluster string from FDB_CONNECTION_STRING and any FDB client (Python, Go, Node, Rust, Java, fdbcli)

Internal mode vs external mode — what's the difference?

FoundationDB embeds a single canonical address in every wire-level handshake packet,on when the port they dialed doesn't match it. Because Railway's TCP proxy translatesports (e.g. external :11333 → container :4500), the server has to commit to one canonical view of itself:

external (default when the TCP proxy is enabled): public-address is the proxy host:port. Both external clients and other Railway services in the same project connect through the proxy. Works for everyone; internal traffic hairpins through Railway's edge.
internal: public-address is the container's private IP:port. Direct, in-network traffic for services in the same project. External clients cannot connect.

Set FDB_MODE to override. The currently-active mode is exported to the container's environment, so printenv FDB_MODE inside the container always tells you which mode is live.

How do I wipe the database and start fresh?

Set FDB_FORCE_INIT=1 in the service variables and redeploy. The entrypoint will wipe /var/fdb/data and bootstrap a new database on the next boot. This destroys all data. Unset (or set back to 0) afterwards so the next deploy doesn't wipe again.

Which storage engine?

ssd-2 by default. You can change FDB_STORAGE_ENGINE before the first boot, but the choice is locked in at configure new time — switching later requires wiping the volume (FDB_FORCE_INIT=1).

Why does the cluster file use an IP and not a hostname?

fdbserver recognises itself as the coordinator by comparing its --public-address to the address in the cluster file verbatim. The entrypoint resolves the public hostname to an IPv4 on every boot and writes both in matching form. Clients can still use the hostname in their own cluster files — only the server-internal handshake is IP-pinned.

What does the template cost to run?

Just standard Railway compute and storage. The container itself is small (≈ 100 MB image after layers, ≈ 200 MB RSS idle). The volume grows with your data. In external mode, internal services hairpin through the Railway TCP proxy, which counts as egress bandwidth — usually negligiblto FDB_MODE=internal if egress costs become a concern and you don't need externalaccess.