I’m all fired up with Meteor 3.5.1 on Galaxy Metal, and I thought I’d write a quick post mortem for those interested.
First and foremost, everything is much quicker. I run a single quad container and on metal it’s definitely faster than on the legacy infrastructure. Combine that with Meteor’s change streams where my publications are way faster & more efficient (almost doubly so) and my app has got a fantastic performance boost courtesy of the Meteor/Galaxy teams.
Congratulations & thanks, guys - great progress 
.
My Metal migration wasn’t a smooth experience, but it’s been worth it in the end. I’m going to list the things that went wrong as “lessons learnt” so any future migrations work better (though I’m told that for the vast majority of apps, there were no problems. I guess I was unlucky 
):
- Migration was substantially behind schedule as advertised in 2025
- Despite agreeing to a forewarning, my migration was made without one (and it had to be reverted)
- The migration necessitated me to update, and refactor the use of, a few 3rd party libraries my app used as they would not build on metal - contrary to the “seamless” promise.
- The setup was initially wrong such that I had horrible latency for a few days between the metal server and Atlas DB
- The killing of sockets every 30 minutes that the new proxy servers now employ, caused subscription storms and performance issues - until I upgraded to 3.5.1. A policy I still have issues with.
- External HTTP calls to the server now time-out (within a minute, I think) - they used not to. Again, a change that I’ve had to adjust my system to cater for (though admittedly for the better)
And at one point, a reversion to legacy failed to work and my server was completely down for an hour or two. This highlighted the fantastic record that I’ve had with Galaxy since I started - my server has never been down for 7 years!
So, here’s to 7 more years of continuous up-time and super-improved performance 