> ## Documentation Index > Fetch the complete documentation index at: https://docs.asobeast.com/llms.txt > Use this file to discover all available pages before exploring further. # Deploy on Railway > Deploy asobeast on Railway in one click. The template runs the published images with PostgreSQL and Redis and generates every secret for you. The Railway template is the fastest way to a hosted instance. It runs the same published images as [Run a published release](/install/published-images) and generates every secret at deploy time, so there is nothing to clone, build or configure before the first sign in. [![Deploy on Railway](https://railway.com/button.svg)](https://railway.com/deploy/asobeast?referralCode=GAJ6fQ\&utm_medium=integration\&utm_source=template\&utm_campaign=asobeast-docs) ## What does the template create? One Railway project with four services on its private network. | Service | Image | Public domain | | - | - | - | | `web` | `ghcr.io/asobeast/asobeast-web:1` | Yes, the only entry point | | `api` | `ghcr.io/asobeast/asobeast-api:1` | No | | `Postgres` | `postgres:18-alpine` | No | | `Redis` | `redis:8-alpine` | No | The `web` service is health checked on `/api/health` and the `api` service on `/health`. `Postgres` keeps its data on a volume mounted at `/var/lib/postgresql`, and `Redis` keeps its queue state on one mounted at `/data` and starts with the same memory ceiling and eviction policy as the Compose stack. The template also sets what depends on Railway's edge proxy. `TRUST_PROXY` is `1` on `web`, for the edge, and `1` on `api`, for the web hop. `AUTH_COOKIE_SECURE` is `true`, and `WEB_PUBLIC_URL` is `https://${{web.RAILWAY_PUBLIC_DOMAIN}}`. See [Verify the hop count](/security/hosting#verify-the-hop-count) for why the hop count matters. Redis has no password and relies on the private network. Keep public networking off for `api`, `Postgres` and `Redis`, so `web` stays the only service reachable from the internet, exactly as the Compose stack publishes only the web container. See [Which ports does asobeast publish?](/install/requirements#which-ports-does-asobeast-publish) ## Deploy asobeast Click **Deploy on Railway** above and sign in to Railway. The template fills in every required variable, including the database password and `AUTH_SECRET`, so you can deploy without editing anything. The API applies every database migration and seeds the default workspace when it boots. The instance is serving once all four services show as active. Open the public domain of the `web` service as soon as the deploy finishes. The domain is public from the first minute, and the first account to register becomes the owner, after which registration closes. See [Authentication and accounts](/security/authentication). Railway serves the domain over HTTPS, so the secure session cookie works in every browser, Safari included. ## Optional variables Set optional variables on the `api` service, under its **Variables** tab. Railway stages a variable change and applies it when you deploy the staged changes. Without these the instance runs fully, with email alerts and AI assistance switched off. | Variable | Turns on | | - | - | | `SMTP_HOST`, `SMTP_FROM` | Email alerts. Both are needed, plus `SMTP_USER` and `SMTP_PASSWORD` for an authenticated relay | | `OPENAI_API_KEY` | The AI assisted audit, metadata drafts and action explanations | Every other variable, with its default, is in the [configuration reference](/configuration/reference). ## Use a custom domain Open the `web` service, then **Settings**, then **Networking**, and add a custom domain. Railway shows the DNS record to create at your registrar and issues the certificate once the record resolves. Add the domain to `web` only. The API is reached through the web origin at `/api/backend/*`, so it never needs a domain of its own. Then set `WEB_PUBLIC_URL` on `api` to `https://` followed by the new name, because it still points at the Railway domain and builds the alert, confirmation and recovery links. See [Set WEB\_PUBLIC\_URL](/security/hosting#set-web_public_url). ## Upgrade The `1` image tags move with every `1.x` release, and Railway shows an update button in a service's **Settings** when a newer image is published under its tag. Read the release notes and take a backup first, then update `api` and wait for it to become active before you update `web`. The API applies every pending migration on boot. Leave Railway's automatic image updates off, because they skip the backup and update the two services independently. To choose exactly which release runs, pin an exact version. Open each application service, then **Settings**, and change the source image to a version tag such as `ghcr.io/asobeast/asobeast-api:`, using the same version for `api` and `web`. See [Run a published release](/install/published-images) for the tag shapes, and [Upgrade and roll back](/install/upgrade) for what the compatibility promise covers and what a rollback means once a migration has run. ## Back up PostgreSQL PostgreSQL is the only service that needs backing up, as on any other host. Open the `Postgres` service, then **Backups**, to take a backup by hand before an upgrade and to schedule daily, weekly or monthly volume backups. Volume backups stay inside Railway. For an archive you hold yourself, enable a TCP proxy on `Postgres` under **Settings**, then **Networking**, run `pg_dump` against the address it shows with a PostgreSQL 18 client, and remove the proxy afterwards so the database is private again. [Back up PostgreSQL](/operations/backups) covers the archive format and how to verify that it restores before you rely on it. ## Next steps Paste a store URL and start tracking. How many keyword markets one instance carries before the store rate limits bind. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.