I'm a go dev, but I've never done this before, so give me a minimal reproducible example and I'll get you set-up.

Hi brody

https://github.com/romelgomez/go-arepas

Here it is. I've significantly reduced it; this version now contains only one table, 'Posts'.

Thanks!

Can you give a list of all the command you would run as if you just pulled this code from GitHub and wanted to stand it up for production?

Assume the machine already has go installed.

What is every single thing command I would need from `go mod download` to the migration commands for production, to building the binary and so on.

With that extra information, I should be able to tackle this either Monday or Tuesday at the latest.

Hi brody,

https://github.com/romelgomez/go-arepas

I managed to do it, I have two processes in GitHub workflows, one for the build and another for the migrations, please review it and tell me how I can improve it.

Now I'm a bit lost, what do the GitHub workflows have to do with Railway?

Hi brody, sorry the delay,

I have two .yml files. The build.yml file does nothing except build the project, while the migrate.yml file generates and deploys the updates/migrations to the database defined by the DATABASE_URL environment variable set in the GitHub project. This database is hosted on PostgreSQL in Railway.

You can view the files here:

• build.yml

• migrate.yml

I get that the database is hosted on Railway, but beyond that what do these workflows have to do with Railway? why are you using workflows to do this, to begin with?

I don't see how these workflows help you in the slightest to get your project running on Railway.

When I make an update to the schema and commit that change to the main branch, the migrate.yml workflow automatically runs to update the database schema hosted on Railway. This automation ensures that any schema changes are applied without needing manual intervention.

You can view the schema file here:

Schema file

This project is deployed using the following Docker configuration:

Dockerfile

Does that answer your question? If not, please clarify further, and I'll do my best to provide a better response.

Gotcha, that seems extremely overly complex, why not just have a start script that does all this for you so Railway runs it for you.

Yeah, I see what you mean! A start script could work for simpler setups, but I’m using GitHub workflows because it’s great for automating things like testing, building, and deploying the app (CI/CD stuff). It saves me from doing everything manually, especially as the project grows. Plus, GitHub Actions integrates well with my repo. There are other services like CircleCI, Travis CI, and GitLab CI that do similar things, but since I’m already using GitHub, it just makes sense to stick with it. It might seem a bit complex at first, but it’s worth it for the automation and consistency.

If you are okay with having your database on the public internet go for it.

Hmm, what do you mean by "public"? Am I missing something?

The DATABASE_URL is not public; only the repository is public. You can fork the repo, but the environment variables are private.

So, it should be safe.

Please correct me if I'm wrong—I'm still learning!

The database itself is available on the public internet.

please, let me try to understand and learn more:

The PostgreSQL database in railway has two environment variables:

• DATABASE_PUBLIC_URL

• DATABASE_URL

I’m using DATABASE_PUBLIC_URL in the GitHub workflow to run the migrations. This means that the database is accessible on the public internet, right?

Your proposal is to use a Railway script a .sh for example?, which I assume will use the internal DATABASE_URL environment variable, correct?

If that’s the case, could you provide a link to the documentation so I can review how to set it up that way?

That's correct, though we don't have documentation for this as it wouldn't be Railway specific.

Cool, thanks, that clarifies it. I’ll do some research to figure out how to set it up, and I’ll let you know once I have it done.

Awesome!

Hi Brody

I found this

https://blog.railway.app/p/github-actions

Is @railway/cli the way to go?

I would personally use the docker image instead of the npm install.