Titanous

Great question!

We designed Flynn to solve a bunch of the common problems around running apps in production.

This means that we're working full-time just on the automation and stability of your production environment. As you grow and scale, Flynn will scale with you and provide integrated features without any additional effort.

Here's an incomplete list of things that Flynn provides out of the box:

- Automatic high availability. Everything in Flynn is highly available, as long as you are running three or more servers. Additionally, it's designed to fail gracefully, so even if there's a network partition or some hosts fail, everything will keep working if at all possible.

- git push deployment, after installing Flynn you can run `flynn create && git push flynn master` and your app will be automatically built and deployed.

- Polyglot apps. Want to deploy a Phoenix app written in Elixir? You can do that just by specifying the appropriate buildpack. Everything else works exactly the same.

- Zero-downtime deployment with release management and easy rollbacks. If a new version or configuration variable causes the app to crash at boot, Flynn will automatically detect this and stop the deploy before any traffic hits it. Deploying new versions of the application does not cause user-visible downtime.

- Easy app configuration. `flynn env set FOO=bar` rolls out a new immutable release with the configuration change. You don't have to edit any files, and you can roll it back later with `flynn release rollback`.

- Built-in HA databases. `flynn resource add postgres` configures your app with a PostgreSQL database in a cluster that is highly available and already configured with replication and safe automatic failovers. You can do the same to get a MySQL or MongoDB database.

- Automatic load balancing and TLS. Flynn automatically load balances HTTP and TCP traffic, and supports HTTP/2 out of the box. You can add a TLS certificate with a single command, and all changes to the routing configuration happen immediately without restarts or downtime. Want to send a subpath to a different app? You can do that in a single command.

I could go on and on like this, but you probably get the idea. Of course, it's probably possible to build every feature of Flynn that you want using your configuration management tool of choice, but that would be a huge amount of time not spent developing the actual applications that you want to deploy with it.

Correct. By default app slugs are stored as large objects in the built-in Postgres cluster, to allow deployment without external dependencies. For production we recommend moving to AWS S3, Google Cloud Storage, or Azure Storage.

Garbage collection of old slugs is supported though it isn't on by default (it will be in the next stable release).

This would be great!

The open source Parse server (https://github.com/ParsePlatform/parse-server) already works on Flynn, and we can't wait until someone implements an open source system like Lambda.

The space is too complex to do a chart, as a bunch of details are not directly comparable.

Many people who choose Flynn are not directly comparing us to hosted platforms, as they want more control over their infrastructure (where they run it, lock-in avoidance, etc).

As far as individual features go, we are closest to Heroku (and maintain buildpack/runtime compatibility). However there are differences including our support for other databases (MySQL and MongoDB in addition to Postgres and Redis) and many other smaller things like HTTP/2 support.

> You want to use an external blob-store, by default it uses its own postgres to store them. However, it also doesn't do any garbage collection

The lack of garbage collection by default will be fixed in next week's stable release, we're really sorry that it caused you pain!

> The default limits on memory is 1gb, and for our app, when it runs out, it just crashes. Leaving no obvious error messages to be found.

Indeed, we're working on documenting this and exposing out-of-memory events in the app logs so that this is obvious.

Our experience at Flynn is that there are a few common scenarios:

- Small and side projects run well without supervision.

- Existing ops teams can manage Flynn without much additional effort.

- Medium sized teams that don't want an internal ops team pay us for Managed Flynn where we take over all ops-related responsibilities.

Thanks for using Flynn!

> There are still a couple of rough edges, specifically around upgrading and persistence across power failure

Indeed, we have been finding and fixing bugs in these two areas lately, and things have been improving. Next week's stable release will have a bunch of fixes for issues we found. We also recently added a bunch of new test coverage for backup/restore, which should ensure that future upgrades go smoothly.

As always, if you see any issues please let us know so that we can fix them!

Hey, I'm a co-founder of Flynn.

Flynn is entirely open source and BSD-licensed (https://github.com/flynn/flynn). You can run Flynn on any infrastructure without paying us anything.

The price you reference is for our Managed Flynn product, where we act as your ops team, operating a Flynn cluster for you and providing hands-on support for your apps and databases in production.

The full policy is available here: https://sourcecode.cio.gov

> This policy also establishes a pilot program that requires agencies, when commissioning new custom software, to release at least 20 percent of new custom-developed code as Open Source Software (OSS) for three years, and collect additional data concerning new custom software to inform metrics to gauge the performance of this pilot.

The spam threshold is adjustable: https://www.fastmail.com/help/receive/stopspam.html#settings

It also supports training a filter on your specific email/spam patterns which works very well in my experience.

Or ship compiled static binaries.

There is also a BSD-licensed version that we wrote in Go: https://github.com/flynn/go-tuf

If you're interested in securing software update systems, check out The Update Framework. TUF is the only system I'm aware of that has a comprehensive threat model for the problem of securely distributing software updates.

https://theupdateframework.github.io

Obviously I'm biased, but here's my take:

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.

The Configuration and Limits sections of this page might be helpful: https://flynn.io/docs/apps

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.

> Is there a document describing the architecture of a running system?

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.

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.

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.

Thanks Paul!

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.

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 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?

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.

Both Dokku and Deis focus on stateless webapps.

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.

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.

Yes, you can run a privileged container that bind-mounts / on the host into the container. root.

My understanding is that in practice this is quite hard to do. As far as I know, none of the mainstream block-layer encryption systems (BitLocker, FileVault, dm-crypt) provide authenticated encryption.

Here's a short thread about the problems with adding it to dm-crypt: http://comments.gmane.org/gmane.linux.kernel.device-mapper.d...

I'm sure you can find more threads if you look around.

In order to do filesystem encryption properly, it needs to be done at the file layer, not the block layer. Block-level encryption is not authenticated because there are no extra bytes to add the authentication tag.

If a ciphertext is not authenticated, it can be trivially tampered with. This means that someone with access to the encrypted drive could add backdoors or otherwise tamper with the executables and data even though it is encrypted.

NaCl is basically this, but as a library instead of copy/paste. It's available in most languages if you look around.

https://nacl.cr.yp.to/index.html

Comodo's CEO has responded on their forums: https://forums.comodo.com/general-discussion-off-topic-anyth...

Correct, the executable code is unencrypted, the source code has not been released.