Deploy Teable | No-Code Database with Postgres, Redis and a Real Volume
Self-host Teable on Railway: pinned release, Redis cache, data that stays
Just deployed
/var/lib/postgresql/data
Redis
Just deployed
/data
Just deployed
/data
Deploy and Host Teable on Railway
Teable is a no-code database: spreadsheet-style tables, views and forms on top of real Postgres, with an API over every table.
About Hosting Teable
This template pins the Teable release, and it deploys the Redis that current Teable requires.
That second part is the whole story of why the existing template fails. It runs ghcr.io/teableio/teable with no tag at all, and with patch auto-updates switched on, so the running version drifts on its own. Current Teable refuses to start without a cache:
Error: Config validation error: "BACKEND_CACHE_REDIS_URI" is required
There is no Redis in that template. So it worked until the floating tag rolled forward into a release where the cache became mandatory, and from that moment every new deployment crashed on boot. Pinning the image is exactly what prevents this, and it is what this template does.
Common Use Cases
- A shared table for a team that would otherwise live in a spreadsheet, with types and permissions
- A lightweight admin UI over data you also query from your own code - it is Postgres underneath
- Forms and views for collecting structured input without building a front end
Dependencies for Teable Hosting
- Postgres, included, on a persistent volume - this is where your tables actually live
- Redis, included, for the cache Teable requires
- A persistent volume on the app for uploaded attachments
Deployment Dependencies
- Documentation: https://help.teable.io
- Source: https://github.com/teableio/teable
Implementation Details
Open the domain after deploying and create the first account - it becomes the administrator.
| Variable | Why |
|---|---|
| PRISMA_DATABASE_URL | Points Teable at the bundled Postgres over the private network |
| BACKEND_CACHE_PROVIDER, BACKEND_CACHE_REDIS_URI | The Redis cache, required since recent releases |
| SECRET_KEY | Generated per deployment; signs sessions |
| PUBLIC_ORIGIN | The public address, used in links and attachment URLs |
| BACKEND_STORAGE_PUBLIC_DIR, BACKEND_STORAGE_PRIVATE_DIR | Attachments, kept on the volume rather than in the container |
One Railway-specific detail worth copying if you build something similar: the bundled Redis starts with --bind :: 0.0.0.0. Railway private networking is IPv6, and Redis binding only to IPv4 leaves the app failing with Connection is closed even though Redis itself looks healthy.
Why Deploy Teable on Railway?
Three services on a private network from one deploy, each with its own volume, and a pinned app version - so the next redeploy gives you back the same Teable you were running, not whatever shipped upstream since.
Template Content
