We're very active about providing as much free support as possible to users over email, github, and IRC. We've collected some great quotes from users about how impressed they are with our responsiveness.
Unfortunately we're a small team and frequently travel to events, etc. So it's expensive for us to guarantee that someone will be around. Obviously we'd like to provide support to as many people as possible at the lowest possible rate, so as we have more people paying for support and economies of scale kick in we hope to be able to drop those prices. In the meantime we need to cover our costs or development will stall
edit: our current prices are also based on the level of support that our most active beta users needed. Now that we're past 1.0 hopefully users will need less help which will also help lower prices. We have a very high bar for support quality and don't want to overextend ourselves to the point where we can't deliver
We designed Flynn to be easy to install and use and for it to take care of itself as much as possible. Users generally get up and running and manage issues on their own.
Most current users (from individual developers to large organizations) haven't needed or wanted commercial support contracts. The offering is there for organizations who need significant help and/or an absolute guarantee that they'll be able to reach us at any hour of the day, every day of the year.
I use Cloud 66, so I'll use that as a comparison in terms of price. Their price is $19/mo for the first server + $9/mo for additional servers. It's a little bit of work to get set up and running.
To compare with Flynn, their current pricing is $74-75/node, which is quite a bit more. However, Flynn appears to offer more 1 on 1 support whereas Cloud66's is extra.
Nonetheless, there's quite a bit of difference. I think the range of $20/node may be reasonable. Anything less, the company would be unable to grow. In fact, especially for early stage startups, I'd probably err on the side of a higher pricing (eg. $30-40).
The paid plan is not for the side project but for funded projects or ones that already have money coming in.
Flynn is also a whole lot easier to get set up. Again, just what I've observed based on an earlier release.
Dokku is explicitly single-host. Flynn can run in a single-host configuration but typically deployed in a highly available configuration with three or more hosts.
Flynn is designed to tackle some much bigger problems and supports running and managing highly available databases inside the platform out of the box in addition to stateless web apps.
BOSH operates at a lower level, working with VMs. Flynn is higher level and allows deployment and management of applications and databases in containers.
Instead of relying on a lower layer like BOSH, Flynn is self-bootstrapping and self-hosting. It runs everything except the container runner in containers managed by the platform. The same APIs and tools are used to manage user applications and Flynn components.
You can bring your own lower level infrastructure, like IaaS or bare metal. There is a cloud installer that can spin up a cluster to try out on EC2, Azure, or Digital Ocean, but most production users are using whatever management tools they are comfortable with to deploy and scale Flynn hosts out.
As Titanous said, BOSH operates at a lower level than Flynn. You could use BOSH to deploy Flynn, hypothetically. A more direct comparison would be Cloud Foundry.
Kubernetes didn't exist when we started, so we ended up building our own scheduling system and management APIs. So it wouldn't really be "adding" support, instead we'd need to switch several layers of the system to be Kubernetes instead of our code.
We're watching Kubernetes, it's possible that doing that change will make sense at some point in the future.
Is there a document describing the architecture of a running system?
I didn't get from reading the documentation whether I'm spawning processes, containers, or affecting full servers.
What comprises a cluster?
Can I choose to dedicate a host to run a db, and at the same time run serveral mini-processes without launching every one in a container?
The front that flynn exposes is pleasently simple, but I also want to know what implies every command and how it affect the running environment.
Please let me know if anything specific is missing so that we can add it.
> Can I choose to dedicate a host to run a db, and at the same time run serveral mini-processes without launching every one in a container?
You can dedicate specific hosts to specific apps and process types using node tagging, though it looks like we are missing documentation for that. I'll make sure it gets added soon.
You are free to fork multiple processes inside of containers you deploy, there doesn't need to be a 1:1 mapping of container to process.
Thanks, that detail was what I was looking for.
I also wanted to understand the flexibility and options that Flynn offers to modify the running environment.
I very briefly looked into Flynn when evaluating self hosted PaaS offerings and ended up settling on Dokku for now, and there are several features it had that Flynn seemed to lack that were huge wins. Is there any plan to support plugins in a similar way to Dokku? Specifically the volume storage plugin has made deploying some apps that don't play nice with 12f stuff much easier.
The other thing that has come in very handy is being able to deploy Dockerfile builds directly, is this something that Flynn can do as well, or is support planned?
> Is there any plan to support plugins in a similar way to Dokku? Specifically the volume storage plugin has made deploying some apps that don't play nice with 12f stuff much easier.
Flynn is natively highly available and multi-host, which makes doing volume storage tricky. Our current immediate plan for this is to support NFS mounts for apps so that you can point at an external file server (or service like AWS EFS). Feel free to watch or thumbs-up this issue: https://github.com/flynn/flynn/issues/1521
As far as plugins go, Flynn is entirely API-driven so you should be able to hook in and do whatever you want without modifying Flynn itself. If you run into something that you want to do that makes sense as an integration but isn't currently possible, please open an issue and we can discuss how to make it happen.
> The other thing that has come in very handy is being able to deploy Dockerfile builds directly, is this something that Flynn can do as well, or is support planned?
Building Dockerfiles is currently tricky from a security and modularity perspective as it requires running inside a privileged Docker daemon. There is no way that I'm aware of to do a build without providing root or root-like capabilities. If it was as simple as importing a package and using it in an unprivileged container to perform the build, we'd definitely evaluate adding support carefully.
I'm not aware of any support for building images using Dockerfiles in rkt. My understanding is that the Dockerfile build system is embedded in the docker daemon.
Dokku is a fantastic project. I just wish it worked on a cluster of machines.
I looked at Deis recently as a future migration option once I outgrow Dokku but the database layer is not really documented or talked about. The blog posts are very hand-wavy when discussing persistent storage.
Volume storage has been one of the huge issues with people looking at Docker. I've heard there's better storage support now, but at my current company, we just use AWS/RDS instances for DB storage and everything else is stateless in containers on CoreOS.
Wow, these people really seem to like you! Have you considered putting some of their endorsements on your résumé?
> You let people deploy and manage lots of applications, whether they’re microservices or monoliths, written in any combination of languages.
> You make running software faster and easier so developers can ship their code with less friction and spend more time creating applications and products.
> You bring resilient, scalable, and efficient infrastructure to everyone. You are a single, unified, easy-to-use platform.
> Developers and companies around the world are using you to power everything from their latest side project to their startup’s most important products in production.
> This is just the beginning of your development, and we’ll have many more features to announce in the coming months. For now, you are solid, stable, and ready to use.
> You are fast and easy to install on popular clouds with our graphical installer or on your local machine with Vagrant. Try it today and see how far we’ve come.
This is usually a holdover of having the blog its own system (e.g. WordPress) at blog.example.com or example.com/blog and having the rest of the site managed by some other CMS or none at all.
Not saying there's a legitimate reason to do that, but just saying that's usually the technical reason for it.
One thing I think would be nice is a screenshot of the dashboard. Compared to Dokku or other solutions which are command line only, having a UI is a huge plus and they should definitely show it off.
Absolutely. We're putting together a list right now, we just don't have permission from everyone to talk about it publicly yet. Hopefully we'll have quotes and case studies to post on the website soon.
I evaluated flynn (an earlier release) previously and noticed issues when one of the servers in the cluster went offline suddenly. The stack couldn't fix itself and along with it the DB was gone as well.
There was a Github issue before about, but I don't have that link around.
Could someone from the dev team at flynn comment about how flynn self heals currently if there's a server issue? eg. especially the one where the DB is hosted
Flynn is designed to be self-healing, if a server goes offline it will recover immediately and automatically and no confirmed writes will be dropped.
We use a combination of Raft for service discovery and leader election, along with multiple instances of all core services so host failures within the quorum tolerance should not impact availability. The design of the data appliances is carefully considered, you can read an overview here: https://flynn.io/docs/databases
If something catastrophic does go wrong, like the power going off in the datacenter, there is code that can resurrect the cluster when enough hosts come back online.
We did have some issues with recovery that have been fixed over the past few months, I'm almost certain the issue that you ran into has been fixed. Data is never destroyed by Flynn, so it's possible to recover the database from disk even if Flynn isn't running.
The system is also designed to tolerate partial failures gracefully, so if for example service discovery fails, the router will fall back to a cache and HTTP clients should not notice that anything is wrong.
I've used flynn on a couple smaller projects and overall had a good time with it. Has anyone used it for any larger projects and wouldn't mind sharing their experiences? I'd be interested to see how it goes once more moving parts get involved.
We've been using it with a ~10 nodes cluster for some time to host both internal and production apps.
It has allowed the rest of the team to focus on the apps themselves without worrying about how to deploy them, how to provision more capacity, how to rollback in case of failure, etc.
Using the builtin affinity and priority system, we were able to make sure that production apps would always run smoothly without being affected by our other processes.
We use it at my company on a 3 node cluster running in AWS.
We host about 10 small apps/services in it. They vary from things that do (basically) a single simple API call to full Rails apps.
Experience has been very positive. We had our share of "pre 1.0" issues, to be sure. But, the team in #flynn (IRC) is incredibly responsive. It's been a pleasure watching the issues get resolved, merged, and deployed very rapidly.
Digging into the code too, it's easy to follow and feels quite nicely architected.
Aside from all of that, my team is thrilled to have its own little PaaS.
On this topic, i am looking for a simple "deploy this app to my machine" sort of deployment scheme. I don't have fleets of machines, hell i will usually only have a single machine. I mostly just want to ease the process of deploying updates to my webapps.
What do you recommend? I spent some time last night looking into all the big names atm, Flynn, Deis, Nomad, Kubernetes, Docker, etcetc. They all seem so complex for my needs.
Sure, if my app grows, being able to boot up a few extra VMs, add them to my "cloud", and then deploy my app to my new machines easily sounds appealing, but honestly right now that's so beyond my scope that it seems silly. I just want easy deployments, and easy installation of whatever i end up using (Flynn/Deis/etc).
So with that said.. any opinions on the simplest? Dokku seams to be the simplest.. but it's hard for me to say atm, i don't have much experience of perspective.
Flynn aims to be the easiest to use among the available tools. We intentionally limit the amount of configuration necessary to get up and running and don't require you to bring together a bunch of components to make a stack that works.
Dokku is architecturally simpler because it only focuses on single-host use cases, but we hope Flynn is just as easy or easier to install and use.
Try cloudron.io. It's exactly what you are looking for wrt app updates. You can make custom apps and not just from the store. All apps are on a single server as well (and not about "scale")
Disclaimer: managed cloudron customer (I have not used the selfhosted option).
I would really like to see an article comparing Flynn with Deis. Last time I looked it seemed to me like two different implementations of the same thing. What are the differences?
Flynn has a larger technical scope, covering everything from the details of how container are run all the way up to the user interface used to deploy applications. We also run highly available databases within the platform, in addition to stateless webapps. As a result of working to build an easy to use unified solution, we've ended up building many components from scratch specifically for Flynn and have very few dependencies.
Deis is designed to use commonly used off the shelf components, and has a focus on stateless web apps. Currently Deis is built around the Kubernetes and Docker ecosystems.
Flynn's approach has given us more flexibility, but it has taken longer, so Deis has often reached various milestones faster.
It's a frequently asked question so hopefully in the future a well-informed user with experience on both platforms can write a detailed teardown/comparison.
As one of the Dokku maintainers, I'd like to congratulate the flynn developers on a 1.0 release. Getting everything polished to a state where you can say "this is stable" is really hard, and they've done a fine job with Flynn.
57 comments
[ 0.22 ms ] story [ 115 ms ] threadUnfortunately we're a small team and frequently travel to events, etc. So it's expensive for us to guarantee that someone will be around. Obviously we'd like to provide support to as many people as possible at the lowest possible rate, so as we have more people paying for support and economies of scale kick in we hope to be able to drop those prices. In the meantime we need to cover our costs or development will stall
edit: our current prices are also based on the level of support that our most active beta users needed. Now that we're past 1.0 hopefully users will need less help which will also help lower prices. We have a very high bar for support quality and don't want to overextend ourselves to the point where we can't deliver
I feel like our current deploy infrastructure doesn't need to be replaced if it means forking over $1500+ a month.
Most current users (from individual developers to large organizations) haven't needed or wanted commercial support contracts. The offering is there for organizations who need significant help and/or an absolute guarantee that they'll be able to reach us at any hour of the day, every day of the year.
To compare with Flynn, their current pricing is $74-75/node, which is quite a bit more. However, Flynn appears to offer more 1 on 1 support whereas Cloud66's is extra.
Nonetheless, there's quite a bit of difference. I think the range of $20/node may be reasonable. Anything less, the company would be unable to grow. In fact, especially for early stage startups, I'd probably err on the side of a higher pricing (eg. $30-40).
The paid plan is not for the side project but for funded projects or ones that already have money coming in.
Flynn is also a whole lot easier to get set up. Again, just what I've observed based on an earlier release.
Dokku is explicitly single-host. Flynn can run in a single-host configuration but typically deployed in a highly available configuration with three or more hosts.
Flynn is designed to tackle some much bigger problems and supports running and managing highly available databases inside the platform out of the box in addition to stateless web apps.
Instead of relying on a lower layer like BOSH, Flynn is self-bootstrapping and self-hosting. It runs everything except the container runner in containers managed by the platform. The same APIs and tools are used to manage user applications and Flynn components.
For more information, check out our Architecture page: https://flynn.io/docs/architecture
You can bring your own lower level infrastructure, like IaaS or bare metal. There is a cloud installer that can spin up a cluster to try out on EC2, Azure, or Digital Ocean, but most production users are using whatever management tools they are comfortable with to deploy and scale Flynn hosts out.
At Pivotal we're seeing multi-thousand VM instances of Cloud Foundry that BOSH deploys and updates gracefully.
We're watching Kubernetes, it's possible that doing that change will make sense at some point in the future.
The front that flynn exposes is pleasently simple, but I also want to know what implies every command and how it affect the running environment.
There is an architecture page: https://flynn.io/docs/architecture
Please let me know if anything specific is missing so that we can add it.
> Can I choose to dedicate a host to run a db, and at the same time run serveral mini-processes without launching every one in a container?
You can dedicate specific hosts to specific apps and process types using node tagging, though it looks like we are missing documentation for that. I'll make sure it gets added soon.
You are free to fork multiple processes inside of containers you deploy, there doesn't need to be a 1:1 mapping of container to process.
Let me know if there is something else specific that you are wondering about and I can answer here or get some more docs up.
The other thing that has come in very handy is being able to deploy Dockerfile builds directly, is this something that Flynn can do as well, or is support planned?
Flynn is natively highly available and multi-host, which makes doing volume storage tricky. Our current immediate plan for this is to support NFS mounts for apps so that you can point at an external file server (or service like AWS EFS). Feel free to watch or thumbs-up this issue: https://github.com/flynn/flynn/issues/1521
As far as plugins go, Flynn is entirely API-driven so you should be able to hook in and do whatever you want without modifying Flynn itself. If you run into something that you want to do that makes sense as an integration but isn't currently possible, please open an issue and we can discuss how to make it happen.
> The other thing that has come in very handy is being able to deploy Dockerfile builds directly, is this something that Flynn can do as well, or is support planned?
We support pushing Docker images to a registry built-in to Flynn: https://flynn.io/docs/docker
Building Dockerfiles is currently tricky from a security and modularity perspective as it requires running inside a privileged Docker daemon. There is no way that I'm aware of to do a build without providing root or root-like capabilities. If it was as simple as importing a package and using it in an unprivileged container to perform the build, we'd definitely evaluate adding support carefully.
Would it be easier with rkt?
Funny how much things change and how much they stay the same.
I looked at Deis recently as a future migration option once I outgrow Dokku but the database layer is not really documented or talked about. The blog posts are very hand-wavy when discussing persistent storage.
> You let people deploy and manage lots of applications, whether they’re microservices or monoliths, written in any combination of languages.
> You make running software faster and easier so developers can ship their code with less friction and spend more time creating applications and products.
> You bring resilient, scalable, and efficient infrastructure to everyone. You are a single, unified, easy-to-use platform.
> Developers and companies around the world are using you to power everything from their latest side project to their startup’s most important products in production.
> This is just the beginning of your development, and we’ll have many more features to announce in the coming months. For now, you are solid, stable, and ready to use.
> You are fast and easy to install on popular clouds with our graphical installer or on your local machine with Vagrant. Try it today and see how far we’ve come.
Also, the logo links to the product page, not to some blog aggregation page as many other announcement do.
Not saying there's a legitimate reason to do that, but just saying that's usually the technical reason for it.
"If you can explain the problem better than the customer, they'll believe you also have the solution."
There was a Github issue before about, but I don't have that link around.
Could someone from the dev team at flynn comment about how flynn self heals currently if there's a server issue? eg. especially the one where the DB is hosted
Thanks and congrats!
We use a combination of Raft for service discovery and leader election, along with multiple instances of all core services so host failures within the quorum tolerance should not impact availability. The design of the data appliances is carefully considered, you can read an overview here: https://flynn.io/docs/databases
If something catastrophic does go wrong, like the power going off in the datacenter, there is code that can resurrect the cluster when enough hosts come back online.
We did have some issues with recovery that have been fixed over the past few months, I'm almost certain the issue that you ran into has been fixed. Data is never destroyed by Flynn, so it's possible to recover the database from disk even if Flynn isn't running.
The system is also designed to tolerate partial failures gracefully, so if for example service discovery fails, the router will fall back to a cache and HTTP clients should not notice that anything is wrong.
It has allowed the rest of the team to focus on the apps themselves without worrying about how to deploy them, how to provision more capacity, how to rollback in case of failure, etc.
Using the builtin affinity and priority system, we were able to make sure that production apps would always run smoothly without being affected by our other processes.
We host about 10 small apps/services in it. They vary from things that do (basically) a single simple API call to full Rails apps.
Experience has been very positive. We had our share of "pre 1.0" issues, to be sure. But, the team in #flynn (IRC) is incredibly responsive. It's been a pleasure watching the issues get resolved, merged, and deployed very rapidly.
Digging into the code too, it's easy to follow and feels quite nicely architected.
Aside from all of that, my team is thrilled to have its own little PaaS.
What do you recommend? I spent some time last night looking into all the big names atm, Flynn, Deis, Nomad, Kubernetes, Docker, etcetc. They all seem so complex for my needs.
Sure, if my app grows, being able to boot up a few extra VMs, add them to my "cloud", and then deploy my app to my new machines easily sounds appealing, but honestly right now that's so beyond my scope that it seems silly. I just want easy deployments, and easy installation of whatever i end up using (Flynn/Deis/etc).
So with that said.. any opinions on the simplest? Dokku seams to be the simplest.. but it's hard for me to say atm, i don't have much experience of perspective.
Dokku is architecturally simpler because it only focuses on single-host use cases, but we hope Flynn is just as easy or easier to install and use.
Disclaimer: managed cloudron customer (I have not used the selfhosted option).
Flynn has a larger technical scope, covering everything from the details of how container are run all the way up to the user interface used to deploy applications. We also run highly available databases within the platform, in addition to stateless webapps. As a result of working to build an easy to use unified solution, we've ended up building many components from scratch specifically for Flynn and have very few dependencies.
Deis is designed to use commonly used off the shelf components, and has a focus on stateless web apps. Currently Deis is built around the Kubernetes and Docker ecosystems.
Flynn's approach has given us more flexibility, but it has taken longer, so Deis has often reached various milestones faster.
It's a frequently asked question so hopefully in the future a well-informed user with experience on both platforms can write a detailed teardown/comparison.