
An Open Source, Self-Hosted Heroku - stucat
http://www.bitmatica.com/blog/an-open-source-self-hosted-heroku/
======
mbreedlove
I just migrated a hobby website to Dokku, which also markets itself as a self-
hosted Heroku. I was curious how Flynn compared. Fortunately, there was a blog
post giving an overview[1]. I get the impression that Flynn has all the
benefits of Dokku, but has the ability to scale to multiple servers. It seems
like Flynn is obviously better than Dokku, so I guess I get to do that this
weekend.

Keeping up with new containerization tech is starting to feel like keeping up
with new JS frameworks/tooling...

[1] [https://flynn.io/blog/upgrading-from-dokku-to-
flynn](https://flynn.io/blog/upgrading-from-dokku-to-flynn)

~~~
zachwill
I think a lot of us feel your same pain.

Has anyone had success with sticking to Dokku for small side projects on
DigitalOcean/Linode/etc?

~~~
ryanSrich
I've had success going from heroku to Dokku on DO. Pricing is pretty much the
same and Heroku has mature features so I may switch back at some point.

~~~
andybak
Are you saying Heroku costs are the same as Dokku on DO? How so?

~~~
ryanSrich
My app is very small. Typical charges on a $7 hobby dyno were $3-$6 per month.
DO is $5 for the droplet.

------
bglusman
This is a great overview of the kubernetes/self-hosted PaaS landscape, but is
also clearly a bit of marketing for Flynn. Flynn looks awesome, but also
as/more awesome at a glance from my research and test runs is
[https://github.com/convox/rack](https://github.com/convox/rack) which I got
closer to working more quickly than Flynn, though it helped that Convox builds
on top of docker-compose.yml files, which we were already using for
development.

For better or worse, we're going the full kubernetes route though, and still
working out what deployment etc looks like. So far a lot of un-DRY looking
YAML files have inspired a spike at a tool to help manage creating and
maintaining kubernetes yaml[1], which others reading this are welcome to try
and I'd love to hear better alternatives to or get feedback/pull requests/etc.
I may push up a branch I'm working on later that partially automates creating
deployments from a Procfile, but we discovered having seperate Procfiles may
make applying env-variable only changes harder, curious to hear if others have
any guidelines on that, it's so easy to edit an ENV var on Heroku we took it
for granted.

[1] [https://github.com/stellaservice/ky](https://github.com/stellaservice/ky)

~~~
Titanous
I'd love to hear about any trouble you ran into while trying Flynn so that we
can fix it! Feel free to send me an email: jonathan@flynn.io

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.

edited to add: We didn't know about this post until Bitmatica posted it, this
is just a great post from a happy user, not planned Flynn marketing!

~~~
bglusman
Yeah, definitely think you guys are both top notch projects, but the article
focused on you guys as the end solution and mentioned so many other things en
route, I felt people should see one of the other high profile contenders,
though forgot to add it was AWS only (added below). It's been a few months now
since I kind of timeboxed an hour or two to play with each of 3 I narrowed
down to as most likely to offer the easiest transition off of Heroku without
being single node like Dokku (you guys, Convox and Tsuru were the 3 I think I
tried, and got furthest with and was most impressed with Convox and Flynn). It
wasn't a totally fair comparison, as I think I ran Flynn and Tsuru locally via
Vagrant, because I could for both I think, but had to actually use real AWS
for Convox... but this was all just because I was hoping to make a case at
work that we should try one of these actual PaaS-like solutions rather than go
for a non-PaaS solution like Kubernetes, as I knew it would not be a trivial
transition, as the articles' author discovered. If I ever have time to try it
again I'll try and go a little further and provide feedback if I have any!

~~~
Titanous
Awesome, thanks for the feedback!

------
ggrochow
As someone who's been using flynn in production for a month or two, some
things to be aware of. (Devops is not one of my strongpoints, so keep that in
mind)

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, so we ran out
of HD space on our cluster, causing postgres to go into read-only mode. This
prevented us from pushing updates / changing any app-config settings ( ENV,
Scaling, etc ). Thankfully we were hosting our own DB off-cluster or that too
would have been read only.

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.

Obviously RTFM as well, (especially this part
[https://flynn.io/docs/production](https://flynn.io/docs/production)) we had
some other issues that could have easily been prevented.

Huge shout-out to the team that hangs out in their IRC channel, they were a
massive help in solving the problems we've came across.

Using it when it works is lovely, we switched off of heroku recently and its
been a very similar experience.

~~~
Titanous
> 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.

~~~
twic
Good luck with the out-of-memory handling. From personal experience, that's
easier said than done.

~~~
Titanous
Here's the issue tracking this:
[https://github.com/flynn/flynn/issues/3375](https://github.com/flynn/flynn/issues/3375)

------
mawalu
"However, a primary goal of our solution was to automate the process of going
from code in a repository to a deployed application in our cluster — much like
Heroku. Kubernetes did not appear have any mechanism to support this type of
workflow, nor a handful of other features we had hoped to find."

Just in case someone is feeling the same, deis[1] is providing exactly this. I
did not try their software but I've read a lot of positive about them in the
last time.

[1] [https://deis.com/](https://deis.com/)

~~~
stuntkite
I've been using deis in production for ~4 months. It's been great! If I can
fit something into a buildpack it's fast to iterate, for more complex concerns
you've got the kubernetes backing it up.

------
splitrocket
I run flynn as a local staging/CI service in our networking closet. It allows
us to rapidly try out new apps/services in an environment that approaches
production on a couple of machines we had lying around super quickly.

There are still a couple of rough edges, specifically around upgrading and
persistence across power failures, which is unlikely in a datacenter, but
aside from those things, all in all excellent.

In particular, though, the flynn.io team are particularly excellent in terms
of support.

~~~
hashkb
> In particular, though, the flynn.io team are particularly excellent in terms
> of support.

Seconding this. I've had many (like 10 or 20) very positive experiences with
them, where I went from "OMG WORLD IS ON FIRE" to "oh, sweet, I just delete
this row in postgres?"

------
magnotorres
We at Globo.com[1] are using docker in production before it was considered
ready for prod, with tsuru PaaS, as some features in tsuru(like self-healing)
made docker easy to handle, manage and scale containers. Tsuru has more than 4
years, it's really stable and reliable, we are attending huge traffics in a
large number of apps and it has lots of important features like multi
cluster(pool), metrics, auto scale, granular in relation to permissions of
users, etc. We are investing a lot in this project as anyone can see in our
repo[2] and we changed completely the way devs, (dev/)ops and product people
worked here. Tsuru was already easy to install(all in one VM[3,4]), and now we
have an experimental way[5] to make it in all IaaSs supported by docker
machine.

[1] Globo.com is the internet arm of Globo Group, the biggest broadcast
television in Brazil and second in the world [2]
[https://github.com/tsuru/tsuru](https://github.com/tsuru/tsuru) [3]
[https://github.com/tsuru/tsuru-bootstrap](https://github.com/tsuru/tsuru-
bootstrap) [4] [https://github.com/tsuru/now](https://github.com/tsuru/now)
[5]
[https://docs.tsuru.io/stable/experimental/installer.html](https://docs.tsuru.io/stable/experimental/installer.html)

------
jacques_chester
Since there are some Flynnsters hereabouts: do you run buildpacks unmodified?
How do you deal with fully disconnected environments?

I work on Cloud Foundry buildpacks, several of which are downstream from
Heroku's. So I'm professionally interested in seeing another perspective on
how to drive them.

~~~
Titanous
Yeah, we ship unmodified Heroku buildpacks, plus one Cloud Foundry buildpack
([https://github.com/cloudfoundry/staticfile-
buildpack](https://github.com/cloudfoundry/staticfile-buildpack)).

So far no one is using Flynn in a fully disconnected environment, and we're
aware of this limitation. My take on this is that we need a replacement for
buildpacks that allows for repeatable/functional builds (think Nix for app
deployment).

~~~
jacques_chester
I see, that definitely makes it easier. The Heroku code (quite reasonably)
assumes 100% connectivity.

One gotcha: if you are snapshotting images after building, your images are not
truly reproducible. Heroku occasionally swap out the binaries. This surprised
once or twice. This is one reason we wound up building all our own runtime
binaries[1].

When you get to disconnected environments, look us up. We built a whole
tooling, compile-extensions[2], to make it pretty close to seamless. We
intercept URLs and transform their either into our URLs or local copies of the
files.

(edit: actually, you could just switch to the Cloud Foundry buildpacks, since
they have an identical detect/compile/release cycle)

I agree that buildpacks are not the super long term solution. One area being
explored by engineers at Pivotal and IBM is to give a buildpack-like
experience to OCI layers[3]. I'm sure they'd be happy to work with you on this
as well.

[1] [https://github.com/cloudfoundry/binary-
builder](https://github.com/cloudfoundry/binary-builder) [2]
[https://github.com/cloudfoundry/compile-
extensions](https://github.com/cloudfoundry/compile-extensions) [3]
[https://www.youtube.com/watch?v=DSTT0przx4g&list=PLhuMOCWn4P...](https://www.youtube.com/watch?v=DSTT0przx4g&list=PLhuMOCWn4P9io8gtd6JSlI9
--q7Gw3epW&index=47)

------
mcescalante
I'm curious about any compelling reasons I should use something like Dokku or
Flynn if I already prefer to manage my own infra with something like Ansible
or Salt. Serious question, not a sarcastic rhetorical remark about this type
of tool :)

~~~
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.

~~~
jacques_chester
I work on Cloud Foundry, a competing system. Flynn is unarguably ahead in
certain features (and vice versa, in my biased opinion).

I agree with the thrust of your comment here: rolling your own PaaS is _hard_.
Just plain old hard. There's so much, _so damn much_ that you wind up having
to do.

Before I worked on CF I worked in Pivotal Labs. I got to see various custom
home-grown PaaSes. Some were brilliant. Some were terrible.

 _Every single one of them was a millstone_.

A lot of people don't realise it yet, but the Linux of our time has been
written -- in the sense that nobody writes an operating system if they're not
in the OS business.

I don't know if it's going to be Cloud Foundry, or Flynn, or OpenShift or some
mix of these, but we have already passed the point at which it makes rational
engineering sense for the 99% of engineers to build their own.

Disclosure: I work for Pivotal, the majority donor of engineering effort to
Cloud Foundry.

------
heyrhett
I looked into all the "Self-Hosted Heroku's" a few few months ago. One feature
I found they all lacked is multitenancy, meaning that there is no security
model in place to trust that you could host multiple pieces of code from
different clients without them hacking each other.

I'm not talking about the deployment specifically, but rather isolating the
code once it is deployed.

Am I missing something there?

~~~
splitrocket
Flynn's upcoming User/ACL model should cover multi-tenancy AFAIK.

~~~
Titanous
Yeah, our security roadmap will get us to multi-tenancy eventually.

Due to the security posture of the Linux kernel, we won't recommend running
untrusted code side-by-side on the same hosts as more sensitive workloads, but
we plan to harden everything to the maximum extent possible.

------
neokya
Looks like this is great project.

We are using powerful dedicated server to host multiple sites/apps like the
way shared hosting providers do. Maintenance and upgrade is so painful, I am
trying to move to something else.

I looked into Docker but seems things are still not stable. Another approach I
am looking into is KVM virtualization.

Aactually, all I want is something like Heroku (but self hosted or German
providers cause our clients are German and that's important) where we can host
each app on it's own container.

So far, this meets all the requirements.

~~~
aclimatt
That's precisely what we wanted, and we tried a lot of different options.
Flynn was the answer, definitely worth a try.

------
mr_luc
I don't compare Flynn with Heroku or Dokku. I compare it with Kubernetes.

When it comes to dev UX, I'd agree that Flynn's is better, though both are
easy to use. But I'd point to Convox for great dev UX in something that
deploys only to AWS, and that can use a dockerfile/binary artifact instead of
git push (I've been a minor contributor to Dokku and Convox, using both in
prod on a few different projects).

I mention k8s because "self-hosted" is mentioned in the title.

Personally, the main reason I've been doing personal projects in k8s over the
past 6 months or so is that 1) it offers out-of-the-box container networking
and dns-based discovery, and my side projects are all distributed software so
it makes it easy to get nodes talking, and 2) minikube runs a cluster where I
can actually scale my apps up and down and test out distributed software on my
laptop similarly to how it will be deployed.

(I'm investigating using Weave's ECS AMI, so that I can also get container
discovery and networking in Convox, because I love the Convox dev UX so very
much. But I'm also thinking, more and more, about how I can automate a
smoother dev UX for my k8s projects, because I also like being able to easily
run a real cluster locally in minikube, and Convox can run locally but with
only one instance of each app).

------
tracker1
Facing a similar situation a couple years ago, the solution I had pushed for
was just for a few (3) dokku servers setup behind an nginx server as a
reverse-proxy... the reason for multiple servers in our case was redundancy
first, this split allowed us to do the exact same deploy to three servers, run
tests, update nginx config then down the old version(s) of the apps.

Flynn and deis definitely seem interesting, as does the tooling that coreos
and docker themselves are working on.

------
bahmutov
I have been using Dokku for a year for personal side projects and it has been
awesome. Each release brings good features, fixes bugs and in general improves
it.

Setting up could never be easier (read [https://glebbahmutov.com/blog/running-
multiple-applications-...](https://glebbahmutov.com/blog/running-multiple-
applications-in-dokku/)) and the large number of plugins for databases is a
huge plus.

------
ohstopitu
I would love to have something like AWS Lambda that can be self hosted on
something like this or Flynn.

I know a lot of enterprises that are interested in using serverless arch (the
framework serverless[0], not the literal definition of not using servers) but
don't want to use AWS or other public cloud providers.

[0]: [https://serverless.com](https://serverless.com)

~~~
Titanous
This would be great!

The open source Parse server ([https://github.com/ParsePlatform/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.

------
dabeeeenster
Is there a way to dynamically auto-scale hosts? One of my app has very bursty
traffic, and would require scaling from 2 to 10 host servers and then back
down over a period of several hours. I can't see this referenced in the docs?
I can see you can scale processes but that's not increasing host resources
available, right?

~~~
Titanous
Flynn itself doesn't communicate with infrastructure APIs currently, but you
could hook this up so that there is a base set of three servers that are
always running and then an autoscaling group that watched your metrics or a
schedule and added/removed servers.

I'd be happy to explain this more on IRC if you're interested (#flynn on
Freenode).

~~~
dabeeeenster
Thanks for the reply. Is this something that you have planned in the future?

This aspect is a really big part of Heroku/AppEngine/Elastic Beanstalk and
saves me a tonne of money each month due to the auto-scaling that we get
(we're on AppEngine). Is there a reason projects like Flynn have not tackled
it? Or is it just a question of time?

~~~
Titanous
Yeah, it's definitely something we want to support in the future. Autoscaling
requires building some components that are aware of and can communicate the
underlying infrastructure APIs (AWS, GCP, Azure, DigitalOcean, OpenStack,
etc.) combined with app/host metrics. It's just a matter of putting the
implementation effort. We'll get there eventually.

~~~
dabeeeenster
Great stuff - thanks - good luck!

------
ukd1
Why not just use Heroku and actually build your product?

~~~
mbreedlove
Sometimes I have hobby projects that need more than the free tier of Heroku. I
get a lot more bang for buck somewhere like Vultr or Digital Ocean compared to
Heroku.

The standard tier at Heroku is 512MB RAM for $25. Over at Vultr, I can get 2GB
RAM for $20. I also get 45GB of SSD, so I don't have to pay for something like
Amazon S3 to store uploaded files.

If you're building an actual product, I agree with you, pay Heroku and focus
on building your product. However, there's a lot of people looking to host
smaller projects that wouldn't break even financially if they used Heroku.

~~~
njudah
Since ~mid 2015, the Hobby tier for Heroku has been $7 / month, and since last
month, includes SSL.

~~~
bacongobbler
...which is for hobbies, not businesses.

------
malnick
Take a look at dcos.io (Mesosphere's Data Center Operating System). DC/OS
provides a lot of the missing features you're after:

\- Persistant workloads \- Fine grained ACL's for RBAC

They're also working on shipping a consolidated logging and metrics API in
Winter of 2017 which will enabled users to get workload plus host-level logs
and metrics into almost any log and metrics aggregation solution (in your
case, ELK would be easy to ship to).

Best of all it runs on top of production proven scheduling software, Apache
Mesos, which has wide community adoption and support.

------
tscolari
You should check cloudfoundry ->
[https://cloudfoundry.org](https://cloudfoundry.org)

It's opensource, multi-tenant and widely tested (used) by big companies.

------
mmanfrin
Anyone have experience to how this compares with Deis (Workflow)? Last week I
spent an evening getting a small cluster set up with kubernetes and deis. It
looks to work very similar to Flynn.

~~~
Titanous
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.

~~~
jacques_chester
> _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._

I've taken to referring to this as "Not Invented Yet Syndrome". It's hard to
base an architecture on a subsystem that doesn't exist.

------
spitfire
Is there any HIPAA story for Flynn?

You can do HIPAA on AWS yourself or use (expensive vendors). However both of
these routes lose you the management/deployment abilities of things like
Heroku/Flynn.

~~~
tracker1
It seems to me, the security model needs to be similar to using EC2 itself...
you probably shouldn't run apps for multiple clients on the same host
instance, but you can run multiple services for the same client, and provision
version upgrades on a given client.

The docker security sandbox has had a few issues, and probably should not run
sensitive data for multiple partners on the same ec2 instance. ymmv though.

------
smartbit
How would Flynn compare to Cisco Mantl [https://blogs.cisco.com/cloud/mantl-
version-1-2-released-kub...](https://blogs.cisco.com/cloud/mantl-
version-1-2-released-kubernetes-fully-integrated)? Mantl is Open Source,
supports many Cloud platforms using Terraform including Openstack &
virtualBox, schedules with Kubernetes & Mesos, etc, etc: all the buzz-words
included :-)

BTW Met the Flynn team at 32C3, nice guys indeed.

------
ukd1
Did anyone checkout [https://convox.com/](https://convox.com/) \- which is a
more direct alternative to Heroku?

~~~
znpy
I read some of the convox docs a while ago, and the idea I got is that it is
an alternative, open heroku implementation which is nice but you're still
locked to Amazon AWS (and its prices)

------
artellectual
I too have been on a journey to create a heroku for myself. I finalised my
system on using rancher + drone ci combo.

You can watch a video of my setup here:
[https://www.youtube.com/watch?v=zxPB2v-tWvQ&list=PLjQo0sojbb...](https://www.youtube.com/watch?v=zxPB2v-tWvQ&list=PLjQo0sojbbxViGEbI_87SPXpb3neuVqDL&index=2)

------
afro88
Anyone using Erlang/Elixir on Flynn? Will distributed message sending between
deployed apps work?

~~~
Titanous
Yeah, check out this blog post about how to deploy Phoenix:
[http://nsomar.com/how-to-use-flynn-to-deploy-a-phenix-
app/](http://nsomar.com/how-to-use-flynn-to-deploy-a-phenix-app/)

Distributed communication should work fine, feel free to ping us on IRC or
GitHub if you run into any trouble or have any questions!

------
barkingcat
It isn't clear from the intro docs, but what OS's does Flynn run on?

The install guide mentions Ubuntu. Does it work on FreeBSD? Does it work on
other Linux distributions from the Redhat family (fedora, centos, rhel, etc)

~~~
jpgvm
Currently Flynn clusters must be running a Debian based distro. Out of the box
it works on Ubuntu 14.04 but you can get it to run easily on Debian or Ubuntu
16.04. It likely also works on RHEL based distributions.

The CLI can be installed on any Linux distribution, FreeBSD, Windows and OSX.

Disclaimer: I work on Flynn.

------
mwalburn
Curious if the folks looking for an "open source Heroku", whow found Flynn,
also looked at open source Cloud Foundry... and what turned them off from CF.

~~~
astrostl
I've been a part of running Cloud Foundry in production, both on-prem and in
AWS. From a user (developer) perspective, it's pretty magical: throw an app at
it, and it runs. On the infrastructure side, the footprint is huge and has a
ton of moving parts. If you have an SRE-type team to keep it alive, and your
organization is cool with major multi-tenancy, I'd say that it's good enough
for now. If it's dev-run, or if you want tenant scoping (e.g. one CF instance
per business unit, or other isolated kind of microservices) I would absolutely
not recommend it.

They are working on more lightweight versions. CF is pretty "enterprise," with
the good and the bad that entails.

------
evunveot
Anyone have experience with DC/OS? It runs on Mesos, not Kubernetes, but in
any case it seems very full featured.

[https://dcos.io/](https://dcos.io/)

------
sairamkunala
one more PaaS solution I found today -
[https://hasura.io/](https://hasura.io/) built on Kubernetes and Docker.
Thought this has some relevance here

------
softwarelimits
no autoscaling.

------
bbcbasic

      { tldr : 'https://flynn.io' }

------
xutopia
TLDR: We tried getting something similar to Heroku up and running but we ended
up going with a paid service that starts at 4299$/month.

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

Flynn is entirely open source and BSD-licensed
([https://github.com/flynn/flynn](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.

~~~
bduerst
Do you have a comparison chart or something lining Flynn up against
Azure/Heroku/Google App Engine somewhere?

I know it's probably not as feature-complete as those other PaaS's, but it
would be great to get it at a glance.

~~~
Titanous
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.

