Help Tiny: What would it take for you to use Galaxy? (VERY IMPORTANT!)

Get Galaxy run with Meteor accounts that don’t require local storage for storing login token, so apps can pass basic security audits and make Meteor more interesting to corporate customers.

This came up due to this related post:


This would open up HTTP/REST as an option for using Meteor accounts.

Thanks @veered for this thread

  • If your target audience is small teams, you should make it turnkey: bundle MongoDB (charge more of course). That would bring on board smaller teams focused on results (a bit like what Digital Ocean does. It’s nothing special, except it’s made for smaller teams)
  • Auto-scaling with EBS would bring in the bigger players (integrate redis-oplog)
  • Documentation: make it super easy to start and deploy a new project with sample boilerplates (e.g. no hard-coding of MongoDB URL – since we are using Galaxy it should automatically connect to the DB associated with the install)
  • APM – Kadira needs some love and very few of us have the bandwidth to invest. The code is AWFUL, needs to be cleaned up and made production-grade

PS: You don’t have to host your own MongoDB instances for now, you could work with a third-party provider and have an API into a common Galaxy interface


:smiley: I made a wireframe / design concept for a sprint planning userstory. It seems like a relatively small ask.

  • Autoscaling definitely

  • Actual responses to Support questions would be nice too

I am not a deep core programmer knowing well how to install a stack and make sure all is compatible. I wish to start a real life live version of my project. But I wish to use some technologies together because I feel there is an advantage using them. Not knowing how to put them together, I postpone rather than begin right now.

In my case it would be using Nuxt.js with Vue.js, Meteor.js and Grapher.js (that uses GraphQL). About grapher: Grapher - Collection Relationship Manager + GraphQL Like Data Fetcher.

I would also use d3.js as drawing for dashboards, such as drawing arrows or links or anything around/between data nodes that would be served by their own template. etc. So, 3 levels of technologies that implement a sort of data reactive frontend (Vue, Meteor and d3). It sounds redundant, these 3 levels of reactivity.

About Galaxy, it would be cool to have such bundle already maintained and a prototyping/low volume usage pricing for starting websites before they generate incomes.

Again great to see the engagement of the community. I would assume Tiny wont bet all on Galaxy. It is simply a no-go for most large companies solutions to get locked in to a single… Good leverage when using the momentum the Tiny acquisition brought is key (one off) and deserves enough time for some market analysis together with the community feedbacks. I much hope the journey will be successful.


Lol, adding the button is, but that’s not the feature you want. You want a JSON editor. But Meteor settings are loaded as Node ENV variables when starting Meteor. So to update these settings it needs to restart your server upon save. Then you save and found out you made a mistake, and suddenly your Stripe integration doesn’t work anymore but you can’t figure it out. Oops!

And so your wireframe button becomes something quite complex :smile:

1 Like

Remember days back ago when it was possible to upload examples built with meteor for free. Pretty sure at some point it really helped with organic grow of meteor users. This is especially useful for community created packages and examples.

1 Like

Galaxy is great, but too expensive !!
For this reason I’m looking for another option to deploy, Zeit Now look fine, and offer a free tier option.

If Galaxy stay with this high price, sure lots of people will leave it, like me…

Also, an autoscale should be awesome, lots of people are also waiting for this feature since a long time.

meteor-now is now deprecated, moved to meteor-hero with heroku :


For those of you who currently looking for a way to autoscale, have you checked out this package?


Also, regarding a tool for separated monitoring, there’s this tool by @zodern


I disagree with your assessment that companies would not get locked (after all it’s AWS). Many companies with a deep stack use all sorts of secondary sites (e.g. micro-sites) for internal (and sometimes) external services. IT teams often live in silos and don’t have access to the core hosting dev team that easily (or that team is focused on mission-critical deployments).

If a secure well-vetted hosting platform that is zero-maintenance is available they could easily get corporate approval for it. There is a strong business case for this kind of solution.

I can tell you we would never use such a package. It has to be part of the platform. That’s the goal. If we have to manage it ourselves, it reduces the value of the hosting platform – which is supposed to be set-it-and-forget-it. There is tremendous business value for that


Hello ramez, your case is surely also valid but should not be stated as exclusive.
Sure you have all right and I encourage to disagree, with the purpose of placing different opinions, which is key to best frame the strategical target. (To relate my input; my experience and practice in large companies prime activity IT in past 40 years (yes, old guy, started coding at ETHZ on punchcards, despite mostly management&architecture never lost grip on cool tech stacks, reason of my strong sympathies/support to meteor.
Also since I have experienced a large period in IT history and how, which items evolve or do not evolve). I clearly believe there is the same risk (as I had mentioned few years ago in a post at a similar junction/crossroad of meteor) that exclusive hosting, cloud-service will not allow to fully scale.
It was/is one of the strategy key criterion’s in my job. Particularly in the fast changing times to ‘prevent lock-in’. In the past there was the saying ‘you never get fired for choosing IBM’, very many companies were locked in to IBM (still today with heavy legacy stacks - and massive code volume).

I see continued high potential in Meteor and would consider three strategical vectors to not miss:

  1. Become the top (fully dominant) stack for prototype, stage 1,2, alpha/beta design and development
    The stack which does dominate the starting stage can further influence the full scaling (hosting of applications, micro-macro services etc., supported via well defined/conditioned free hosting as outlined in various posts here already)

  2. Provide full scale production service - Tiny hosting/cloud

  3. Provide flexibility to change 2 to another provider (docker etc.)

The very clear strength of meteor is on 1(-2), other companies will continue to dominate the high-end hosting/cloud service AND IT’S TECH EVOLUTION (here Meteor should best adapt, stay relevant). Tiny may gain major portion of the revenue via services (experts to optimize and help
move from 1 to 2/3 (and between them), subscribe community skills/contracts :wink:

Also perform some UCase friction analysis should be done ‘full’ stacks such as .net
(learn from and minimize direct clash but clear alternative - DIFF/GAP table etc. used for marketing)

1 Like

I agree with lots of the ideas here, particularly the OP and @awatson1978. For us the priorities would be:

  • Improve the price/performance ratio. I don’t mind paying a premium over what a T2/T3 nano or micro costs but I don’t want to pay 2 or 3 times as much for something than has much worse performance.
  • Security. Please add TFA and also add a secrets store for the settings - which can then be accessed/updated like @awatson1978 suggested.
  • Debugging/Profiling: All the stuff @veered suggested.
  • APM: I would try to make the innards of Meteor a bit easier to plug into so people can use the APM of their choice. If Tiny then went and created a modern APM solution that would be great too but maybe the first step is to make it easy to get at the internals.

We left reluctantly, so we’d be more than happy to come back if there were improvements :slight_smile:

1 Like

Biggest problem we’ve had is meteor deploy being broken in Gitlab CI/CD scenario. Also no ability to deploy from Mac, have to be inside a Linux machine when doing a deploy otherwise we get errors at Galaxy runtime.

  1. Return of free plan in addition to paid ones.
  2. Return of all web-sites (I am sure MDG has a backup), it is okay to put a lot of advertising for monetization there. No hoster (and MDG was a hoster) would make such move like MDG did. But it is never late to say ‘I am sorry’ ). Of course, I understand that half of them would be outdated but it is someone’s work and effort.
  3. Return of ability to magically post your web-site online.

Let us make Meteor magic again )


I actually had 6-8 galaxy containers continuously for a few years, with a huge bill of like $400 a month, and switched to mup eventually to save the company money. I’m sorry guys, I am just glad I was able to support MDG for as long as we could hold out. I’m actually happier with mup in the end because it’s just a lot FASTER. Everything on Galaxy is SLOW SLOW SLOW.

Galaxy is adequate, but I never truly loved it (especially considering the price). We need to transform it to be a magical leap over mup, even after you account for the initial investment setting up mup. What can you do to provide that?

  1. Start with similar pricing to DO - Make people think “should I even bother learning mup?! It’s not really going to save any money” This is going to immediately bring you closer to your goal; adding to the cost is going to make it harder to be a leap over mup.
  2. Simple mongodb hosting - But, don’t make the same mistake by boosting the price on what is really a simple server. IMO mongodb is super easy to set up, even accounting for making it production-ready. Much easier than node apps which are riddled with “gotchas”. I could add this to galaxy in a matter of months. Low risk, high reward for you guys.
  3. SPEED needs to be addressed for every single last operation from sluggish to INSTANT!
  4. Just echoing… Leverage Galaxy to provide free hosting again. This will help user acquisition!
  5. I don’t want to go into galaxy ever. Galaxy should replace our IT guy.


Honestly I’m not sure Galaxy even helps people pick meteor to begin with, it’s not like hosting and deployment isn’t covered already. Unless galaxy offers a free tier, it doesn’t really help get developers to use meteor.

Honestly if I were tiny I wouldn’t bet on Galaxy but I would explore other options that leverage the advantages of meteor itself. I’d make a remote team of skilled programmers that were available for contracting along with a good sales team that can drive meteor adoption. Manufacturing and defense markets are in sore need of reactive data, and thousands of startups are in need of modern sophisticated web apps.


I have used Galaxy for a few projects and I liked it very much. The UI is nice, assigning SSL certs is great and I love not having to do SSR because of

The reason I left was that it was just so expensive. All my apps are now hosted on the Vultr platform, using MUP to deploy. It’s slightly more work to deploy and update my apps, but so much cheaper (especially because I can use one server to host multiple apps). All-in, the cost is about 10% of what I was paying on Galaxy.

That said, I’d love to move back to Galaxy, especially if it supports the long-term development of Meteor. My preferences are:

1 - Much cheaper pricing
2 - Autoscaling
3 - Inclusion of APM as standard

And, just to provide a different opinion to some of the other voices in this thread: I really don’t think that it’s important for Galaxy to provide database hosting (it’s so easy to use an external service for this), and I don’t think it’s important to have free deploys either.