Buildspace
Redis

Overview

Optional managed Redis add-on for your Buildspace apps.

Redis is an optional add-on you can install on a Buildspace app after it has been provisioned. Each app gets its own Redis service inside its Railway project, with separate dev and prod instances.

Redis is not part of the default app bootstrap — you opt in per environment from Creator Studio.

How it works

  1. Opt in per environment — Open the Infrastructure tab in Creator Studio, click Enable Redis, then provision it for dev, prod, or both.
  2. One shared service, isolated environments — A single Redis service is created in your app's Railway project. Each environment gets its own volume, its own password, and its own runtime variables.
  3. Persistence is on by default — The service runs redis:8-alpine with AOF persistence enabled and a mounted Railway volume at /data, so data survives restarts and redeploys.
  4. External access for local dev — Redis is exposed over Railway's TCP proxy so you can connect to the same instance from your local machine as well as from your hosted runtime.
  5. Credentials are injected automatically — Buildspace writes Redis connection variables to your runtime service env and stores them as system env vars so they show up in Creator Studio.

Architecture

ConceptDetail
EngineRedis 8 (redis:8-alpine)
PersistenceAOF + periodic RDB snapshots, on a Railway volume mounted at /data
AuthEvery instance has a generated password, written as $REDIS_PASSWORD on the service
IsolationOne Railway service per app, one volume and one password per environment
Environmentsdev and prod each have independent data, credentials, and runtime vars
AccessExternally reachable via Railway's TCP proxy (usable from local dev)
ProviderRailway, orchestrated by @buildspace/hosting-service

Environment variables

When Redis is enabled for an environment, a single variable is injected into the runtime service and also stored as a Buildspace system env var:

VariableSecretDescription
REDIS_URLyesFully-formed redis:// connection string. Uses Railway's externally reachable TCP proxy so the same string works both from your hosted runtime and from outside Railway (local dev, CI).

That's the whole contract. Your code just reads process.env.REDIS_URL — no host, port, or password variables to wire up.

Lifecycle

  • Enabling for an environment is idempotent. Running it again reconciles the Railway service, volume, start command, env vars, and runtime references from the current Buildspace state.
  • Disabling an environment removes that environment's volume, revokes its Buildspace Redis system env vars, and blanks the runtime references. The shared Redis service is removed when no environments still have Redis enabled.
  • Password rotation is not exposed in V1. The generated password is stored as the system key BUILDSPACE_REDIS_SERVICE_PASSWORD and is what the reconcile loop writes back into Railway.

Costs and trade-offs

  • External access uses Railway's TCP proxy. This is convenient for local development but may incur egress costs.
  • This is a single-node Redis deployment. It is appropriate for caches, queues, and pubsub, but it is not a high-availability Redis cluster.
  • The data volume lives in the app's Railway project. Treat Redis as "durable enough for a cache and a queue" rather than a primary database.

On this page