FL0

Thanks @dansiepen !! Appreciate your support

@omaridau Thanks mate! Excited for you to give it a test run!

Hi @anindha_parthy users can cap their costs based on max number of instances they want deployed - we will use memory and cpu metrics to determine when to scale the service up and down. A users project environment is network isolated from other users / the rest of the infra and spread over multiple AZs within a region that the user selects. Hope that helps and thanks for the support!

@ryan_fl0 With AWS its relatively clear what type of performance I get per instance and I can do most of what you said using EC2 auto-scaling. Not trying to be too negative and would love to try the service if I can find a compelling benefit. edit: I am also curious if the main product is open source seeing you have an open source tag on the PH release but couldn't find it on your Github.

@anindha_parthy Yes it's absolutely possible to build all of this on AWS - however, our focus is accelerate teams by making sure they don't have to spend their time doing that, and can focus on their own product and features instead. So our users can push commits and we automatically roll them out to their dev environment, and they can push to their prod environment when they wish (or configure to automatically push from another branch). For performance we offer from shared cpu (on Free) up to 8 dedicated cores (on the Pro plan), and more for enterprise customers.

@ryan_fl0 We use PM2 for some of this type of functionality (yes its Node specific only). Say I needed 30 x 4 core servers what would be the marginal cost of FL0 vs AWS (rough guide is also fine)? The issue I had with Heroku was once we got to a number of servers we realised the margin was quite high for using Heroku and we invested time in deploying directly to AWS. I appreciate the responses!

Hi @sarvpriy_arya we offer a number of different levels of compute for our users on the platform, with and without autoscaling, dev and prod environments, as well as customisable domain names. Further per-environment config can be injected into the environments. If you've got any specific requirements, we would love to hear them!

@dean_mcpherson thank you! Haha indeed, I should share the bloopers video 😂

@miduga thanks for all your support! Awesome to see the amazing things you've been deploying on FL0!

Thanks for the support @kinzarra - Our fl0bot's focus right now is getting our users up and running as quickly as possible - trying to drive down the "connect to repo" -> "serving traffic" time. Our fl0bot helps categorise issues broadly into either build or runtime failures, from there we drill down further - for example a common issue is not binding to the correct `PORT` env var; or a configuration issue at runtime that will cause the service to crash; or a build failure due to missing a dependency. By surfacing these issues directly to the user we can guide them in rectifying the issue and getting them up and running as quickly as possible. We have a lot of exciting features for this in the pipeline.