Railway App

Hosting General
#10

Hi Robert,

It is not my intention for you to change your workflows. My intention for bringing up Railway is to highlight the ease with which a full stack application can be deployed. This is for the benefit of newbies who get easily confused by the number of alternatives.

The reason for using Github is two-fold. In the first instance it is a version control. Secondly, it will replace the File Transfer Protocol.

Mind you, Railway is not the only platform as a Heroku alternative. In another post I saw that someone had adopted Render. Then there is also Cycle and many others.

Out of all of these, my personal preference is Railway. Other opinions may differ.

1 Like
#11

You could also try with any of these:

1 Like
#12

Please see:

2 Likes
#13

Thank you Ben. I’m one of the newbies to Wappler and I appreciate the pointer to Railway! I’m still evaluating hosting options and Railway sounds like a great fit for me. I have done quite a lot of full-code work (C#, javascript, MS SQL, HTML, CSS, etc.), so I’m not afraid of multi-step setups, but I’d rather focus on a smooth, easy workflow that I can easily hand off to others when needed, so I’ll check out Railway.

1 Like
#14

Hi and thank you Ben, I have been deploying to Railway from Wappler using Github before you posted this video :slight_smile: it is very easy to do. Also your enviroment variables will be detected by Railway so it will ask which values to assign them when you deploy, which gives a lot of flexibility and security (I use it to have diferent salt encryption values between local development and online instances)

PROBLEM: The only thing I don’t like is that my project uses SQLite database (because I am not technical enough to work with postgres or other db) and I don’t know how to separate my local database that I use for testing from the one I like to work on production in the railway instance.

I can only think in one solution: Make Wappler ignore the SQLite database (using gitignore) so the file is not in the Github repository and therefore the Railway app does not have that file as part of the deployment. But, how to add and keep a separate SQL database in the railway instance that is always updated in its structure / scheme to work remotely?

Thanks from Mexico

p.d. I am new to Wappler, two months now, coming from Bubble development. Your videos have been my primary source of learning Ben, you are amazing.

#15

It is probably better to use antother database like MySQL. The problem for the moment is that MySQL is misbehaving when using NodeJS as the server model. See my bug report:

Hopefully this can be fixed soon. If not soon, and you need an immediate solution, then you can use PostgreSQL which is a bit more involved than PHP.

When I have the time, I will produce a video showing how easy it is to use another databse when deploying to Railway.app

1 Like
#16

Using Project Publisher, you can stop changes to the database

image
image1527×1108 102 KB

#17

Have a look at

1 Like
#18

Just checked them out, quite a handy service, great for PoC or protos (or services, that do not require EU datacenters)

Thanks for sharing.

EDIT: looks like new data centers are in progress (e.g. EU/Ireland).

1 Like
#19

Thank you, Ben.

I have been testing deployments from Wappler to Railway using Github and a remote MySQL server in Railway (as per your last video). I am also utilizing different targets and environment variables in Wappler, but I have some security concerns/problems.

The setup: Wappler project, Node.js server, remote MySQL server in Railway, and deploying using Github to Railway. I am attempting to use different targets for added secrecy and to protect the production environment.

  1. DATABASE CONNECTION DETAILS AND ENVIRONMENT VARIABLE VALUES EXPOSED: When using Github, your database connection details and environment variable values are sent to Github (github-project/.wappler/targets/name-of-target/databases/name-of-database.json) and can be viewed by anyone unless your Github directory is set to private (a paid feature).
    1.a I suspect that it’s not possible to use .gitignore, as not having it in the Github directory will prevent the deployment from working in Railway. Is that correct?
    1.b Even if I use environment variables for database connection details (set in workflows > Globals > Database Connections), this only changes the config.json file which also gets published to Github (github-project/.wappler/targets/name-of-target/app/config/config.json), thus the environment values are still exposed.

  2. MAINTAINING DATABASE STRUCTURE/SCHEMA ACROSS ENVIRONMENTS: Suppose I work on a local MySQL database for the development target but my staging or production target will be a Railway MySQL. If I don’t use the setup provided above (same database connection but with different values, all of which get exposed when publishing to Github) then the database schema won’t be the same and nothing will function correctly. Is that accurate?

Gracias from Mexico

#20

So far, I have only been experimenting with Railway and think it to be a great alternative to Heroku. I have not used either for production, I am sticking to my old-fashioned host until I am sure that Railway suits my needs.

  1. This is a BIG worry. Have a look at this discussion

I am wondering how the likes of @JonL handles this for Heroku.

  1. I think that the solution would be to use a different database for each environment. This is what I do presently: Wamp server for local development and a remote database for production.
1 Like
#21

Thanks for the kind reply @ben

In the discussion you provided they say to avoid putting the target files in GitHub using .gitignore

I wish I knew that before. Not too much information about how to use .gitignore properly with Wappler :frowning:

1 Like
#22

Environment settings can be managed in the server connect options per target. So you can enter there any environment settings needed for your local development target, but use different ones for your live target that are already available on the server so you don’t have to enter them. @ben

2 Likes
#23

Thank you, @George, for your attention.
I apologize if I am misunderstanding what you mean. As a new user of Wappler, I am not familiar with how the configurations in Server connect can prevent the exposure of database connection details when the project is published to Github. Could you please provide more information or clarification on this?

#24

Hi @ben I had a few questions about how to setup a dev and live version of a website using Railway.

I see https://docs.railway.app/develop/environments but am not sure if it is needed? Since the site is deployed through GitHub I can make any changes I want locally in Wappler and if I don’t want to deploy them, I just don’t push the changes to GitHub right? Assuming I am working on this myself in Wappler is there any need for a live dev site?

I’m a bit more confused on the database side though. Is that where I should use the railway environments or would I be better off just making another database and calling one dev and one live? And how would I connect both databases in Wappler? If I add them both as direct database connections can they have the same name or would it cause issues with my server actions? Or would I make a new target and add the connection there? And if so, would both connections just be local since I am using GitHub to push the changes and not Wappler?

Looking forward to hearing your thoughts on this and thanks for introducing me to Railway, it seems a lot easier for people newer to this.

Oh also, regarding the target files showing on GitHub. If I have my GitHub repo private is that enough to keep it secure? Or should I add to the gitignore? Would adding **/.wappler/targets/ be correct?

#25

Personally, I would always opt for a development environment where I can play around without it affecting the production version. A development database rather than the production database would be part of that environment.

As far as Github is concerned, a private repository would help to keep private information safe, but this is very subjective. How safe is private info when it is kept somewhere in the cloud?

Regarding Railway, you can choose to use it in several ways, one for development, one for staging and one for production. My initial thought was to make it easy ffor newbies to develop a database driven site without having to install local servers. From there on, it depends on further requirements.

Please note that these are my views, other’s views may differ.

3 Likes
#26

I personally agree with Ben in many ways and looking back into my past projects (not Wappler) and the businesses I am working with, I would consider this advices as „best practices“.

2 Likes
#27

Thanks for the info! One last thing if you don’t mind. I have having trouble setting up the database connections inside Wappler and was wondering if you could help.

I have a dev and production environment on Railway

1198×651
that both have a MySQL database.

I add the dev one to the default development target

1332×1029

and it works fine.

For the live version, do I add a new target and just copy the settings from the dev target since I am publishing with Git and not Wappler?

1087×848

and then edit the db connection with the live one for the new target?

1259×1023

when I try that I get an error

Or am I supposed to just use one target and have 2 database connections?

I appreciate any help you can provide.

#28

2 targets, 1 database connection.

Make sure your Globals db connection is not open in a tab.

Set your active target to production.

Open the db connection in Globals and edit the connection as needed. Save the file.

If you then return the active target to dev, and reopen the db connection, you should see the dev connection details.

1 Like
#29

Thats what I did when I got the error posted earlier. Double checked all the settings and now I see

I’m guessing it is because I have http://localhost:3000/ set for both targets but I don’t know what I should have there since I am not deploying to the target from Wappler.