Moving your app can be stressful for those looking to move off of Heroku. Railway makes it easy. This guide will walk through what we offer and show, not only tell, how to migrate your app from Heroku. We promise it'll be quick.
Railway is a simple and powerful deployment platform. Software is hard enough; thinking about deployments is a rabbit hole we don't want you to worry about. Give us a GitHub repo, and we build and host it. Contrary to our name, we aren't a Rails-only hosting service. We support over 20+ languages and runtimes.
Other products seek to replace the magic that Heroku offered developers; we think Railway best philosophically fits the mold of having you focus on your code, not infrastructure.
Just like Heroku, we offer…
Users tell us that we really shine in the following...
If you want to know more about the features that Railway has, you can see our docs here.
We'll walk through an app from Heroku over to Railway. This guide applies to any language your workload may use. However, we will use a Rails 7 app with Postgres as an example.
You can follow along with the same steps for your own workload!
This guide will walk you through the following on the platform.
You should see an open Command Palette ready for your input. Select: "Deploy From GitHub Repo"
If you haven't, log in with GitHub.
Then select: "Configure GitHub App." This will allow Railway to deploy your code from your account.
Then select the repo you wish to deploy. We will go ahead and deploy our Rails repo.
You will then see the Project Canvas, a blank slate to espouse your applications into existence. Finally, you should see one or multiple services building and deploying.
Clicking on the service opens a panel to see your build logs. This is where we will later add domains and variables. But, first, let's put a pin on this and explain what just happened.
Railway detects if there is a Procfile at the root of your repo. Then we map each Heroku process within the Procfile into a service. We even carry over the name of the process from the Procfile.
It’s likely you have some DBs that your app is talking to, let’s import your Config Vars from Heroku to have your app talk to them.
On Railway, with the exception of Database Environment Variables, secrets are scoped to the service within Railway. We offer a variable import from Heroku.
Within your service’s variables pane, Command + K and type Import Variables From Heroku. After you complete the prompt, you can run the import on any and all services that need variables from your old project.
Alternatively: if you are using a .env file within your repo, we offer an easy GUI to help facilitate the import called the RAW Editor.
Click into your Rails service on Railway select the Variables table and then click the RAW editor. Adding variables to a service triggers a redeploy to make your application aware of the secrets.
Now your code should be running on Railway but using the Heroku connection strings. In the next section, we will set up Database services on Railway.
Zooming out. A mental shift that we see reported from users when they move from Heroku is process scheduling and management. Those familiar with Heroku know their application runs on a Dyno than can be vertically or horizontally scaled.
To handle the start command of the user’s application. Heroku would use a Procfile to handle a single or multiple process running on these Dynos.
Heroku has this system to allow developers to scale these processes independently of each other.
Our Heroku Procfile for a multi-process deployment looks like the following:
web: /bin/bash -l -c "bundle exec puma -C config/puma.rb"
worker: /bin/bash -l -c "bundle exec sidekiq -e production -C config/sidekiq.yml"Like you just witnessed: we support Procfiles out of the box. Any named process within a Procfile should build and deploy normally, without any further intervention on your part.
On Railway, Projects have multiple Services. Services are just deploys of code/image. There are two types of services: Database Services and Code Deploy Services.
We already have our code deployed, now let’s spin up our database services.
Our Rails app needs Redis and Postgres. (Your app might need them too.) Lets navigate back to our Project Canvas. Press Command (or Ctrl) + K and type in “New Service”
Navigate to “Database” and then “Add PostgreSQL”. Repeat these steps and select “Add Redis” for your Redis instance.
After a few moments, you should see it pop up within your Project Canvas. DBs on Railway have Table View GUIs, Manual Queries, and much more.
Railway by default injects DB variables into all services within your Project. Just like Heroku, we use the env var name DATABASE_URL for the connection string for Postgres and REDIS_URL for Redis. (If your Heroku variable import imported these Config Vars, you’ll need to delete them from your variables else it will overwrite the Railway connection strings.)
Slam a commit through for now or manually add a variable to trigger a redeploy. (We know… redeploy button coming soon.) On a new deploy, these variables will be sourced in. Everything should work now.
It’s very likely that you have some data on Heroku that you’d like to bring over. You can follow our tutorial on how to backup and restore your PG database here.
As your application grows, Railway will let your application consume more resources depending on the plan you are on to scaling vertically. No need to resize a dyno or look at 5 by 20 matrix to decide witch instance is right for you.
You can spin up additional services to meet demand and use a reverse proxy to coordinate them together similar to adding additional dynos. (Built in horizontal scaling is on the roadmap)
One really cool thing about developing and deploying with Railway is the ability to pull down your variables locally so you can use your cloud infra. No need to run local versions of Postgres.
Example, running a migration from your terminal is as easy as:
railway run rake db:migrateWhen you preface your command with railway run we pull down your variables locally. No need to SSH into your Rails app any longer.
Many people coming from Heroku are big fans of how easy it is to just type git push heroku master and get a new deploy of your code going. We have something similar with our CLI.
After you railway link or railway init to your project, you can trigger a new deploy from your repo’s root within your terminal with:
railway upIt’s snazzy, try it out!
Railway by default assumes the code you want to push doesn’t always need a domain. Web services on a Procfile always get an autogenerated domain and cert. We’ll show you how to get a Railway provided domain to expose your app to the internet.
Within your service, under Settings, the top menu has an option to use a Railway provided domain, or a custom domain.
Generating a domain will give you a customizable domain that will use the *.up.railway.app wildcard domain.
Not all apps listen on Port 80. Railway will do it’s best to guess what PORT your app is running on to expose it but that information is best provided by you.
The easiest way to get up and running is to have your application listen on 0.0.0.0:$PORT, where PORT is a Railway-provided environment variable. You can manually override the PORT environment variable by adding PORT to your service’s variables page. (Command + K and type Variables or you can use the keyboard shortcut: G + V under your selected project)
Railway not only supports Rails, but Node, Python, Clojure, Elixir and much more out of the box. We have 40+ templates to get you going ready to be deployed in minutes.
If something didn’t quite work out, please let us know! We are very active on our Discord where the community and team are actively helping out of issues of all types. If you see anything within the product that can be improved: we have a feedback page just for you.
We can’t wait to see your projects here on Railway. Tweet at @Railway and let us know what you are hosting!
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。