#Help moving large apps from Heroku to Railway

10 messages · Page 1 of 1 (latest)

mint haven
#

My team has a large ruby/graphQL/postgres/redis app and also a node app that currently runs on heroku. We have another node app now running on railway and we love it, and we’re itching to get our other apps over and pay y’all more money. The problem is we aren’t seeing how we can SSH into our apps and run regular operational commands which arise in our organization’s day to day operations.

Some example use cases:

  1. Using a Ruby REPL or running a Ruby script to query our Postgres database or Redis database
  2. Using a Ruby REPL or running a Ruby script to made modifications to our Postgres database or Redis database
  3. Using a Ruby REPL or running a Ruby script that, among other side effects, enqueues jobs to our Sidekiq worker queue
  4. Using a Ruby REPL to debug code pathways, which may or may not interact with our database, including introspecting about the server and software environment when necessary

Roping in one of our engineers (@urban wharf ) so he can add some more context or examples as needed. Anyway, creating a UI for each of these use cases isn’t feasible so is there a sane alternative to SSH that could solve these problems? How are other railway users solving these problems with larger production apps with these needs?

rocky geyserBOT
#

Project ID: N/A

mint haven
#

N/A

lone hawk
#

1 and 2 can be done through a local REPL with railway run (runs the repl locally but with the linked service variables available)
3 and 4 would need ssh access, other users have done this by running tailscale in the container

urban wharf
#

thanks @lone hawk

#

we're familiar with those options, but they seem very hackish and were hoping for something first-party

#

regarding railway run, we have a number of concerns

  1. we have multiple developers on the team, so our local code can easily get out of sync with what is in production. Obviously this is not an insurmountable challenge, but it is unneeded cognitive overhead when things are going wrong
  2. we place a significant value on having environmental consistency between production and staging, and this introduces a huge gap. Devs are using either Linux or Mac, and their software stacks might differ from what Railway is using. When tracking things down, the details matter
  3. for better or worse, this makes it easy to make changes to your code before you run a script or open a console. To me, this could come in handy but could also be dangerous. We have a review process for a reason. Ideally we'd be deploying to production and then working off of reviewed and tested production code
#

I've read up on Tailscale and it seems like it should work, but more or less fits the definition of a hack

#

our ideal environment would include some sort of run infrastructure like Heroku does, where you get a brand new instance every time you connect your REPL or run a script. SSH feels like a passable second choice. Tailscale feels like a viable but unfortunate way to do that

lone hawk
#

i hear you, theres definitely a need for ssh or similar way to run a command in the container in this case, but unfortunately railway doesnt provide a way to do that 1st party, ive heard they are debating it since there are many more use-cases just like yours, for now the only way around would be the hack that is using tailscale