I'll start by saying you probably shouldn't take critical infrastructure advice from strangers on the internet.

That said, I've moved off of both a VPS and other hosting platforms to Railway and have been pretty happy while using similar tech to what you're describing. It's less maintenance than managing baremetal VMs and often cheaper too as you only pay for what you use. You don't have to overprovision for bursty traffic.

Does Railway support your workloads

Let's go through your list point by point and see if Railway would support your workload:

• Keycloak: Railway has a popular template for this already Deploy Keycloak | Railway

• Node.js & Express: Railpack (Railway's default builder) supports node.js well, but they also fully support OCI compliant containers. If you have a Dockerfile, it will run on Railway.

• PostgreSQL: Railway supports this database out of the box and has support for backups / restores / plugins. PostgreSQL | Railway Docs

• Next.js: self-hosting Next.js is a PIA to host anywhere that isn't vercel but Railway is a good a spot as any

• Docker & Kubernetes: Railway runs on Containers; that's how everything works behind the scenes so you won't need K8s and docker workloads are fully supported

• Redis MQ: Railway also supports Redis out of the box; just like PostgreSQL Redis | Railway Docs

• Resend: don't see why not; there's an official example of how to deploy with Resend on Railway here: Deploy Resend | Railway

• PDF Generation: sure, just setup a worker service and it can handle the PDF generation

• CRON Jobs: Railway supports cron services which imo are easier to manage / have insight into than bare metal crontab. read more here Cron Jobs | Railway Docs

How would you recommend migrating

As far as recommended approach for migration, there's literally an entire section of technical literature on migrations and rewrites so that's up to you.

If you're asking for my advice, I would suggest starting with one service or workload at a time and migrating incrementally.
That keeps things low-risk and you can revert early if you're not happy.

For example:

• Identify a non-critical workload (analytics microservice, non-critical cron job)

• Adapt the workload's services to Railway and create a deploy strategy

• Deploy on Railway in a staging / test capacity; test the workload and ensure you're happy with it.

• Deploy on Railway to replace production; spin down your old production in tandem (do backups and all that)

• Monitor the service on Railway

Then repeat those steps until your whole infrastructure is moved over. That's a bit oversimplified but the general approach should work.