We've also been running Rails in production for 15+ years (since 2011) in two companies and it has been serving us greatly. Hiring is tough, but I definitely believe the stack makes up for it due to the productivity gains.
In late 2025 we decided to migrate one of them to Inertia. Public facing pages is already done, and we're 80% through migrating the logged in area (it's a huge app). We choose Vue.js.
It's amazing how powerful this stack is and how little you have to change in the backend.
I'm surprised hiring is tough. The job market is such trash rn and I feel there are a lot of Rubyists, or ex-Rubists interested in returning to it, around. Maybe not? (Edit: spelling)
Off-topic, but I'm having a terrible experience with Cloudflare and would love to know if someone could offer some help.
All of a sudden, about 1/3 of all traffic to our website is being routed via EWR (New York) - me included -, even tough all our users and our origin servers are in Brazil.
We pay for the Pro plan but support has been of no help: after 20 days of 'debugging' and asking for MTRs and traceroutes, they told us to contact Claro (which is the same as telling me to contact Verizon) because 'it's their fault'.
Do you think cloudflare is responsible for all of the network traffic routing in the entire world and can simply fix any problem even if it's on somebody else's network?
No. I do think that Cloudflare is a great company and got where it's at today because they care for this type of issue, and has a much better chance of contacting their peering traffic partner than me because they take care of ~20% of all internet traffic, while I take care of none.
Sometimes it helps to also provide a drawio file that has the elements you wan't (eg. cloud service icons or whatever), but you just feed it the content you want diagrammed and let it eat.
Even if it's not completely correct, it usually creates something that's much closer to complete than a blank page.
One Rails app self deployed in VPS can really go a long way.
I'd add:
- Learn tailscale. It's one of those technologies that takes half a day to get used to (claude code will answer all your questions), and you'll never want to live without it in the future. SSH into your VPS, install tailscale and use `tailscale set --ssh`, and shut down `systemctl stop ssh.service`. You don't even have SSH daemon runing anymore, extra safety.
- Use a simple docker compose to run your dependencies like docker. Bind to the tailscale IP, so ports: {{ tailscale_ip_of_this_server}}:5432:5432. This way your database is not exposed to the web, but it's exposed to the tailscale. Use tailscale_ip_of_this_server in your ENV vars to rails to connect - since it's running in the same server, tailscale will route it to localhost (and with localhost latency).
- With claude, set up a second VPS, add it to the same tailscale, turn of SSHD. They can now connect directly via tailscale (try ping or sshing between them).
- Then, install claude code on this second VPS. Since postgres is bound to the tailscale IP on the main, the 'slave' can connect to it. Install postgres via docker, but have claude set up a 'streaming replication' between server MASTER and server SLAVE, using tailscale ip.
100% secure, encrypted, and now you have a postgres replication with zero data loss if something goes wrong.
In the same SLAVE, you can also install barman - claude code will help you set it up.
You then have a postgres BACKUP with point in time recovery.
I redeemed my 50 USD credit to give it a go. In literally less than 10 minutes I spent 10 USD. Insane. I love Claude Code, but this pricing is madness.
The biggest selling point to using Postgres over qdrant or whatever is that you can put all the data in the same db and use joins and ctes, foreign keys and other constraints, lower latency, get rid of effectively n+1 cases, and ensure data integrity.
I generally agree that one database instance is ideal, but there are other reasons why Postgres everywhere is advantageous, even across multiple instances:
- Expertise: it's just SQL for the most part
- Ecosystem: same ORM, same connection pooler
- Portability: all major clouds have managed Postgres
I'd gladly take multiple Postgres instances even if I lose cross-database joins.
Yep. If performance becomes a concern, but we still want to exploit joins etc, it's easy to set up replicas and "shard" read only use cases across replicas.
In late 2025 we decided to migrate one of them to Inertia. Public facing pages is already done, and we're 80% through migrating the logged in area (it's a huge app). We choose Vue.js.
It's amazing how powerful this stack is and how little you have to change in the backend.
reply