Deploy Raytha on Railway

Railway is the fastest way to get Raytha running: a one-click template that deploys the app with PostgreSQL included. This page covers the deploy and the settings to check afterwards.

Deploy the template

Open the Raytha template on Railway and deploy it into a new project.
Wait until the Raytha service and its PostgreSQL service are both deployed.
Open the public domain Railway gives the Raytha service. Raytha redirects to /raytha/setup until an administrator exists.
Create the administrator. The steps are the same as in the Quickstart.

Raytha applies its own database migrations when it starts (APPLY_PENDING_MIGRATIONS ships as true), so there is no separate migration step.

Deploy on Railway

What the template sets up

The template creates one Railway project with two services:

Raytha, from the raythahq/raytha image on Docker Hub, with a public Railway domain and HTTPS. A volume is mounted at /data, and the health check path is /healthz.
PostgreSQL 17, from Railway's postgres-ssl image, with its own volume. Railway generates the password.

On the Raytha service it sets these variables:

ConnectionStrings__DefaultConnection=<reference to the Postgres service>
APPLY_PENDING_MIGRATIONS=true
FILE_STORAGE_PROVIDER=Local
FILE_STORAGE_LOCAL_DIRECTORY=/data/user-uploads
FILE_STORAGE_MAX_FILE_SIZE=100000000
FILE_STORAGE_ALLOWED_MIMETYPES=text/*,image/*,video/*,audio/*,application/pdf

It also offers optional SMTP_* variables, covered below. The template on Railway is the source of truth: open the service's Variables tab to see exactly what was set for your project.

See Deploy Raytha on Railway for costs and common questions.

After the first deploy

Set the Website URL

On the setup screen, Website URL must be the address visitors use, including https://. Raytha builds links in emails and absolute media URLs from this value and never from the request's host header. If you later attach a custom domain, change it under Settings, Configuration.

Decide where uploads live

The template stores uploads on the Raytha service's volume: FILE_STORAGE_LOCAL_DIRECTORY is /data/user-uploads and the volume is mounted at /data, so files survive redeploys. Anything written outside /data is lost on the next deployment, because Railway containers do not keep their filesystem. A Railway service can have only one volume, so keep the uploads directory under /data. Your options:

Keep the template's setup: Local storage on the volume at /data/user-uploads. Volume size depends on your Railway plan.
Use S3-compatible storage or Azure Blob and set the variables in File storage. This is the better choice if you also want files served from a CDN.

Whichever you pick, back it up separately from the database.

Configure email

Add SMTP_HOST, SMTP_PORT, SMTP_USERNAME, SMTP_PASSWORD and SMTP_FROM_ADDRESS to the Raytha service's variables, or save an SMTP override in the admin. Without either, password resets and magic-link sign-in emails cannot be sent. See Sending emails.

Check proxy trust

Railway terminates TLS in front of the app and forwards X-Forwarded-For and X-Forwarded-Proto. Raytha's default, TRUSTED_PROXIES=all with one hop, is the right setting for that, and you can leave it unset. If you put Cloudflare in front of Railway, two proxies append to the chain, so set:

TRUSTED_PROXIES=all
TRUSTED_PROXY_HOPS=2

Getting this wrong makes every visitor appear to come from the same address, which breaks the per-IP sign-in rate limit. See Running behind a proxy.

Point health checks at Raytha

If you configure a health check path on the service, use /healthz for a liveness check or /healthz/ready to also test PostgreSQL and file storage. See Health checks.

Backups and upgrades on Railway

A Raytha site is two things: the PostgreSQL database (content, users, settings, API key hashes and data-protection keys) and the uploaded files. On this template both live on Railway volumes, one on each service.

Railway volume backups

Railway can back up a volume on a schedule. Open the service, then its Backups tab, and pick one or more schedules:

Daily, kept for 6 days
Weekly, kept for 27 days
Monthly, kept for 89 days

Turn this on for both the Postgres service and the Raytha service. You can also take a manual backup from the same tab. A restore goes back into the same project and environment. Railway bills backups for their incremental size at volume storage rates; see Railway's backup docs for the current details.

Your own database dump

Volume backups stay inside Railway. To keep a copy elsewhere, dump the database from your own machine:

On the Postgres service, open Settings, Networking and enable public access (a TCP proxy). Railway then exposes DATABASE_PUBLIC_URL in the service's variables. Traffic through the proxy counts as egress.
Use a pg_dump from PostgreSQL 17, the same major version as the server:
```
pg_dump -Fc "$DATABASE_PUBLIC_URL" -f raytha-$(date +%F).dump
```
Copy uploads too, or rely on the Raytha volume's backups for them.

Restoring, and the order to restore database and files in, is covered in Backups and restores. You can turn public access off again when you are done.

Upgrading Raytha

The template uses the raythahq/raytha image without a version tag, which means latest, and it does not turn on Railway's automatic image updates. Your site stays on the image it was deployed with until you act:

Follow latest. When Railway shows an update for the image in the service settings, or when you redeploy, the service pulls the current latest image.
Pin a version. Set the image to a release tag such as raythahq/raytha:2.0.1 under the service's Settings, Source. You choose when to move, and a rollback is a change back to the previous tag. Releases are listed on GitHub.
Automatic updates. Under Settings, Source, Configure Auto Updates, Railway can update the image in a maintenance window you choose. It backs up attached volumes before each update. New versions are detected with a delay of up to a few hours.

Raytha applies database migrations when it starts, so a new image upgrades the schema on its first boot. Take a backup first, and read the release notes. For the move from 1.5 to 2.0 follow Upgrading from 1.5 to 2.0.

Gotchas

Plain HTTP is not an option in production. The sign-in cookie is Secure, which is fine behind Railway's HTTPS domain.
Variables set in Railway override appsettings.json but not a .env file inside the image. The standard image contains none.
Changing FILE_STORAGE_PROVIDER after you have uploaded files does not move them.
The database is the only home of your content, API key hashes, webhook secrets and data-protection keys. Losing it loses the site.

Next steps

Quickstart: your first content type and API call.
Configuration: every environment variable.
Deploy with Docker if you later want to host it yourself.