@overworkedasian Dokku is a really good example of what you can build quickly with a small amount of code when you limit your scope. Flynn is totally compatible with apps that run on Dokku, so if you want to scale past one server, Flynn is a great fit. https://flynn.io/blog/upgrading-...

@nbrempel Indeed! We launched our crowdfunding campaign on Hacker News in July 2013, and shipped the 1.0 release almost exactly three years later, this past July.

@jamiequint Convox is a great pick if you want to use AWS-specific services for your entire stack. Instead of using portable open source components, Convox uses AWS services wherever possible, and acts as a lightweight coordinator to combine them into a platform. Flynn has no external dependencies on cloud features, so you can run it anywhere, whether that's on your laptop, AWS, Google Cloud, a VM somewhere, or bare metal in a colo or private datacenter. We also include RDS-like highly available database appliances so that your whole stack is portable and you are not locked into a single hosting provider.

@jamiequint does flynn support RDS, elasticache etc? If I run flynn on AWS, will it run dbs and caches on top of EC2?

@jigardoshi Flynn doesn't have built-in integration with RDS, but you can use any external cloud services that you want, including RDS and Elasticache, from your Flynn cluster. You can also use the provider API to integrate external database services into Flynn (for example https://github.com/flynn/postgre...). The databases built-in to Flynn run on the servers in the Flynn cluster. We specifically made the choice not to consume cloud-specific APIs, our built-in database appliances do roughly the same that that RDS does, but without the lock-in.

@bogomep Great question! The license is BSD 3-clause, and it's in the GitHub repo: https://github.com/flynn/flynn

@titanous Thanks!

@therealcoelho Dokku only supports a single server. Flynn can also run on a single server but is highly available when run across three or more servers. We also have database appliances with safe, automatic failover, so you can get PostgreSQL, MySQL, MongDB, and Redis hooked up to your app with a single command. We recently wrote a blog post about moving from Dokku: https://flynn.io/blog/upgrading-...

@elizabethhunker you and me both.. what do you think so far?

@_pascalandy Probably! Flynn is a solution that "just works" out of the box, so you can push app repos and Docker images and have them be deployed in a highly available configuration with databases and load balancing, easy rollbacks, log aggregation, and a bunch of other features without doing any work. If you're just using vanilla Docker, getting to the point where you can do all that tends to be a lot of work and then you have to maintain it once you get everything working. With Flynn, we've already taken care of building the platform, and you can focus on building your apps instead of wrangling infrastructure.

@_pascalandy I don't think anyone has tested Flynn at that scale yet. The first limitation you'd run into would be the IPv4 /24 subnet that we use for each host would limit the number of containers per host to ~250. That being said, we're definitely going to get to the point of running tens of thousands of containers on a Flynn cluster, we just haven't had any users that have needed it yet. As far as running Flynn in Swarm Cluster goes, this would not be possible, as Flynn manages containers itself and does not run within other container runners like Docker. Flynn is automatically highly available out of the box (when you run it on three or more servers), and everything from the internal components to the databases and the apps that you deploy on top of Flynn tolerate server failures and will keep on working with minimal production impact.

@titanous > As far as running Flynn in Swarm Cluster goes, this would not be possible, as Flynn manages containers itself and does not run within other container runners like Docker. Exactly what I thought. Thanks for the clarification. > The first limitation you'd run into would be the IPv4 /24 subnet that we use for each host would limit the number of containers per host to ~250. I know LOL. But check this out https://github.com/docker/docker...

@_pascalandy The medium-term plan is to use IPv6 by default which will eliminate this issue entirely. Once we have that in place, we'll also do a bunch of scale testing to sort out where the bottlenecks are and remove them.

@titanous @_pascalandy I'm curious for both of your perspectives: how does this compare to Deis Workflow (https://github.com/deis/workflow/)? I'm a fan of the scalability of Kubernetes and see this work as a Heroku-on-top-of-a-platform-I-know situation. No matter the answer, this project's presence on GitHub looks impressive.

@mjbrender When we started in 2013, the only open source scheduler available was Mesos and the ecosystem didn't have community efforts like Kubernetes, so we had to write our own components to build Flynn. Flynn is designed to be an end-to-end solution for production deployment, and all of our components are created to work together. The whole system is self-bootstrapping and self-hosting, so installation is easy, and the same APIs are used to manage the whole platform as are used to manage apps deployed on it. In addition to the twelve-factor stateless webapps that Deis Workflow supports, Flynn also includes highly available database appliances with safe, automatic failover (currently PostgreSQL, MySQL, and MongoDB with more coming in the future). We also have a bunch of security features coming over the next few months like Let's Encrypt support and flexible user authentication with 2FA and very granular access control. If you don't need or want our database appliances and you are comfortable with Kubernetes and happy to install and operate it, then Deis Workflow is a good option. If you don't care about using Kubernetes specifically, Flynn is a good pick as it is easier to get up and running with.

@istereotype There are four overview videos, one on each of the main pages (Home, Apps, Manage, Databases) but they are not quite tutorials. Is there anything specific that you'd like us to explain better in the docs or make videos about?

@titanous Surely, I think a video walkthrough on how to install flynn and then one on how to use it would be great. Even though i have already reached a certain point. These days video walkthroughs help a lot more. But everything aside, this looks super cool. I am sure a lot of devs like myself would highly appreciate what you guys have built. Having our own heroku itself kind of makes me feel like 😎

@titanous I agree with @istereotype. :) I hope you can release some walkthrough video soon. Basic guide in installing & deploying apps.

@menjxo @istereotype Thanks for the feedback! We'll make some more videos. In the mean time check out the four videos that are on the site now as they provide overviews of usage, installation, apps, and databases.

@gopietz

@karlmonson Most of our time on databases up to this point has been spent on getting the safe, automatic failover right, which we're now confident that we've solved. Our database appliances currently lack the ability to tune parameters to handle production workloads and require some optimization around the movement of data volumes to handle larger amounts of data. Implementing these features is our primary focus right now and we expect them to be ready for demanding production use cases within the next few months.

@titanous @karlmonson This rocks! Everyone know how crazy it can be to optimize DB. Love your spirit!

@titanous is there any plan for more granual permission? Each app has its own product manager. Would be great to be able to limit user access

@hadifarnoud Yeah, we're working on that right now! Here's our security roadmap: https://github.com/flynn/flynn/p...

@hadifarnoud Thanks for using Flynn, we're so glad it's been useful to you!