Using the meteor.com domain is problematic. I think you can use *.meteorapp.com domain when using Galaxy.
No problem about .meteorapp Just return the magic! )
Why are you guys not using DataDog? No one can compete with them IMO. Happy user and then have a ton of new features every couple of months.
Canada would be really beneficial to our business at the moment.
For some of my Deployments I use Nodechef, things that I like about their hosting are:
- Static hosting, easier to setup SEO ready landing pages and have the app separate.
- Bash scripts to add or adjust plugins such as wkhtmltopdf - which is WAY out of date.
- included mongo database, for those projects that don’t need a huge setup
- smaller containers on the cheap with database and static hosting
only thing that I wish they had was the ability to create a container via CLI, I would love the ability to create dynamic projects. Other thing is no Database interface but Robo 3T works fine.
The deal-breaker for us, literally, with Galaxy, is the performance of the app. Using small containers on AWS just blows any Galaxy container out of the water for raw speed, which we need for a lot of reactive updates and heavy crunching in our simulation. I wish there was a performance tier available on Galaxy, or that the containers themselves were burstable, that is probably the biggest problem.
The things you mentioned, performance and support for Google Cloud and we move back to Galaxy.
Hi Jorgen, with “performance tier” you mean more container sizes (like 8 GBs / 8 ECUs, 16 GBs / 16 ECUs) or what do you mean exactly?
The experience we had is that even with the 1GB the performance was lower than a similar instance on Google Cloud.
Definitely higher ECU, or burstable performance.
We had similar performance problems. The compact galaxy container is basically half a t2.nano’s CPU (the smallest on ec2). This compact container costs ±30/month (40 if you include Kadira). A nano - which has double the CPU of that compact container cost 4/month. And for more intense work you can use the t3.nano which is burstable as well but with 2 ECU.
Then there’s also the load balancer. This costs about 16/month in AWS. I’m not sure how Galaxy implements this, if they launch one per app or if they manage to use one for multiple apps. I’m hoping it’s the latter.
It would be nice to see the performance increased and/or prices reduced.
Long gone and never looked back again. We’re using Terraform and a complex CI/CD environment on AWS plus our own Beta System on Linode with several systems running on it.
Cost wise, support wise (working outside of the US means we never got Galaxy support on our regular sized app, especially on weekends).
Cost went down (on a like for like comparison) and we now have both systems for the same price as we got Galaxy which was just running our app without lambda, Fargate etc
I believe @msavin built this out a while ago with very reasonable pricing! https://montiapm.com/
Yes, that’s what we currently use. I don’t know if @msavin is involved. But that’s the platform of @zodern I was referring to. I can recommend it. We have a couple of our environments on the paid plan, and it’s been running stable in the 2 years or so we use it.
Mm yes I meant @zodern my bad I recommend it as well, its great! I confuse the two people bc they both produce awesome stuff
I’ve published the same roadmap that we have here now in a permanent link https://github.com/meteor/galaxy-roadmap/blob/master/README.md
We will post updates in this readme.
Hi,
I am thinking now
- built-in CDN would be a great feature. Waves and MUP uses AWS CLI (I think) to generate the AWS environment for EBS. I am wondering if a similar approach would be possible for S3 + Cloudfront so that the developer only focuses on keys to enable the feature and check whatever he/she wants to pay (size and region).
- Push. For Push, a user needs some Google keys, some Apple certificate and that is pretty much it. I wish Push in Meteor would be a … checkmark where I just enable it at a cost and only have to deal with the client side (mainly listeners). The Push method could be made as abstract as the Meteor Email. The server side of Push has no dependency on all the Cordova misconfigurations, bugs of the push plugin. Push to PWA and browser are in huge demand for those web apps that cover loyalty, news or getting a user hooked for any reason.
The Public API feature sounds great. To be able to Meteor.connect
to specific or all containers retrieved from a list of current Galaxy containers for an application would be beneficial. Sending messages between containers, etc. This would eliminate needing to use 3rd party tools (e.g. redis) to do similar things.
Tho, to be honest, we still have our eye on moving our 7x double-container app off of Galaxy all together. It’s just too expensive. We would probably save $600 - $900 per month. Just debating if that’s worth the headache.
Adding the AWS region eu-central-1
(Frankfurt) would be nice. Mongo Atlas doesn’t offer eu-west-1
(Ireland) so at the moment, when deploying Meteor to Europe and using the Atlas service the app and database servers can’t colocate in the same region.
Mongo Atlas doesn’t offer
eu-west-1
(Ireland)
You can use all tiers (including the free M0) in Ireland. I have a several Atlas clusters running in eu-west-1
.