Did you provide variables into your Go service?

Railway exposes a DATABASE_URL variable automatically - you might not need to parse all those individual env vars. Try this instead

go

dsn := os.Getenv("DATABASE_URL")
if dsn == "" {
    // fallback to your current method
    dsn = fmt.Sprintf("%s:%s@tcp(%s:%d)/%s", db_user, db_pw, db_host, db_port, db_name)
}

That port 40351 seems odd - Railway's MySQL instances usually run on 3306 internally. The external port changes, but inside Railway's private network you should use 3306. Check your Railway dashboard under your MySQL service there should be connection variables you can reference.

Make sure your variables are actually set - In Railway, go to your backend service → Variables tab. You need to either:

• Reference the MySQL service variables directly (preferred)

• Or manually add DB_USER, DB_PASSWORD, etc.

Try clicking "New Variable" → "Add Reference" and select your MySQL service. This will auto-populate the connection details.

Check if they're on the same network - Your backend and MySQL need to be in the same Railway project to talk privately. If you can connect locally but not on Railway, it's usually a variable issue.

What error are you actually seeing?

I did something like this within my service:
The values are obviously the keys within my database and the key "DB_HOST" is used within my go-code. Is this the right way to approach things?

I would like to try your connection string approach. So I would simply use the url(public for my go code I assume?)
And then use it like this?

Should I change the variable names in my .env to match the variables in railway when I add references? So use the "MYSQL_DATABASE" in my code .env?

Thank you guys for your help so far!

They need to be references to an actual service. For example, if I wanted to use the DATABASE_URL from the service named Postgres, I would need to use ${{ Postgres.DATABASE_URL }}.

No. You should be using variable names you assigned in your service configuration. Not the names of other services’ variables.

Also, if you are using a Dockerfile, you will need to add ARG statements to ensure that the Dockerfile building process is properly “eating” the provided environment variables.

Another thing I’d do for a sanity check is to SSH into the service container and running echo $DB_HOST to make sure the variable actually exists within the container.

To do this, right click your service and click “Copy SSH Command” and run the copied command in your terminal. Note that you’ll need Railway CLI installed beforehand.