An Open Source, Self-Hosted Heroku
41–50 of 123 posts
Re: An Open Source, Self-Hosted Heroku
#42Why not just use Heroku and actually build your product?
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.
Re: An Open Source, Self-Hosted Heroku
#43This 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 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…
+1 for convox ( https://convox.com/ ) we've been using it successfully for a number of our clients - it's easy to setup and run.
Re: An Open Source, Self-Hosted Heroku
#44I'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 :)
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.
Re: An Open Source, Self-Hosted Heroku
#45Did anyone checkout https://convox.com/ - which is a more direct alternative to Heroku?
Re: An Open Source, Self-Hosted Heroku
#46This 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 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…
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!
Re: An Open Source, Self-Hosted Heroku
#47I 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?
Re: An Open Source, Self-Hosted Heroku
#48Why not just use Heroku and actually build your product?
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 H…
Re: An Open Source, Self-Hosted Heroku
#49Re: An Open Source, Self-Hosted Heroku
#50I 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?
Flynn's upcoming User/ACL model should cover multi-tenancy AFAIK.
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.