We’re committed to making Flynn one of the best ways to run Parse apps.
Flexibility is important to us. We want you to be able to write your apps
however you want, using any technologies and run them happily on Flynn. Flynn
already makes it easy to run apps written in most languages and frameworks by
using Heroku buildpacks and Docker container images. Flynn is also 100% open
source and we’re committed to developer tools and infrastructure being as
portable as possible.
October’s stable release is out! It includes an Azure Storage blobstore backend,
app garbage collection by default, improved reliability for apps while
deploying, and many bugfixes and small improvements. The
changelog has the details and
there are docs on how to update.
When we created Flynn, our goal was to build a single platform that ran
everything you needed to run your apps. One of the most important and most
challenging parts of that vision was how to manage databases.
Setting up and managing databases is one of the hardest things to do in ops.
Most databases are difficult to install and configure, especially if you’re
trying to use best practices like high availability and automatic failover.
Configuring databases by hand is hard, but automating them so they can manage
themselves is much trickier. There are a number of Database as a Service
providers out there, but most are closed source and lock you into a single
infrastructure provider. For databases to work in Flynn they needed to be
completely self-managing, quick and easy to set up, and be able to run anywhere.
We believe the most important job of a database is to keep data safe. When an
application tells a user it’s received input, the database needs to hold onto
it, no matter what. Unfortunately it’s all too easy to run databases in
configurations that lose data when things go wrong, and at scale things always
go wrong. Hard drives break, networks partition, uninterruptible power fails,
and so on.
We built Flynn’s database appliances to survive those kinds of failure and keep
users' data safe.
Here’s how we do it:
High Availability: Flynn’s PostgreSQL, MariaDB, and MongoDB appliances are
highly available by default. That means there are always multiple copies of
the database running and ready to go. So if something happens to one, the
others are ready to take over. As long as you are running three or more
servers, Flynn runs multiple copies of the database on different machines,
just in case.
State Machine: We use a state machine based on Joyent’s
Manatee so there’s a chain
of replicas: a primary, a synchronous replica, and an asynchronous replica.
When an application sends a write to a Flynn database appliance, the appliance
will only confirm the write after it’s been copied to the primary and
synchronous replica. If the primary goes down, the synchronous replica is
promoted to the primary, the asynchronous replica is promoted to become the
synchronous replica, and a new instance is created to become the asynchronous
replica. This “chain” means that there’s never any question about which
replica should take over.
Automatic Failover: Flynn’s health check and service discovery services
monitor each of the instances in the database appliance’s state machine. It
automatically promotes and creates new instances in the state machine. Since
this failover is automatic, it can switch over nearly instantaneously and
responds much faster than a human operator who receives a page and has to
investigate what happened.
Whole Cluster Backups: Flynn manages your applications and databases on the
same cluster. The command that takes a cluster backup includes databases. It
takes only two lines of code to backup a running cluster and restore it
Cloud Independence: Flynn doesn’t use any cloud-specific features to run or
manage databases. So a Flynn cluster using PostgreSQL and MongoDB runs the
same on AWS as it does on DigitalOcean or your own hardware in a colo. Your
product and data stay portable, so your options stay open.
We have a lot more features and
improvements in the works for how
Flynn handles databases. There’s already a solid foundation but we want running
all your production databases (and applications) in Flynn to be a no-brainer.
You can subscribe to the GitHub
issue or sign up for our mailing
list to watch our progress.
We now provide fully managed Flynn as a service in addition to our existing
commercial support and training products.
We want everyone to have the best experience with Flynn possible, whether that’s
running it entirely on their own, with our help via a support contract, or using
a Flynn cluster that we manage for them.
We offer commercial support contracts for users who want to be able to reach our
team 24/7 if anything goes wrong. We try to become customers' “backup ops team”
and go above and beyond expectations by solving their problems whether or not
they’re related to Flynn.
Recently we’ve been approached by users who want even more. Many companies,
especially small startups and development shops don’t have (or want) an ops team
or sysadmin, or have one solo “devops person”. Some of these users are happy
running Flynn on their own, but others have asked us to run everything for them.
We’re launching a beta of Managed Flynn today. Here’s how it works: our team
configures, installs, runs, and manages a Flynn cluster for your company.
Everything runs in your own cloud account so you always have complete control
and ownership of your infrastructure (and can take advantage of any cloud
credits you might have). Our team is standing by 24/7 to help your developers
get the most out of Flynn and help fix anything that goes wrong with Flynn, your
apps, or infrastructure provider.
We’re already working with several managed customers and are excited to see how
this scales. As Flynn itself becomes more powerful and feature-rich we’ll be
able to offer even more capabilities and guarantees to our customers.
If you’re interested in becoming a Flynn managed customer, please contact
One of the most common ways developers find Flynn is when they’re looking for an
alternative to Dokku.
Dokku is a widely used open source mini PaaS.
It’s a great introduction to what platforms can offer and easy to get up and
running on a single server. It’s also tiny and a model of efficiency, originally
written in just 100 lines of Bash.
Many developers choose Dokku because it provides many of the benefits of PaaS,
but can be run anywhere on a single server.
Unfortunately the feature that makes Dokku so attractive to developers working
on personal side projects, its single host nature, makes it unsuitable for
larger and production deployments.
Running as a single instance on a single server prohibits high availability.
A single host means there’s a single point of failure. If that server goes down,
everything breaks. It also means that users need to do a lot of heavy lifting
themselves to scale out.
Flynn includes all the benefits of Dokku without its limitations. One of Flynn’s
original design goals was to be the next step on the upgrade path for Dokku
users. Both Flynn and Dokku were created to give users the benefits of Heroku,
but with more control and the ability to run anywhere they wanted.
Like Dokku, Flynn is also easy to use and install, but scalable, far more
robust, and suited to production environments. Everything in Flynn is highly
available, so there’s no single point of failure. Even Flynn’s internal
components run inside the cluster as highly available Flynn apps.
You can run Flynn on a single server or scale it out to many, many more. Flynn
has a web dashboard that makes it even easier to use. Flynn also includes
built-in database appliances, which you can think of like having a database as
a service (DbaaS) inside your Flynn cluster. Other features you’ll need for
scaling production apps like overlay networking and service discovery are also
If you’re already running your apps on Dokku, it’s very easy to migrate to
Flynn. Here’s how: