13 days ago
I'm trying to figure out how to set up a custom chatbot on my website.
I can't get the test website on Railway to open, it deploys but gives me an error upon opening.
I'm using SillyTavern from github, which is a chatbot software, I'm trying to get it up and running on Railway. I got an api key from openrouter.
I set my variables:
OPENROUTER_API_KEY = (the api key)
PORT = 8000
HOST = 0.0.0.0
NODE_ENV = production
Setting a volume (5gb) seems to have removed all the errors. But despite no errors now, the site won't open.
"Error seems to be caused by the application" is what I get when I try to open the website.
ChatGPT says this:
"Look at the logs:
SillyTavern WebServer\SillyTavern is listening on IPv4: 127.0.0.1:8000
That means the app is live, but only inside the container right now (localhost = 127.0.0.1). Railway can’t serve it publicly unless the server is told to bind to 0.0.0.0 instead of 127.0.0.1."
Admittedly, I set this whole thing up using ChatGPT because I'm a beginner.
ChatGPT has given me some start commands to try to force it to bind to 0.0.0.0 but none of that stuff seems to work. Right now I'm just using "npm run start"
5 Replies
13 days ago
Hey there! We've found the following might help you get unblocked faster:
🧵 Railway Deployment Issue - Recurring Problem After Temporary Fix
🧵 Deployed App Domain Not Resolving – DNSPROBEFINISHED_NXDOMAIN
🧵 Persistent 502 Error with Simple Python HTTP Server - Need Deployment Troubleshooting Help
If you find the answer from one of these, please let us know by solving the thread!
12 days ago
@arvinxx1 can you share your Dockerfile? That is usually where port mapping happens
debugraidcallmewhatyoulike
Your setup is solid so far: SillyTavern from GitHub, deployed on Railway, with environment variables OPENROUTER_API_KEY=(your_key), PORT=8000, HOST=0.0.0.0, NODE_ENV=production, and a 5GB volume that cleared deployment errors. The logs show SillyTavern is listening on IPv4: 127.0.0.1:8000, meaning the app is running but only accessible inside the container. Railway's proxy can't reach it because SillyTavern defaults to localhost for security, ignoring your HOST=0.0.0.0 since it uses specific configs like listen or SILLYTAVERN_LISTENADDRESS_IPV4. This is a standard Node.js/Express behavior where the listen() method binds to 127.0.0.1 unless overridden. Reassurance: This is a configuration tweak, not a code flaw—SillyTavern is designed to allow remote access with the right settings, as seen in community deployments on platforms like RunPod.tweaking Railway's environment variables to make SillyTavern bind to 0.0.0.0 and allow external traffic. Log into your Railway dashboard at railway.app, select your project, then your SillyTavern service, and go to the "Variables" tab. Add these (case-sensitive, as SillyTavern prefixes configs with SILLYTAVERN_):SILLYTAVERN_LISTEN=true: Enables remote listening, switching the bind to 0.0.0.0.SILLYTAVERN_WHITELISTMODE=false: Disables the default IP whitelist (127.0.0.1, ::1), which blocks Railway's proxy. Keep your existing vars (OPENROUTER_API_KEY, etc.). Railway auto-detects ports, so PORT=8000 is fine but optional. Save the variables, and Railway will redeploy. Check the logs for SillyTavern is listening on IPv4: 0.0.0.0:8000. If you need to set these via Railway's CLI, install it (npm install -g @railway/cli), log in (railway login), and run: railway variables set SILLYTAVERN_LISTEN=true SILLYTAVERN_WHITELISTMODE=falseThen redeploy:Open the generated URL (e.g., your-app.railway.app). If it fails, check logs for errors or try adding SILLYTAVERN_LISTENADDRESS_IPV4=0.0.0.0 as a fallback.If env vars don't work (e.g., config override issues), we can force the bind via the start command. Your current npm run start runs node server.js. SillyTavern supports a --listen flag to enable 0.0.0.0. In Railway, go to your service > Settings > Build & Start, and change "Start Command" to: node server.js --listen --whitelist falseThe --listen sets binding to 0.0.0.0, and --whitelist false disables IP filtering. Alternatively, if you prefer npm, use: npm run start -- --listen --whitelist falseThe double -- passes flags to the script. Redeploy and check logs for 0.0.0.0:8000. To revert, set it back to npm run start. If you're using Railway CLI, update the start command in your railway.json (if present) or via the dashboard, then: railway upIf the above feels shaky or hits Railway's free-tier limits (e.g., storage or CPU), pivot to the official SillyTavern Railway template for a pre-configured setup. Visit railway.app/template/YuyzZp and click "Deploy". It uses a Docker image (null2264/st-railway:latest) optimized for cloud, with listen=true and persistence at /home/node/app/persist/. Add your OPENROUTER_API_KEY during setup, and optionally SILLYTAVERN_ENABLEUSERACCOUNTS=true for user auth. Deploy takes 1-2 minutes, then check logs and access the URL. Why pivot? It skips manual config hassles, ensures correct binding, and supports your OpenRouter integration out of the box. If you switch, download any data from your current volume first (via Railway's dashboard). To deploy via CLI: railway init --template=https://railway.app/template/YuyzZp railway variables set OPENROUTER_API_KEY=your_key railway upsecurity upgrade FREE!!!With whitelistMode=false, your chatbot UI is publicly accessible—anyone with the URL can use it. For a "custom chatbot on my website," consider embedding it (via API or iframe) or enabling auth. Add these env vars:SILLYTAVERN_ENABLEUSERACCOUNTS=true: Enables user login in the UI.SILLYTAVERN_BASICAUTHMODE=true, SILLYTAVERN_BASICAUTHUSER=youruser, SILLYTAVERN_BASICAUTHPASSWORD=yourpass: Adds HTTP basic auth. Set these in Railway or via: railway variables set SILLYTAVERN_ENABLEUSERACCOUNTS=true SILLYTAVERN_BASICAUTHMODE=true SILLYTAVERN_BASICAUTHUSER=youruser SILLYTAVERN_BASICAUTHPASSWORD=yourpass In the UI, go to API > OpenRouter, input your key, select a model (e.g., Llama), and test prompts. If the site still won't open, share exact logs or errors (copy-paste from Railway's logs tab). We might need to check config.yaml or npm dependencies.
11 days ago
Thanks for all of that info.
I started by adding the variables SILLYTAVERN_LISTEN=true: and SILLYTAVERN_WHITELISTMODE=false:
It deployed (still no working link though), but then crashed a few seconds later.
Mounting volume on: /var/lib/containers/railwayapp/bind-mounts/e2ca6de5-e62d-4c54-9e3e-b2dc82f17bb9/vol_lr4hfkrzeaoyhqv7
> sillytavern@1.13.3 start
> node server.js
Node version: v22.19.0. Running in production environment. Server directory: /home/node/app
Using config path: ./config.yaml
Using data root: ./data
Preferring IPv4 for DNS resolution
Your current SillyTavern configuration is insecure (listening to non-localhost). Enable whitelisting, basic authentication or user accounts.
Mounting volume on: /var/lib/containers/railwayapp/bind-mounts/e2ca6de5-e62d-4c54-9e3e-b2dc82f17bb9/vol_lr4hfkrzeaoyhqv7
> sillytavern@1.13.3 start
> node server.js
Node version: v22.19.0. Running in production environment. Server directory: /home/node/app
Using config path: ./config.yaml
Using data root: ./data
Preferring IPv4 for DNS resolution
Your current SillyTavern configuration is insecure (listening to non-localhost). Enable whitelisting, basic authentication or user accounts.
Mounting volume on: /var/lib/containers/railwayapp/bind-mounts/e2ca6de5-e62d-4c54-9e3e-b2dc82f17bb9/vol_lr4hfkrzeaoyhqv7
> sillytavern@1.13.3 start
> node server.js
11 days ago
@arvinxx1 can you use Markdown formatting when you reply in here, to make your logs and code snippets easier to read?
I think we'll need to see your Dockerfile, and the logs from when the app appears to be crashing, in order to debug this further.
11 days ago
I think this post is a duplication of this other post:
https://station.railway.com/questions/no-errors-but-website-won-t-load-57f843f7#7x30
please check all your port are set correctly as I wrote in the other thread, also I think opening the same thread multiple time it creates only confusion