Deploy Teable

Deploy and Host Teable on Railway

Teable is an Airtable-style spreadsheet database backed by private PostgreSQL and Redis, with persistent local attachments. Basic tables do not require a model-provider key or paid feature license.

Deploy Teable on Railway

About Hosting Teable

This template deploys three container images directly. No GitHub repository, source fork, or build setup is required.

Use one Teable replica with local attachment storage. First boot applies database migrations before starting the application. Allow up to 600 seconds for /health; upstream recommends at least 4 GB RAM and two CPU cores for the standalone stack.

First deployment and account

1. Deploy all three services with their volumes. Check PostgreSQL and Redis startup as well as application health. Redis must be able to write AOF files under /data.
2. Create the first account before sharing the URL, using controlled access. The first account becomes instance administrator. There is no preset admin password; a teable.ai cloud account does not authenticate to this instance.
3. Configure registration and invitations in the administrator UI before broader access. Do not assume an ENABLE_SIGNUP environment variable closes registration.
4. Create a base/table and row, edit and reload it, and verify row and attachment readback after restart. Confirm wrong-password and anonymous access behavior before storing sensitive data.

An automatically generated public domain is not an owner-only setup gate. If you cannot control the initial registration window, establish private ingress or an access gateway before exposing the app.

Connection and session settings

• DATABASE_URL and PRISMA_DATABASE_URL reference ${{Postgres.DATABASE_URL}}.
• BACKEND_CACHE_PROVIDER=redis; BACKEND_CACHE_REDIS_URI references ${{Redis.REDIS_URL}}.
• Redis reference variables include REDISUSER=default and REDISPORT=6379, without underscores. The password is generated separately.
• PUBLIC_ORIGIN=https://${{RAILWAY_PUBLIC_DOMAIN}} is the exact app HTTPS origin without a trailing slash. For a custom domain, update it to that origin and redeploy.
• BACKEND_SESSION_COOKIE_SECURE=true and BACKEND_TRUST_PROXY=1 account for Railway's single ingress hop. Reassess this trust count if adding another proxy; do not blindly trust every forwarded header or disable Secure cookies. Incorrect proxy/origin settings can break sessions, uploads and imports.
• Keep generated SECRET_KEY, database password, and Redis password private and stable across restarts. Never commit resolved credentials.

Persistent storage and permissions

PostgreSQL stores accounts, schemas and rows. The Teable volume stores local attachment bytes. Redis provides the authenticated cache/session backend with AOF and snapshots.

The Redis startup command sets mount ownership to redis:redis and mode 700 before the image entrypoint drops privileges, preserving Railway's lost+found. This avoids failed AOF startup when the entrypoint skips automatic permission repair. The app uses RAILWAY_RUN_UID=0 for writable mounted assets; this is a permissions tradeoff, not production hardening.

Back up PostgreSQL, attachments, Redis and secret configuration together; volumes and AOF are not backups. For scaling or production attachment storage, review upstream S3-compatible storage guidance.

PostgreSQL 17 is for fresh volumes only. Do not downgrade an existing PostgreSQL 18 volume in place. Plan a backed-up logical migration and test it separately. A version tag is not a guarantee of future database/image compatibility.

Validation scope

The configuration was checked on fresh volumes with actual browser table creation and row creation/edit/reload. After restarting Teable, PostgreSQL and Redis, the edited row, existing authenticated session and exact attachment bytes persisted. Signup/login, wrong-password rejection, anonymous denial and Secure session cookies were also verified during validation.

Attachment upload and readback were exercised through authenticated browser API requests, not the file-chooser UI. Registration-policy closure and a fresh login after restart remain unverified. Existing-session persistence is not proof of a new login after restart. SMTP, paid integrations, backup/restore, upgrades and production load require separate validation.

Common Use Cases

• Team tables, internal records and spreadsheet-style workflows.
• Structured data with PostgreSQL-backed storage.
• Evaluating a self-hosted alternative to a hosted spreadsheet database.

Dependencies for Teable Hosting

Three Railway services, three volumes, private service references, HTTPS, and controlled first-administrator setup. SMTP/email delivery, external AI providers, optional paid features, backups and restore workflows require separate configuration and validation.

Deployment Dependencies

• Teable Docker deployment guide.
• Pinned Teable release source, for reference only; deployment uses the container image directly.
• PostgreSQL SSL 17 and Redis 8.2 container images listed above. Review upstream feature licensing before enabling paid functionality.

Why Deploy Teable on Railway?

Railway provides HTTPS routing, private database/cache networking, persistent mounts and deployment logs. You manage administrator access, registration policy, backups, licensing and resource capacity.