Deploy SillyTavern

Deploy and Host SillyTavern on Railway

SillyTavern is the power-user frontend for large language models — character cards, lorebooks, group chats, personas and granular prompt control, pointed at whichever backend you already pay for. Normally it runs on a PC you have to leave switched on. This template puts it on an always-on URL with your data on a volume and auth configured before the domain resolves, so it reaches your phone without leaving your provider keys on an open door.

What This Template Deploys

One service, one volume. No database, no second container — SillyTavern keeps everything as files under its data directory, which is why the volume is not optional and why its contents deserve more care than most self-hosted apps.

About Hosting

SillyTavern was built to run on localhost. Giving it a public URL is the right move for convenience and the wrong one for every default it ships with.

Basic auth is the only lock, and the project says so itself. SillyTavern's documentation states plainly that HTTP basic authentication is not strong security and has no rate limiting against brute force. Every hosted guide reaches for it anyway, because it is what the app offers. Treat it accordingly: a long random password, never reused, because your protection is password entropy alone.

Your provider keys live on the server, not just in your browser. SillyTavern writes backend secrets into its data directory — the allowKeysExposure setting exists precisely because those keys are stored server-side. Anyone past basic auth gets your OpenAI, Anthropic or OpenRouter keys, not merely your chat history. That is what you are defending.

The IP whitelist locks you out before it protects you. SillyTavern ships with whitelist access control on and only loopback permitted. Railway assigns dynamic IPs with no stable gateway to add, so the whitelist can only block you. Disable it and lean on basic auth — but see the first point, because that trade is real rather than free.

It is a frontend, and it brings no model. Nothing here generates text. You supply an API key for a hosted provider or a URL for a backend you run. Whatever you route through it stays governed by that provider's terms, which a self-hosted frontend does not alter.

One instance is one user unless you say otherwise. Multi-user accounts are off by default, so a shared URL means a shared persona, chat list and settings. Enable user accounts before handing the link to anyone, or expect people to overwrite each other.

Typical cost: ~$5–10/month for one small service and a volume at $10/GB/month RAM, $20/vCPU/month CPU and $0.15/GB/month volumes. SillyTavern is AGPL-3.0 and free; inference is billed by whichever provider you point it at.

How It Compares

The honest edge: if you are at a desk with the machine running, a local install is free and strictly safer — keep it. Open WebUI is better if you want a clean assistant interface rather than character and prompt machinery. Hosting SillyTavern earns its place for one reason — continuity across devices without a PC left on — and the price is that convenience-grade auth now stands between the internet and your provider keys.

Deploy in Under 5 Minutes

1. Click Deploy and pick a workspace. Set a long random basic-auth password now, not after — the domain is reachable the moment it resolves.
2. Wait for the build and confirm the volume is mounted on the data directory under Settings → Volumes.
3. Open the public domain. Your browser prompts for the basic-auth credentials before SillyTavern loads.
4. Add a backend under API Connections — a provider key or a URL for a server you run — and send one message to confirm it responds.
5. Import a character card and enable user accounts if more than one person will use the instance.

Verify before you rely on it: open your domain in a private window. If SillyTavern loads without prompting for credentials, the instance and the keys inside it are open to anyone with the URL — fix that before adding a backend.

Common Use Cases

• Continuity across devices — pick up the same chat, persona and lorebook on a phone that you started on a laptop.
• Long-form collaborative fiction — lorebooks, author's notes and world info that stay consistent across a long session.
• Prompt engineering and comparison — edit the instruct template directly and run one character against several backends to compare.
• One frontend over many backends — switch between hosted providers and your own inference server without changing tools.

Configuration

Set the password before the first deploy, not after. The public domain is live and discoverable the moment it resolves, and the instance behind it holds your provider keys.

Do not re-enable the IP whitelist as a second layer. With no stable gateway address to permit, turning it back on blocks you rather than an attacker.

Dependencies for SillyTavern Hosting

• Railway account — ~$5–10/month for one small service and a volume.
• Bundled services — none. SillyTavern is a single Node process with no database.
• Volume — required. Holds character cards, chat history, lorebooks, personas, settings and stored provider secrets.
• A backend — an API key for a hosted provider, or a URL for an inference server you run. SillyTavern supplies the interface, never the model.

Deployment Dependencies

• SillyTavern on GitHub
• SillyTavern documentation
• Configuration file reference
• Railway volumes

Implementation Details

The app runs the official image on a pinned tag rather than latest, serving on port 8000 behind Railway's HTTPS proxy so TLS terminates at the edge. SillyTavern resolves configuration with environment variables taking precedence over config.yaml, which is what makes a container deployment workable — security settings are applied as variables rather than through a config file you would otherwise bake into the image or mount and edit by hand.

Three settings decide whether this works and whether it is safe. listen must be true or the server binds to loopback and nothing reaches it. whitelistMode must be false or Railway's dynamic addressing locks you out. basicAuthMode must be true, because the first two together otherwise leave the app open to anyone who finds the URL. Two of three right gives you either an unreachable instance or an unprotected one.

Everything stateful is files on the volume: character cards, chat history, lorebooks, personas, extension data and the secrets file holding your backend keys. Back it up if your chats matter, and remember what the backup contains — a copy of that directory is a copy of your provider credentials.

Frequently Asked Questions

Is a public SillyTavern instance safe? Only as safe as its password. The project's own docs note basic auth has no rate limiting, and the instance holds your provider keys — use a long random password and do not share the URL casually.

Why can't I reach my instance? Usually the IP whitelist. It defaults to loopback-only and Railway has no stable address to add, so it blocks every real request.

Do I need an API key? Yes. SillyTavern is a frontend with no model of its own — supply a hosted provider key or point it at an inference server you run.

Will my characters and chats survive a redeploy? Yes, with the volume mounted. Everything lives as files on it; without one, each deploy starts empty.

Can several people use one instance? Only with user accounts enabled. Left off, everyone shares one persona and chat list and will overwrite each other.

Why Deploy SillyTavern on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying SillyTavern on Railway you get the configuration a public instance requires — listening beyond loopback, the unusable IP whitelist off, basic auth enforced before the domain resolves, and your cards, chats and keys on a volume that survives every redeploy.