11 ms·

An Open Source, Self-Hosted Heroku

443 points by stucat 10y ago

xutopia 10y ago
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.
- aclimatt 10y ago
  That's for Managed Flynn. We're using the open source version, which is free: https://github.com/flynn/flynn https://github.com/flynn/flynn
  - newsat13 10y ago
    And nothing for the support offered by the flynn team? I am also curious to find out what is the running cost for maintaining flynn. Is there one dedicated engineer minitoring the infra?
    - Titanous 10y ago
      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.
      - tracker1 10y ago
        For a small-mid sized company with an overworked dev manager, hiring out flynn for the cost of a Jr Systems Administrator sounds pretty reasonable.
    - aclimatt 10y ago
      Yep, the Flynn team helped us out via IRC and were fantastic. Especially as we were still working on getting pre-1.0 running, it was great to work with an engineer directly through the bumps. Obviously they do offer paid support as well, which is great for recurring issues and operational assistance. We do have a dedicated engineer managing / monitoring our infrastructure. It's not a set-it-and-forget-it kind of thing, so if you don't have somebody to manage your infrastructure, the hosted version might be a better choice. The big cost savings win was for all of our /other/ engineers who now don't need to know anything about ops to get their apps running. Previously with Chef, everybody was responsible for writing recipes and setting up environments, but now we have a standard set of buildpacks that work with our apps, and when we need to transfer an app to a client (as we're a dev agency), we can set it up on Heroku and it should "just work".
- Titanous 10y ago
  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 10y ago
    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 10y ago
      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.
splitrocket 10y ago
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.
- Titanous 10y ago
  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!
- hashkb 10y ago
  > 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?"
mbreedlove 10y ago
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
- christiangenco 10y ago
  Try out Flynn for sure, but from my experience with both Dokku is worlds simpler and more stable.
- zachwill 10y ago
  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?
  - nicksergeant 10y ago
    I currently have 16 apps deployed via Dokku on my 8GB Linode and am pretty happy with it. I have a wide variety of apps installed: Node, Django, Rails, and Elixir (Phoenix).
  - Shrugs 10y ago
    I'd also back dokku for small side projects. I have 4 small slack bots installed on my reserved t2micro instance and I'm pretty happy with it.
    - josegonzalez 10y ago
      Ah, if only people backed Dokku monetarily[1]. I'd probably get my ass in gear and release the multi-server functionality I prototyped over the summer. Nice to see that others are finding Flynn useful though, there is plenty of space for PaaS offerings, and I truly hope they are financially successful. [1] My experience in this area is that it's hard to get peple to pay for something that is free, which dis-incentivizes work/releases. I'm not surprised that many use the free version of Flynn, or that there were a ton of Heroku users that left once they stopped getting free resources 24/7. Dokku does take donations - https://opencollective.com/dokku https://opencollective.com/dokku - but to be quite honest, it's almost certainly nowhere near even 1% the amount of money we've saved our users.
ggrochow 10y ago
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 10y ago
  > 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 10y ago
    Good luck with the out-of-memory handling. From personal experience, that's easier said than done.
    - Titanous 10y ago
      Here's the issue tracking this: https://github.com/flynn/flynn/issues/3375 https://github.com/flynn/flynn/issues/3375
neokya 10y ago
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 10y ago
  That's precisely what we wanted, and we tried a lot of different options. Flynn was the answer, definitely worth a try.
mawalu 10y ago
"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 10y ago
  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.
bglusman 10y ago
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
- matthewcford 10y ago
  +1 for convox (https://convox.com/ https://convox.com/) we've been using it successfully for a number of our clients - it's easy to setup and run.
  - bglusman 10y ago
    Yeah I initially linked the .com then thought people might appreciate seeing the product, rack and its open source repo more :-) Weirdly when I set it up, it looked like with only a small change or two to our existing docker-compose.yml it "just worked", but the funny thing was once it was running I couldn't quickly manage to find the web service exposed anywhere to actually test... but it deployed painlessly and showed up running in several ec2 instances and a load balancer in our AWS console! Oh, that't another point, unlike Flynn, Convox is AWS only, so it's more opinionated/less flexible, but for many people that's not really a downside if you only plan to run it on AWS for now anyway. It's also built by a bunch of former Heroku engineers, including David Dollar (https://github.com/ddollar https://github.com/ddollar)
ohstopitu 10y ago
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 10y ago
  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.
- bglusman 10y ago
  Me too! We've been considering migrating off Lambda native to serverless or Chalice[1], but I keep thinking kubernetes is perfect for self-hosting this (or could be? Maybe?). I have one thing bookmarked in this direction, funcktion [2], and another that looks less... mature, open lambda [3] but would love to hear thoughts/other options if anyone has tried any of these. [1] https://github.com/awslabs/chalice https://github.com/awslabs/chalice [2] https://github.com/fabric8io/funktion https://github.com/fabric8io/funktion [3] http://www.open-lambda.org/ http://www.open-lambda.org/
bbcbasic 10y ago
{ tldr : 'https://flynn.io' }
mcescalante 10y ago
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 :)
- mbreedlove 10y ago
  I have a really extensive Ansible playbook for setting up my stack; nginx with extra modules, postgres, redis, and others like fail2ban. It all targets CentOS and also configures SELinux when appropriate. It all works well, until I want to do something that doesn't fit the mold that I've put myself in. For example, I wanted to get off Google Analytics and try out Piwik, which uses PHP and requires MySQL, Postgres isn't supported. It would have been really difficult to write out a bunch of Ansible config for PHP and MySQL, both technologies I'm not familiar with and don't know their best practices. So, I'm still using Google analytics. A similar story happened when I wanted to host a Tor relay. The allure of just pointing Dokku/Flynn to a pre-made Dockerfile for Piwik/Tor/ownCloud/etc. is pretty compelling. It let's me mix and match technologies without feeling like I'm polluting my server with a bunch of random services and tech. Containerization provides just enough separation to make me happy. I'm not sure if Dokku or Flynn is the golden goose I'm after, but it seems like a step in the right direction. I still use Ansible to do basic provisioning like users and SSH keys, setting up Fail2ban, and installing Dokku.
  - mcescalante 10y ago
    Hearing your workflow/tooling is handy and I may borrow an idea or two while playing around, thanks for writing this up :)
- josegonzalez 10y ago
  Probably user experience. If you've nailed that with your own infra and made it easy to manage the lifecycle of services for your developers, then there isn't really any need to "reinvent the wheel". Infrastructure doesn't stop working just because there isn't any docker in it.
- 10y ago
ukd1 10y ago
Why not just use Heroku and actually build your product?
- ukd1 10y ago
  Down votes, but avoiding answering the question, classy!
- mbreedlove 10y ago
  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 10y ago
    Since ~mid 2015, the Hobby tier for Heroku has been $7 / month, and since last month, includes SSL.
    - bacongobbler 10y ago
      ...which is for hobbies, not businesses.
- Titanous 10y ago
  If Heroku works for you, that's fine, but for lots of people it doesn't. For example, Heroku only supports HTTP, not TCP. There are a number of technical limitations Heroku places on apps that other platforms like Flynn don't. There are lots of reasons why users need a different, or especially an open source, PaaS. Some users run into scaling problems when their products grow beyond a certain point. Others want to have more control over their infrastructure for compliance, governance, or other administrative reasons. Others have huge deployments and want to save money by using their own cloud accounts. It varies from customer to customer, but for many Heroku isn't an option or isn't the best option.
heyrhett 10y ago
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 10y ago
  Flynn's upcoming User/ACL model should cover multi-tenancy AFAIK.
  - Titanous 10y ago
    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.
- jacques_chester 10y ago
  You aren't missing something here, it's necessary for reasons best explained -- by way of slight analogy -- by Sir Humphrey Appleby: > Jim Hacker: People can wait in the lobby. Or in the state rooms. > Sir Humphrey Appleby: Some people. But some people must wait where other people cannot see the people who are waiting. And people who arrive before other people must wait where they cannot see the people who arrive after them being admitted before them. And people who come in from outside must wait where they cannot see the people from inside coming in to tell you what the people from outside have come to see you about. And people who arrive when you are with people they are not supposed to know you have seen must wait somewhere until the people who are not supposed to have seen you have seen you. This is one of the priority engineering efforts for Cloud Foundry at the moment. People want it. Disclosure: I work for Pivotal, the majority donor of engineering to Cloud Foundry. I guess that makes us competitors to Flynn.
ukd1 10y ago
Did anyone checkout https://convox.com/ https://convox.com/ - which is a more direct alternative to Heroku?
- znpy 10y ago
  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)
- ukd1 10y ago
  https://www.quora.com/What-are-some-open-source-Heroku-alternatives https://www.quora.com/What-are-some-open-source-Heroku-alter... has some more answers (I just added an answer). As of today, the list (in no particular order) is looking like: Convox, Flynn, Dies, Dokku, Tsuru, Apache Stratos, cloudify-cos, Openshift, etc
evunveot 10y ago
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/
dabeeeenster 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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 10y ago
        Great stuff - thanks - good luck!
    - jacques_chester 10y ago
jacques_chester 10y ago
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 10y ago
  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 10y ago
    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=PLhuMOCWn4P9io8gtd6JSlI9--q7Gw3epW&index=47 https://www.youtube.com/watch?v=DSTT0przx4g&list=PLhuMOCWn4P...
spitfire 10y ago
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.
- Titanous 10y ago
  There are healthcare companies that already use Flynn today, though not for HIPAA compliance specifically. Compliance is a really interesting vertical. As we make progress on our security roadmap, Flynn will become a very compelling option for environments like HIPAA, PCI, etc. especially when combined with clouds like AWS that are also compliant.
- tracker1 10y ago
  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.
tracker1 10y ago
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.
mmanfrin 10y ago
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 10y ago
  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 10y ago
    > 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.
mwalburn 10y ago
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.
- joneholland 10y ago
  The pivotal shilling on hacker news is one reason.
- astrostl 10y ago
  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.
artellectual 10y ago
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=PLjQo0sojbbxViGEbI_87SPXpb3neuVqDL&index=2 https://www.youtube.com/watch?v=zxPB2v-tWvQ&list=PLjQo0sojbb...
tscolari 10y ago
You should check cloudfoundry -> https://cloudfoundry.org https://cloudfoundry.org It's opensource, multi-tenant and widely tested (used) by big companies.
barkingcat 10y ago
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 10y ago
  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.
smartbit 10y ago
How would Flynn compare to Cisco Mantl https://blogs.cisco.com/cloud/mantl-version-1-2-released-kubernetes-fully-integrated https://blogs.cisco.com/cloud/mantl-version-1-2-released-kub...? 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.
afro88 10y ago
Anyone using Erlang/Elixir on Flynn? Will distributed message sending between deployed apps work?
- Titanous 10y ago
  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!
softwarelimits 10y ago
no autoscaling.
sairamkunala 10y ago
one more PaaS solution I found today - https://hasura.io/ https://hasura.io/ built on Kubernetes and Docker. Thought this has some relevance here
malnick 10y ago
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.
bahmutov 10y ago
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-in-dokku/ https://glebbahmutov.com/blog/running-multiple-applications-...) and the large number of plugins for databases is a huge plus.
mr_luc 10y ago
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).
tofupup 10y ago
neat
magnotorres 10y ago
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

443 points by stucat 10y ago

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.

aclimatt 10y ago
That's for Managed Flynn. We're using the open source version, which is free: https://github.com/flynn/flynn https://github.com/flynn/flynn
- newsat13 10y ago
  And nothing for the support offered by the flynn team? I am also curious to find out what is the running cost for maintaining flynn. Is there one dedicated engineer minitoring the infra?
  - Titanous 10y ago
    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.
    - tracker1 10y ago
      For a small-mid sized company with an overworked dev manager, hiring out flynn for the cost of a Jr Systems Administrator sounds pretty reasonable.
  - aclimatt 10y ago
    Yep, the Flynn team helped us out via IRC and were fantastic. Especially as we were still working on getting pre-1.0 running, it was great to work with an engineer directly through the bumps. Obviously they do offer paid support as well, which is great for recurring issues and operational assistance. We do have a dedicated engineer managing / monitoring our infrastructure. It's not a set-it-and-forget-it kind of thing, so if you don't have somebody to manage your infrastructure, the hosted version might be a better choice. The big cost savings win was for all of our /other/ engineers who now don't need to know anything about ops to get their apps running. Previously with Chef, everybody was responsible for writing recipes and setting up environments, but now we have a standard set of buildpacks that work with our apps, and when we need to transfer an app to a client (as we're a dev agency), we can set it up on Heroku and it should "just work".
Titanous 10y ago
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 10y ago
  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 10y ago
    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.

splitrocket 10y ago

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.

Titanous 10y ago
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!
hashkb 10y ago
> 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?"

mbreedlove 10y ago

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

christiangenco 10y ago
Try out Flynn for sure, but from my experience with both Dokku is worlds simpler and more stable.
zachwill 10y ago
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?
- nicksergeant 10y ago
  I currently have 16 apps deployed via Dokku on my 8GB Linode and am pretty happy with it. I have a wide variety of apps installed: Node, Django, Rails, and Elixir (Phoenix).
- Shrugs 10y ago
  I'd also back dokku for small side projects. I have 4 small slack bots installed on my reserved t2micro instance and I'm pretty happy with it.
  - josegonzalez 10y ago
    Ah, if only people backed Dokku monetarily[1]. I'd probably get my ass in gear and release the multi-server functionality I prototyped over the summer. Nice to see that others are finding Flynn useful though, there is plenty of space for PaaS offerings, and I truly hope they are financially successful. [1] My experience in this area is that it's hard to get peple to pay for something that is free, which dis-incentivizes work/releases. I'm not surprised that many use the free version of Flynn, or that there were a ton of Heroku users that left once they stopped getting free resources 24/7. Dokku does take donations - https://opencollective.com/dokku https://opencollective.com/dokku - but to be quite honest, it's almost certainly nowhere near even 1% the amount of money we've saved our users.

ggrochow 10y ago

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 10y ago
> 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 10y ago
  Good luck with the out-of-memory handling. From personal experience, that's easier said than done.
  - Titanous 10y ago
    Here's the issue tracking this: https://github.com/flynn/flynn/issues/3375 https://github.com/flynn/flynn/issues/3375

neokya 10y ago

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 10y ago
That's precisely what we wanted, and we tried a lot of different options. Flynn was the answer, definitely worth a try.

mawalu 10y ago

"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 10y ago
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.

bglusman 10y ago

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

matthewcford 10y ago
+1 for convox (https://convox.com/ https://convox.com/) we've been using it successfully for a number of our clients - it's easy to setup and run.
- bglusman 10y ago
  Yeah I initially linked the .com then thought people might appreciate seeing the product, rack and its open source repo more :-) Weirdly when I set it up, it looked like with only a small change or two to our existing docker-compose.yml it "just worked", but the funny thing was once it was running I couldn't quickly manage to find the web service exposed anywhere to actually test... but it deployed painlessly and showed up running in several ec2 instances and a load balancer in our AWS console! Oh, that't another point, unlike Flynn, Convox is AWS only, so it's more opinionated/less flexible, but for many people that's not really a downside if you only plan to run it on AWS for now anyway. It's also built by a bunch of former Heroku engineers, including David Dollar (https://github.com/ddollar https://github.com/ddollar)

ohstopitu 10y ago

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 10y ago
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.
bglusman 10y ago
Me too! We've been considering migrating off Lambda native to serverless or Chalice[1], but I keep thinking kubernetes is perfect for self-hosting this (or could be? Maybe?). I have one thing bookmarked in this direction, funcktion [2], and another that looks less... mature, open lambda [3] but would love to hear thoughts/other options if anyone has tried any of these. [1] https://github.com/awslabs/chalice https://github.com/awslabs/chalice [2] https://github.com/fabric8io/funktion https://github.com/fabric8io/funktion [3] http://www.open-lambda.org/ http://www.open-lambda.org/

bbcbasic 10y ago

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

mcescalante 10y ago

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 :)

mbreedlove 10y ago
I have a really extensive Ansible playbook for setting up my stack; nginx with extra modules, postgres, redis, and others like fail2ban. It all targets CentOS and also configures SELinux when appropriate. It all works well, until I want to do something that doesn't fit the mold that I've put myself in. For example, I wanted to get off Google Analytics and try out Piwik, which uses PHP and requires MySQL, Postgres isn't supported. It would have been really difficult to write out a bunch of Ansible config for PHP and MySQL, both technologies I'm not familiar with and don't know their best practices. So, I'm still using Google analytics. A similar story happened when I wanted to host a Tor relay. The allure of just pointing Dokku/Flynn to a pre-made Dockerfile for Piwik/Tor/ownCloud/etc. is pretty compelling. It let's me mix and match technologies without feeling like I'm polluting my server with a bunch of random services and tech. Containerization provides just enough separation to make me happy. I'm not sure if Dokku or Flynn is the golden goose I'm after, but it seems like a step in the right direction. I still use Ansible to do basic provisioning like users and SSH keys, setting up Fail2ban, and installing Dokku.
- mcescalante 10y ago
  Hearing your workflow/tooling is handy and I may borrow an idea or two while playing around, thanks for writing this up :)
josegonzalez 10y ago
Probably user experience. If you've nailed that with your own infra and made it easy to manage the lifecycle of services for your developers, then there isn't really any need to "reinvent the wheel". Infrastructure doesn't stop working just because there isn't any docker in it.
10y ago

ukd1 10y ago

Why not just use Heroku and actually build your product?

ukd1 10y ago
Down votes, but avoiding answering the question, classy!
mbreedlove 10y ago
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 10y ago
  Since ~mid 2015, the Hobby tier for Heroku has been $7 / month, and since last month, includes SSL.
  - bacongobbler 10y ago
    ...which is for hobbies, not businesses.
Titanous 10y ago
If Heroku works for you, that's fine, but for lots of people it doesn't. For example, Heroku only supports HTTP, not TCP. There are a number of technical limitations Heroku places on apps that other platforms like Flynn don't. There are lots of reasons why users need a different, or especially an open source, PaaS. Some users run into scaling problems when their products grow beyond a certain point. Others want to have more control over their infrastructure for compliance, governance, or other administrative reasons. Others have huge deployments and want to save money by using their own cloud accounts. It varies from customer to customer, but for many Heroku isn't an option or isn't the best option.

heyrhett 10y ago

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 10y ago
Flynn's upcoming User/ACL model should cover multi-tenancy AFAIK.
- Titanous 10y ago
  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.
jacques_chester 10y ago
You aren't missing something here, it's necessary for reasons best explained -- by way of slight analogy -- by Sir Humphrey Appleby: > Jim Hacker: People can wait in the lobby. Or in the state rooms. > Sir Humphrey Appleby: Some people. But some people must wait where other people cannot see the people who are waiting. And people who arrive before other people must wait where they cannot see the people who arrive after them being admitted before them. And people who come in from outside must wait where they cannot see the people from inside coming in to tell you what the people from outside have come to see you about. And people who arrive when you are with people they are not supposed to know you have seen must wait somewhere until the people who are not supposed to have seen you have seen you. This is one of the priority engineering efforts for Cloud Foundry at the moment. People want it. Disclosure: I work for Pivotal, the majority donor of engineering to Cloud Foundry. I guess that makes us competitors to Flynn.

ukd1 10y ago

Did anyone checkout https://convox.com/ https://convox.com/ - which is a more direct alternative to Heroku?

znpy 10y ago
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)
ukd1 10y ago
https://www.quora.com/What-are-some-open-source-Heroku-alternatives https://www.quora.com/What-are-some-open-source-Heroku-alter... has some more answers (I just added an answer). As of today, the list (in no particular order) is looking like: Convox, Flynn, Dies, Dokku, Tsuru, Apache Stratos, cloudify-cos, Openshift, etc

evunveot 10y ago

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/

dabeeeenster 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      Great stuff - thanks - good luck!
  - jacques_chester 10y ago

jacques_chester 10y ago

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 10y ago
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 10y ago
  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=PLhuMOCWn4P9io8gtd6JSlI9--q7Gw3epW&index=47 https://www.youtube.com/watch?v=DSTT0przx4g&list=PLhuMOCWn4P...

spitfire 10y ago

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.

Titanous 10y ago
There are healthcare companies that already use Flynn today, though not for HIPAA compliance specifically. Compliance is a really interesting vertical. As we make progress on our security roadmap, Flynn will become a very compelling option for environments like HIPAA, PCI, etc. especially when combined with clouds like AWS that are also compliant.
tracker1 10y ago
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.

tracker1 10y ago

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.

mmanfrin 10y ago

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 10y ago
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 10y ago
  > 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.

mwalburn 10y ago

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.

joneholland 10y ago
The pivotal shilling on hacker news is one reason.
astrostl 10y ago
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.

artellectual 10y ago

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=PLjQo0sojbbxViGEbI_87SPXpb3neuVqDL&index=2 https://www.youtube.com/watch?v=zxPB2v-tWvQ&list=PLjQo0sojbb...

tscolari 10y ago

You should check cloudfoundry -> https://cloudfoundry.org https://cloudfoundry.org It's opensource, multi-tenant and widely tested (used) by big companies.

barkingcat 10y ago

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 10y ago
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.

smartbit 10y ago

How would Flynn compare to Cisco Mantl https://blogs.cisco.com/cloud/mantl-version-1-2-released-kubernetes-fully-integrated https://blogs.cisco.com/cloud/mantl-version-1-2-released-kub...? 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.

afro88 10y ago

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

Titanous 10y ago
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!

softwarelimits 10y ago

no autoscaling.

sairamkunala 10y ago

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

malnick 10y ago

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.

bahmutov 10y ago

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-in-dokku/ https://glebbahmutov.com/blog/running-multiple-applications-...) and the large number of plugins for databases is a huge plus.

mr_luc 10y ago

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

tofupup 10y ago

neat

magnotorres 10y ago

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