Railway Step-by-Step: Deploy from GitHub with Database

👁 115 reads

Railway deploys an application from a GitHub repository in minutes: you point to your project, Railway builds and runs it, and you add a database with one click. This tutorial takes you from an empty account to a working application with a database and public URL, following Railway’s official guide.

Before You Start: Test Your Project Locally

Railway will build your application exactly as it exists in the repository, so you can catch most first-deployment problems beforehand. Make sure your application runs locally from a clean clone of the repository, without files that only exist on your machine. Write down all the environment variables it needs, because you’ll have to add each one in Railway. Check which port the application listens on and whether it reads it from a variable rather than having it hardcoded.

Files with secrets, such as a local file with variables, should not end up in the repository.

Step 1: New Project from Repository

In the dashboard, click New Project and choose deployment from a GitHub repository. Railway requires a connected GitHub account, and if you haven’t connected one yet, it will prompt you. Then you search for your project and select it from the list.

You have two options: Deploy Now starts building immediately, while Add variables lets you set environment variables first. If your application needs a database or API keys, choose the second option.

Step 2: How Railway Builds Your Application

Railway automatically detects how to build your project. If there’s a Dockerfile in the repository, it will use it, otherwise it will choose a build method based on the language and project files. At this stage, the build and deployment logs are most important.

The documentation gives valuable advice here: read the entire log, because the real error is rarely in the last line. Most often it’s about a missing environment variable or a different language version than the one you’re using locally.

Step 3: Database

You add a PostgreSQL database using the + New button on the project canvas, selecting Database and PostgreSQL. Railway creates it as a separate service and provides variables with connection data, including the database address.

Step 4: Variables and References

In your application service settings, you add variables. Instead of copying the database address, you set a reference to the database variable, for example to its connection address. This way, when the database data changes, the application gets the new data automatically. You also add keys to external services and production environment settings here.

Step 5: Public URL

This is the step that surprises many people: after deployment, the application is not accessible from the internet by default. You go into the service settings, networking section, and click Generate Domain. You get a public URL where the application runs. You can connect your own domain in the same place.

Step 6: Deployments After Every Change

From this point on, every change pushed to the repository triggers a new deployment. You don’t log into any server, and the deployment history lets you roll back to a previous version when something goes wrong.

Command Line

Railway also has a command-line tool. The railway up command sends application files straight from your computer, without a repository, and separate commands add a database or generate a domain. It’s useful for quick tests and scripts.

Example: Discord Bot with Database

You have a Discord bot that saves user points. The repository is on GitHub. In Railway, you create a project from the repository, choose to add variables, enter the bot token, add a PostgreSQL database, and set a reference to its address. The bot runs 24/7, and every fix pushed to GitHub reaches the server automatically.

After such a deployment, it’s worth doing one thing right away: push a small change and check whether the bot updated itself. This confirms that automatic deployments work before they’re really needed. It’s also worth checking the database after a few days of operation and making sure user points are being saved and don’t disappear after redeployment.

Most Common Mistakes

• No public URL and the belief that the application isn’t working.
• Keys in code instead of in environment variables.
• Reading only the end of the log.
• Database address hardcoded instead of a reference to a variable.

How to Evaluate Your First Deployment

After deployment, open the generated URL and test the most important features, not just the home page. Check whether the application saves data to the database and whether it persists after redeployment. Review the logs from the first hour of operation: warnings you ignored locally can be the first signal of a problem on the server. Finally, push a small change and check whether the new deployment started automatically.

Once your first application is running, you deploy the next ones the same way: project from repository, variables, optionally database and domain. After the second project, the entire procedure takes a few minutes, and on the project canvas you see all services and connections between them in one place.

// read moreRailway in Practice: Bots, APIs, AI Apps & Scheduled TasksGuidesRailway Hosting: How Much Does the Hobby Plan Really Cost?AI ToolsLinear Step-by-Step: Teams, Cycles, Roadmaps & GitHubGuides

Kinetyra