What can run in one Railway project?
A Railway project can contain your website and other services. A service is one running part of the project, such as the code that accepts a booking or the database that keeps it.
Start with the web app. Add another service only when the app needs it, then tell the app how to connect.
How do you get one page online?
Start with a Railway account and a saved project. One documented path connects a GitHub repository, the saved copy of your code. You can also deploy with a terminal command or a prepared app package.
- Prepare test-only settings first. Connecting GitHub can start a deployment, so check which code and services the first build can reach before authorizing the connection. A build prepares the app to run.
- Check how your web service starts and where it listens for requests. Generate a Railway address in the service’s networking settings when you want the website reachable. Confirm that one intended page loads.
- If you add Postgres, a database for structured records, reference its connection setting from the web service. Railway’s Postgres template starts private. Give the website the public address and keep the database on the private connection for app traffic.
How do you try a change without using live records?
Start with a staging environment, a separate set of services and settings for testing. A manual duplicate stages the changes for you to review before deploying. You can also make an empty test environment and add the needed pieces yourself.
Before connecting automatic deployments, enabling pull-request previews or opening a change that will trigger one, confirm the test database, account and email settings. If your app builds those settings into its files, keep Skipped Builds turned off before enabling those automatic steps. A pull request is a proposed change in GitHub. When previews are enabled, opening one can start a temporary environment automatically.
Copies can bring ordinary settings along. Sealed settings are hidden from the usual settings screens after you save them. Railway omits those values from duplicates and pull-request environments. Reusing an earlier build can carry an old address forward even if your new settings are correct.
If the automatic path is unclear, use a manual test environment first. Check who can open the preview, then confirm a made-up booking reaches the test records.
How do the plan and actual usage add up?
The monthly plan amount covers your first usage. If you use more than the included amount, you pay the difference.
For example, US$8 of eligible usage on Hobby totals US$8 before separate charges or tax. A running service can use resources while idle. A configured hard usage limit can take workloads offline when reached. Railway lists different computing rates for its separate virtual-machine products.
| What affects the bill | Published unit |
|---|---|
| Monthly minimum | Hobby US$5 and Pro US$20 per month, applied toward usage. |
| App computing | US$20 per virtual processor and US$10 per GB of working memory per month, measured by the minute. |
| Lasting disk storage | US$0.15 per GB per month of volume storage. |
| Data sent out | US$0.05 per GB of outgoing transfer. |
How long can the trial keep a test project?
The account trial includes a one-time US$5 credit for up to 30 days. It moves to the Free plan after time or credit runs out. The documented Free plan has US$1 in monthly usage credit and tighter limits.
Trial account verification can affect outgoing network access. Railway also documents a separate clock for deleting trial storage. It deletes trial disks 30 days after credit expiry and advises upgrading to retain the data. Export any important test records before the trial ends.
Who looks after the records and backups?
A lasting disk called a volume keeps data across deploys and restarts. Railway’s standard Postgres template starts as one database server. Railway maintains the supplied template and releases security fixes for its database package.
You still decide which customers can read or change records, turn on the backup and failover features you need, and manage major database upgrades. Failover means switching to a working database copy if the main one fails. Railway scopes its database support to the supplied setup. Changing its software or how storage attaches can change what Railway supports.
A volume backup restores inside the same project and environment. Wiping the volume also deletes its backups. Keep a separately tested export when you need a copy that can leave Railway.
How do you roll back or take the app elsewhere?
Railway can restore a retained app package and the custom settings saved with it. Before switching, confirm that those restored settings point to the intended database and other services and that the older code can use the current records. Use a separate recovery procedure if data needs restoring.
After switching, open the public address and check the main task.
Keep your code and the list of settings the app needs. Save uploaded files separately. To move PostgreSQL records, use a database client over an authorized connection, make an export and test restoring it in the matching archive format. Railway documents a connection through an encrypted tunnel as an option when a public database address is unavailable.
What if the work has to continue later?
Use a separate running service for a worker that waits for tasks, or a scheduled job for a short task that starts at a particular time and exits when finished.
For example, a scheduled service can prepare a report overnight. Railway skips the next scheduled run if the earlier one is still working. Check for completion and failures before relying on the job for a customer promise.