Can you please give some insights here? I mean mostly you just increase containers as in Galaxy, no? They also have built in fairly intuitive load balancing, dns setup and soon to come advanced monitoring like galaxy has it.
Would love to know where you’re struggling 
TBH I thought the whole Kadira APM stuff went fully Open Source since Arunoda announced the shutdown 
Kadira announced that they’re releasing an open source container you can run to host your own Kadira. MDG will be offering their own hosted solution so you can pay for it if you don’t want to deal with hosting and dev ops for your APM
Hey all - as a follow up we’ve appended a set of answers to questions we’ve gotten about our plans around Kadira:
So users who don’t use Galaxy for good reasons can still not pay you back for an important tool like Kadira, because only Galaxy users can use the hosted solution (and also have to pay for it)? I really don’t get this business strategy, it’s the opposite of extending the target group 
I would really love to pay for it but you don’t let me 
This should be the main topic for the next Transmission!
Well I think that’s an important feedback, you want to pay for MDG but you’re not finding it easy. To further your point @XTA, I’m assuming you’re not currently deploying on Galaxy, could you please elaborate on that decision?
This went from “Great news!” to “Still in trouble…”. Like @XTA, we use Kadira a lot, but do not use Galaxy. (Heroku is a very powerful and perfectly working alternative, with little setup). We would love to pay for just the monitoring. Looks like we still need to spin up an open source version and host it ourselves in the near future. Of course it’s still great news that there will even be an open source version, but it’s sad news that we’ll have to invest in something that just worked.
So thank you for the open source alternative. Maybe we, the community, can make it even better than it was already. (Thinking of a user filter on errors anybody? 
)
Sure, there are several reasons why I wouldn’t deploy on Galaxy (don’t forget this is only my personal point of view):
1. Galaxy is new and MDG is not a hosting company
In this case I don’t know if they will still exists in 1-2 years. If you see how they had shut down the free hosting (the first announcement came 2 weeks before the planned shutdown), this is not trustful to me. The free hosting was uneconomical, I totally understand that. But how can a company ignore that they have to pay 10.000$ per week for a free demo hosting for such a long time? The shutdown should happen much earlier, so I had the impression that something internally goes wrong.
If Galaxy doesn’t make enough money, will they erase all data within 2 weeks too, because they recognize the economic situation too late? Another reason is the missing MongoDB hosting. Galaxy should be the #1 Meteor hosting solution, but MDG is not able to provide MongoDB hosting, because it is too difficult. How should I understand that? The guys who choose MongoDB for their strack and now want to provide a hosting solution, don’t have the knowledge/resources to provide a full service hosting solution for their own framework? This would lead mead to the question if this whole Galaxy thing was well planned and if they have enough employees to provide a professional hosting service?
2. Support
If you take a look into the forum, you will see some threads like this one. Some people got an answer after 9 days of waiting. This isn’t acceptable and would be a reason to cancel a contract. Also no one from MDG has posted an answer or information within that thread. Would a professional provider do that? If someone searches for Galaxy hosting and will find that posting without any statement from MDG, he may choose another provider. This only happens if companies are not well organized (I know that some bigger providers also have such issues, f.e. some departments of OVH). But this shouldn’t happen, especially if you are small.
3. I want to be flexible
Most of my/our applications are not only Meteor apps. We also use some Express apps that are connected via DDP to our Meteor server and provide some services, f.e. file uploads or video conversion. They are running on single VPS systems or dedicated servers. If I use Galaxy, I have to stay at the Amazon ecosystem if my servers should be located in the same data center. But Amazon may be not the best economical decision, there are also some others providers which may be cheaper and provide some features that I would need.
I should think that, if Galaxy were to be shut down at short notice and everything erased in a space of 2 weeks*, not having the DB hosted there would be rather a big plus.
* Not that I believe that anything of this sort would happen with Galaxy, where people are paying to use it.
Sure, in this case this would be a big plus, it’s also possible that this can happen on any other provider, too. I’ve just listed it becaused it has happened in the past (I also know that MDG has extended the dead line, but that 2 weeks gave me a bad feeling about their internal organisation which is something that I can’t ignore when comparing different hosting solutions).
Thanks for sharing your personal experience and opinion XTA. Let me share my perspective on some of the points you raised:
On Being New
I’d say every new business initiative starts from somewhere and Galaxy as it exist today is specific toward Meteor thus its market is not comparable to other hosting platforms. Galaxy has the potential to become the best hosting platform for Meteor apps and I think it’s heading toward that direction. We all want easy, flexible and affordable way to deploy our Meteor apps.
On MongoDB
For the MongoDB, I personally prefer their current approach. I think it’s better if they focus on providing the best environment to run and monitor Meteor apps and leave the hosting of the data for the other specialized providers. Also, with that approach, we won’t have a single point of failure as babrahams mentioned.
On Support
I don’t have the experience to comment on that, I just hope they note those comments and improve their operation where it lacks. With regards to the activity on the forms, hats of to Sashko from MDG, he is active in every threads he needs to be, maybe they need to clone him somehow
On "Flexibility"
Fair point, I guess that’s the downside of being Meteor specific.
From my perspective, I also want to pay for MDG because they served well with Meteor but currently I’m at the development stage and not making money and a 5$ droplet on DO is sufficient. It seems that Galaxy pricing is more tailored toward the larger more established apps. I hope they can provide an entry pricing model so we can deploy on Galaxy early. I used Google App Engine back in 2009 when it was first released, and it was really simple to work with, we had one one click deployment from the IDE and it was free for small traffic but it’d scale automatically to handle larger traffic with the appropriate increase in cost.
I just saw the e-mail that customers have to move before 30 april (!) between either:
Go to galaxy if you want to have Kadira as a service. For some customers this is just not an option because of other limitations of Galaxy.
Host an open-source version of the service yourself, although it’s not yet been released
This is ridiculous. How does Meteor ever want to be taken seriously by any larger company if they give you deadlines of less then a month to either move your stack over to them or integrate a product that’s not yet released in their own deployment. I was trying to make a case to go to Galaxy and Meteor just lost all credit in our company as a service provider because of this action.
I think the added cost of Kadira on Galaxy is really expensive. Especially all of us paying close to nothing per month now have to pay per ECU. Also, the added features are something my team and I could build ourselves (and have).
The reality is you dont need kadira. You can shim the agent and change the target destination of the data to wherever you want. We chose InfluxDB
@abhiaiyer, I’ve been kicking around doing something like this, would you post one of your “howtos” on how to implement this ourselves?
Would be great to collaborate and perhaps setup something an open source package that can be maintained by the community.
For example a common Meteor error logging solution that could log to various backends eg. Sentry, Rollback, MongoDB
And then also the performance logging could go as you mention various DBs for storage.
I haven’t read where MDG specifically states they intend to OS Kadira. Are you sure it’s going OS now that MDG has purchased?
It’s right at the bottom of the blog post:
At the same time, we will also release the existing Kadira codebase under an open source license that will allow anyone to modify and run Kadira in their own environment.
After getting the email today which states we have until April 30th before Kadira shuts down, can you give us a time scale for when you expect to have released the source by?
Moving to Galaxy is not an option for us, and a timeline would help greatly with a migration plan.
Yeah I have alerted the relevant people - I agree we need to make sure there’s a clear and reasonable timeline for people who can’t use Galaxy to get the open source thing set up.