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:
https://forums.meteor.com/t/security-dont-store-tokens-in-localstorage/
This would open up HTTP/REST as an option for using Meteor accounts.
Thanks @veered for this thread
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
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 hosting.cloud… 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 
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.
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.
Edit:
meteor-now is now deprecated, moved to meteor-hero with heroku : https://github.com/jkrup/meteor-hero
For those of you who currently looking for a way to autoscale, have you checked out this package? https://github.com/pathable/meteor-galaxy-auto-scaling
Also, regarding a tool for separated monitoring, there’s this tool by @zodern https://github.com/monti-apm/monti-apm-agent
@hherrmann
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.
@harry97
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:
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)
Provide full scale production service - Tiny hosting/cloud
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 
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)
I agree with lots of the ideas here, particularly the OP and @awatson1978. For us the priorities would be:
We left reluctantly, so we’d be more than happy to come back if there were improvements 
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.
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?
OR JUST DONT?!1
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 prerender.io.
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.
