I really hope it can be get better. The main reasons were:
Competitor charges $9/mo, push-to-deploy simply works, super easy.
The ideal is: write an app. Push to deploy. Nothing more.
Can I ask where you moved to?
Hey @trusktr, sorry to hear that.
Ideally: write an app. Push to deploy. Just it.
We plan to get there. We are evaluating how we could provide MongoDB for production. Possibly we will create integrations with other service providers, but this is still in the research phase.
About the P2D issues, I remember helping you with an issue in the past that got resolved. Did you have any new problems? It would be nice to know more details about this.
Our support team can always help with specific issues at support@meteor.com.
And I’d be happy to help you personally if you email me at fred@meteor.com.
I went to NodeChef for now. Push to deploy is working great first try, plus with Mongo DB included, so that was really easy.
when payment doesn’t happen with credit card on a Friday, there’s no way in the UI to pay with credit card again and you’re not gonna get a hold of anyone all weekend, and are gonna have a weekend-long downtime unless you make a PayPal account. The UI accepts only PayPal payments during this scenario. Really weird. lol.
Will be great!
Did you have any new problems
We did, but rn I don’t remember. Sorry I’m not so helpful here. Will be glad to try again later and report new issues.
I’m not a paid user of gallaxy as it’s not providing anything more than a scalable app.
I created everything on digital ocean as I trust their uptime. I really don’t like devops and could be happy to be in gallaxy but it’s current features are not good enough.
This page is showing what should gallaxy be
Meteor.js Hosting | Lightning Fast Meteor App Hosting | Deploy Meteor.js to NodeChef Cloud
only mongodb is not enough for many, scaling both mongo and redis are big requirements. Besides that using s3 on gallaxy could be a plus.
I’m using AWS for my app, MongoDb Atlas and Redis (at Redis itself). I prefer to leave MongoDb and Redis to the best experts out there, which is the companies that own and run their software.
AWS hasn’t given me any trouble, I’m using CodePipeline which works seamlessly to build and install new versions of my frontend or backend app. Upscaling and downscaling is obviously part of AWS, so it’s all in your configuration files or via their UI (which has gotten a lot better than it was some years ago).
Also all 3 companies provide 7x24h service, with different higher (paid) service levels should problems occur and you really need an expert to work on them.
I’m running my own company and I don’t understand why some owners of small companies don’t work a couple of hours over the weekend or holidays to fix urgent problems of users or at least communicate back to them. The customer should always come first but maybe that’s again a personal preference.
I will add my bit here too. I recently also moved away from Galaxy (to AWS).
price - Galaxy compact container (512 MB RAM) is $29, while on AWS, the nano container is $4 (512 MB RAM).
prerender - there is no control and it got really frustrating at some point (the pages were not being recached and google console kept complaining about it). I tried to set up my own account, but that was frustrating too and I could not somewhat fit in the free tier (which was likely my mistake) and the next cheapest option was $99 (there are other cheaper competitors though). So I moved away from prerendering to SSR and I am very happy about it.
mongo - not really an issue for me. I was ok with the Atlas free tier. My app is quite small and have only a few documents in the DB.
no naked domain redirect. I had to set up pizza.redirect. It worked well in the end, but it was another thing to care of. It is simple to setup in MUP without 3rd party redirects.
APM - it is not a part of the essentials package. I am only trialling it for now, but MontiAPM is $0/$5 compared to $11 on Galaxy. I like that I can try it out for free first and if I am interested to keep ~1 week of logs, only then to start paying.
Information about cost is difficult to find or make sense of because of a 3rd party subscription provider. In AWS, you get estimates, current cost and very detailed breakdowns.
I don’t use P2D or scaling for my apps yet. I liked the Galaxy deployment process and displaying the logs on the web and basic monitoring (monitoring RAM in AWS is complicated and costly). It is also much easier to manage it than the whole AWS infrastructure. I had a lot of expectations from the included prerendering, which was the major reason to try Galaxy, but that was not working for me.
Sounds good man, when your app goes large and you have traffic then AWS will be a burden also so I recommend getting a dedicated server in that case. But not until the bills are over $1k a month or it wont make sense
I am in the process of moving off of Galaxy as well.
It pains me to do it, but the pricing is just too steep, especially without mongo.
Also, the performance you get on Nodechef for $9 is off the charts.
Cheers, I’ll be happy to switch back or consider Galaxy for future projects if things change!
Hi @gabri,
I am not using Galaxy and no disrespect to your plans and decisions but … I am not sure I understand the comparison here.
For $9 with Nodechef you get almost nothing (Pricing | NodeChef). If you are announcing a hobby project leaving Galaxy, that is ok, it is true, Galaxy is not great for nano projects. It is more for real businesses with real usage, businesses that make a profit.
Hey @paulishca. The performance of the $9 Nodechef is actually way better than the Tiny or even Compact containers from Galaxy (in my experience, also keeping in mind that it includes Mongo with almost no latency).
Have you tried comparing them?
The CPU power galaxy offers for their lower tiers is just very small, even for some small projects.
And yes, I am talking about a platform that makes a good profit, with 100-500 visits per day and heavy use in some cases (it’s a game).
Currently paying for Compact + Mongo Atlas, even if I don’t end up in the lowest tier of Nodechef, It’s worth the switch for me.
This was our experience as well. Sooooo much faster that users were delighted and commenting on it after the switch. The forums are filled with people with similar experiences. I hope one day they’ll address it.
I use both Galaxy and Digital Ocean. Personally, didn’t notice much performance difference but Galaxy is more expensive (I use two standard size containers), however it does provide a lot of extra features and it has bene running for years without issues.
I also personally feel better supporting the team that maintains the underlying open source software I use.
I use both Galaxy and Digital Ocean. Personally, didn’t notice much performance difference but Galaxy is more expensive (I use two standard size containers), however it does provide a lot of extra features and it has bene running for years without issues.
I believe Galaxy runs Kubernetes so maybe it’s a container issue and not so noticable compared with Digital Ocean (I’ve never used it so no idea). Possibly a better comparison method is needed as typically people just mention vCPU (or ECU in Meteor’s case) which could mean anything (although in AWS they are quite specific about what you get). But try spinning up the most minimal EC2 instance and you’ll see what we’re talking about.
I also personally feel better supporting the team that maintains the underlying open source software I use.
Yes, I’m with you on this. We’d love to. I hope they improve things and tempt us back.
Maybe, I have not used AWS, only Digital Ocean (smallest droplet), but I trust your observation.
Personally, I don’t see any performance issue with my app on Galaxy (the standard containers), and for me, the DevOps features galaxy has reduces the mental space of concerns, so it is worth it in my opinion. I would rather focus on features than DevOps. I guess it boil down to tradeoffs.
As long as my app is fast and I have less things to worry about l, I don’t mind paying more especially to support the team behind Meteor. I have seen a team dedicate two resources for more than 3 months to update Ember CLI to node 16, meanwhile folks here are a putting tons of effort to make this happen while minimizing breaking change, so hosting on Galaxy is one way to pay them back.
I’m not affiliated with Meteor team in any way, just sharing my own experience and thoughts and I have been running those apps for years now with literally zero DevOps 
On Galaxy at the moment with similar thoughts as @alawi - a way to support the team. The easy devops (vs my experience with AWS) is a nice bonus although I do wish the performance was better.
I know every few years there’s a What’s The Current State of Leaving Galaxy Like? article. But we’re actually wanting to migrate from Galaxy this as well, mostly for cost savings as we launch a few new apps. The service overall is great.
Our team has been researching. Something that’s essential is having the ability to add multiple custom domains that have SSL enabled dynamically on the fly (like Galaxy does with Let’s Encyrpt). What’s the current state of:
It does seem like there’s a lot of forum users on here that are successful at rolling their own solution or some combination of it and the above. Just wanted to ask, again.
Meteor up does set up let’s encrypt, though you have to list all of the domains in the mup config. Depending on how dynamic the domains are, you might want to consider using Caddy for ssl and load balancing - you can configure it so you don’t need to llist the domain names, or use its api to add domains to the config.
The package is stable, and many companies use it in production. There are a number of things that could be improved. The project is accepting PR’s, or I am available to do sponsored work on it.
It uses AWS certificate manager, and currently only supports verifying domains by email so it might not work well for dynamically adding domains. There’s been some changes to their api the last few years, so it might be possible to improve it.
This may be true. But we have to keep in mind Meteor itself: it is an amazing tool for a even a one-person team to prototype a whole app very quickly, what would otherwise be tons of effort or require multiple people to make it manageable for a business.
With this in mind, being able to provide a plan that aligns with the one-person entry level project is key. And then let them grow to bigger plans as needed. But the entry-level for Galaxy should be just as great as Meteor is for entering full-stack as a one-person team.
Right now, NodeChef provides that. And once people are happy on a platform, they may not want to switch. So I think, business wise, revising Galaxy’s entry-level is key.
Why are we sharing these thoughts for free? Well, we like Meteor! We hope it will succeed so we can keep having a simple (for end devs) full-stack solution. This is the most valuable advice we here are giving to Meteor the business. We’re happy to voice our concerns, because we hope it improves the primary hosting offering of the full stack system we believe in.