Dokku is nice and I used it for a while but recently I've been using CapRover [0] and been pretty happy with it. I only use it on 1 host but it supports multiple. It also has 1-click installs for the usual suspects (drupal/wordpress/etc) and things like spinning up a DB is easy. You can also define a docker file in your repo that you instruct it to build and use. HTTPS is a button click and it automatically sets up virtual hosts for you `<your app name>.<base url you configured>`. It's great for quick prototyping and to get a personal project online.
Caprover is nice and convenient but security wise, only a single password field is required on the admin console. (See demo here: https://captain.server.demo.caprover.com/#/login)
Given this it would be nice to at least make the web admin console only accessible via an IP whitelist, but last time I used it I did not find an easy way to do that.
I haven’t used it but it appears to serve everything over the same port. You could block it with a reverse proxy but not with a firewall or layer 4 proxy.
It's been pretty reliable for me but I've never used it in production. It's more of a testing grounds-type tool for me or a way to see my work online at a stable URL (which helps motivate me to continue working on something). That's not to say it can't handle production (the multiple hosts aspect certainly indicates it means to support that use-case), just that I can't speak on it.
On thing that's cool (to me) is that I once borked an update of the CapRover admin and while I couldn't get into the dashboard all my projects kept humming along without a care in the world because they were all in their own docker containers. I thought that was pretty neat (all of CapRover runs inside of containers as well and seems to be independent of apps it manages/monitors.
We have an official (paid, one-time fee) web ui here: https://pro.dokku.com/ . It's under active development.
There are others (ledokku, wharf, bullet, etc.) that folks in the community have developed/maintained, though I cannot comment on them as I haven't used them for more than 5 minutes.
I came to the comments first to answer "what's the catch?". There were no comments at the time so I went to the website. This line near the top seems particularly fair and believable.
> Own your own PAAS. Infrastructure at a fraction of the cost. Powered by Docker, you can install Dokku on any hardware. Use it on inexpensive cloud providers. Use the extra cash to buy a pony or feed kittens. You'll save tens of dollars a year on your dog photo sharing website.
For me, one of the big catches is that you have a single point of failure. Dokku doesn't run over multiple VMs you have. It's on a VM. If that VM goes down, you're down.
I think one of the selling points of Heroku is that if the box you're running on goes down, your service will just be started on another box and traffic will be routed there and you don't need to do anything.
One way to overcome that might be to use ansible to automate:
1. Dokku setup on a new server
2. Deploy your app from a git repository
3. Restore your database from backup
If you aren't comfortable with ansible you can use Fabric [0] or Sup [1]. I think there's even an ansible guide for Dokku deployment on their blog [2].
If you want a much more highly available open source Heroku, there is Cloud Foundry which is used as the basis for a few public PaaS like IBM Bluemix and SAP Cloud Platform. The smallest HA set up is about 50 VMs though, and it's complicated to deploy so not really worth it if you have fewer than 1,000 or so developers to support.
If the box you are running in is a VM, the VM host is already providing hardware redundancy. It’s not full redundancy but in practice it’s sufficient for dog photo sharing sites.
As far as I know only Google Cloud does ‘hardware redundancy’[0]. I’ve had single-instance outages in AWS and they don’t seem to really care if something goes wrong with your instance, although maybe they have more maintenance events than they let on and they might happen transparently to the user thanks to some form of live migration.
I’m not talking about live migration - the instance will go down and there will be a brief outage while the instance restarts on another hypervisor. The same is true of a single dyno Heroku app.
For AWS, nothing involved there is automatic; you have to stop it* and then restart it. It will just stay broken until you restart it yourself. "Brief outage" suggests it might be automatic but in AWS it's not.
* Possibly multiple times. Instances on degraded hosts have a tendency to get stuck and you have to stop, and then stop again to force stop it, and then sometimes even that doesn't work and you have to just wait.
Source: have received lots of "EC2 Instance Retirement" emails
This is what autoscaling groups are for, right? If set the autoscaler to keep one instance running it will spin another one when they retire the one you’re using.
An ASG isn’t nearly as difficult as setting up, securing, and running dokku. There’s even examples and such for setting up the ASG. If you get stuck, all accounts have free support and stack overflow is a few clicks away. The idea that one needs to switch to dokku to avoid setting up ASGs is just silly.
Oh, hey! I used Dokku back in the ... I want to say 2012-2013 ? and missed multi-node stuff a bit (nothing that couldn't be scripted around) so this looks cool.
I do see that it shouts 'EXPERIMENTAL!', so I guess it's 'experimental, but official'.
The warning there is more that if the scheduler plugins land in the core (which I hope to do some day), the official usage may change.
For instance, I'd love to abstract our ingress plugin such that it plays nicely with Kubernetes and Nomad (Nomad in particular, since there is no notion of ingress there at all) but that may mean that the ingress controlling functionality in the Kubernetes plugin changes signficantly.
Dokku _also_ has no notion of autoscaling at the moment, though both Kubernetes and Nomad have autoscaling tooling. It would be great to expose this officially somehow vs the plugin-specific method that is exposed in Kubernetes.
Note that at least the Kubernetes plugin is in active usage - even in at least two commercial products being actively sold.
- You can host the data for the install on a mounted volume, and replace the underlying instance at will (if you're using something like AWS or GCP).
- We support alternative schedulers (Kubernetes and Nomad, with others like Compose, Lambda, and Swarm coming soon). In the case of using an alternate scheduler, your apps won't go down if the build server goes down.
- Since it is self-hosted, your Dokku install's uptime is pegged to your infrastructure's uptime. So yeah, if you are installing it on a Raspberry PI whose uptime is decided by a light switch that is next to your kitchen and you accidentally switch it off every once in a while due to not being able to see the switch at night (very specific example, I know), then yeah, you'll be down for a little while.
If a service is marketed as an "alternative" to any competitor, I think it's generally reasonable to assume that service covers most of the basic features offered by that competitor.
I've seen tons of "Heroku alternatives" pop up over the past couple months, but they all seem to have (rather large, IMO) downsides of "it does A and B like Heroku, but not X, Y, and Z" (where again, IMO, X, Y, and Z are typically rather core features like redundancy/failover). I know everyone uses services for different reasons, but the general appeal of Heroku that I've seen has been the basically-zero-devops-ever-necessary-for-anything approach they've taken.
If you are looking for a HA alternative, Qovery is the one. It's a Heroku like platform running on AWS built for running production workload. It's multi AZ by design.
I've used it on and off. It's ok and I was happy. But it's a fairly thin layer and a leaky abstraction, so I ended up looking at docker logs and firewall rules more times than needed. Unfortunately when things were down, noting the context was not a priority, so I don't have specific issues raised to show.
While in some cases it is a quite thin layer - some commands just proxy along to the underlying Docker command + some flags - I'd love to hear more about places where Dokku itself wasn't useful for debugging your deployed system. Please feel more than free to reach out via Discord/IRC/Slack[1] (all three are synced) with more info if filing an issue is a big reach. I'm more than happy to help folks debug live/file issues as a result, as it makes the project much better.
Can't recommend Dokku enough. I've been using it for years on a $20 DigitalOcean box. I have a lot of random web projects/tools, most of which I'm the only user, and it's great to have a super simple way to get them online. Enabling HTTPS and assigning a domain are each just a single command.
The same here, and that I can host multiple projects on the same server without any additional cost. If I get enough traffic I can always move it to a new server and redirect the DNS (cloudflair)
Last I used dokku my understanding was that it used Heroku's open source build packs. So it was very much your own hosted heroku. This was at least 7 years ago though.
Dokku supports a number of methods to deploy apps:
- Docker images [1]: via `git:from-image`
- Tarballs [2] (extracting into a heroku-like env): via `git:from-archive`
- Dockerfile [3]: autodetected using our builder-dockerfile plugin (or selectable via builder:set)
- Heroku Buildpacks [4]: autodetected using our builder-herokuish plugin (or selectable via builder:set)
- Cloud Native Buildpacks [5]: autodetected using our builder-nix plugin (or selectable via builder:set)
Someone in the community hated these options and wrote one for nix[6]. Others are free to do so as well (or even customize our built-in ones through settings or forks).
Finally, I've also got two builders in the works:
- lambda: builds a lambda-compatible docker image (and an optional zipball of the code in case you want to deploy that on their official runtimes)
- compose: builds using docker-compose (for usage with a compose scheduler)
Dokku has been built with extensibility in mind, so if it doesn't do what you think it should do out of the box, overriding that functionality is fairly straightforward (plugins can be in any language, so feel free to drop golang/shell and use something else if that floats your boat).
- [1] Build from a docker image: https://dokku.com/docs/deployment/methods/git/#initializing-an-app-repository-from-a-docker-image
- [2] Build from a tarball or zipball: https://dokku.com/docs/deployment/methods/git/#initializing-an-app-repository-from-an-archive-file
- [3] Dockerfile support: https://dokku.com/docs/deployment/builders/dockerfiles/
- [4] Heroku buildpack support: https://dokku.com/docs/deployment/builders/herokuish-buildpacks/
- [5] Cloud Native Buildpacks support: https://dokku.com/docs/deployment/builders/cloud-native-buildpacks/
- [6] Build via nix-build: https://github.com/jameysharp/dokku-builder-nix
I guess it comes down do your preference, it's just a GUI for Docker you can do the same Docker commands and container manipulation with or without it.
Is there proper tutorial for people who have never used heroku? I just don't know how to use this because i dont have any experience with heroku.
I'm interesting in self-hosted AWS api compatible solutions.
Parse is also interesting. In fact I discovered that there is a whole new world outside AWS and DO. It no longer makes sense for me to run weekend projects on AWS outright, thats really for large enterprise applications.
What I would love is to be able to deploy my docker images on my "own"cloud running on a dozen droplets/VPS around the world and bill my users at the same rate that AWS is charging. I figure I would be able to undercut AWS significantly with this method.
Storing 2TB on AWS was price shock for me, makes no sense when there are dedicated servers with a ton of storage and bandwidth that I could just use instead of being "serverless".
However, I find it to be a hall of mirrors, wondering if anybody on HN has been in my shoes and how they are handling it. I guess my biggest concerns:
- uptime availability (can I promise close to AWS?)
- security (how do i harden my box/selfcloud and have peace of mind?)
- IAM type of roles/permissions (how do i emulate something like IAM for my team?)
Like the billing from AWS is getting to a point where I feel like we can use bunch of droplets behind some "selfcloud" that manages all these things for me. I'm sure a solution exists, I just often have trouble recalling their names. Dokku makes it easy to remember because it sorta rhymes with Heroku.
Just use railway.app - free tier just works and you can deploy a sample app on a free account in seconds. It will give you a general idea of how Heroku works.
> It no longer makes sense for me to run weekend projects on AWS outright, thats really for large enterprise applications.
depending on the type of site, cf workers is ridiculous value. single button availability of your content in every corner of the world and you wont pay a dime
not sure I quite understand railway, what are they offering? Another AWS on Digitalocean? Would be nice to see exactly what the cpu core/memory/price is.
aren't cf workers very constrained? like your call has to finish within a second or two for it to make sense and I think AWS Lambda matched their price? I could be confused here.
S3 promises 99.999999999% durability and 99.99% availability... I'm not sure regular VPS's give any assurance that your data won't be lost. I assume in case of HDD failure it's up to you to restore data.
There is a tutorial for using it. It's linked to after you install it for the first time, and is available here[1]. It goes through a few common tasks, though by no means is a "kitchen sink" tutorial.
In regards to your specific questions:
- I've answered this elsewhere, but your uptime is defined by your host uptime (and any mechanisms for backup/restore you have setup). Some hosting providers (AWS/GCP) provide migration of hosts that die, some have block storage (Azure/AWS/DO/GCP), while others (Rackspace) provide backups of specific directories. As with anything you run and maintain, very heavy YMMV here, but I'm happy to answer questions[2] specific to your needs.
- Dokku runs very few/no persistent binaries (atm only an optional event-listener that restarts apps if it detects a web container has changed it's IP address), so the attack vectors are your app and anything else you are running that exposes ports externally (SSH is the big one). I defer to others on container security, but our default Herokuish (and Pack) images are built to run processes as non-root users, so that should provide _some_ level of isolation. Container security is a big space, so I don't want to write something here that will be outdated in three seconds or is just plain wrong. If you have concerns about specific things in the project, please get in touch[2].
- I've used metadataproxy[3] to lock down IAM roles on a per-app basis (with a custom plugin injecting the correct container env var for each app). If you need to lock apps to specific users, there is the community dokku-acl[4] plugin. I'm also working on team management support in Dokku Pro[5] which will be a bit more familiar to users of Heroku.
- I know of a few users using our kubernetes plugin[6] (automated via terraform) against mostly default Kubernetes clusters in Digitalocean and AWS. If the Dokku host dies, they just lose the ability to deploy, but can restore access fairly quickly. Everything else just kinda lives out there on their cluster.
Feel free to reach out[1] and I'll try and answer any specific concerns :)
- [1] Official tutorial: https://dokku.com/docs/deployment/application-deployment/
- [2] Ways to get in touch: https://dokku.com/docs/getting-started/where-to-get-help/
- [3] metadataproxy: https://github.com/lyft/metadataproxy
- [4] dokku-acl: https://github.com/dokku-community/dokku-acl
- [5] Dokku Pro: https://pro.dokku.com/
- [6] Kubernetes Scheduler plugin: https://github.com/dokku/dokku-scheduler-kubernetes
It is a way to get the same sort of developer experience benefit as dokku, but without dockers and containers, using plain UNIXy tools on a single Linux node. The above link explains how it works.
For those worried about a Single Point of Failure, you can't have your cake and eat it too. Docker and Dokku is a single point of failure when you build directly on it, I guess. Kubernetes mitigates that.
We're still here, keeping the tires on. I haven't personally tested K8s 1.24 with Workflow yet, but we are actively seeking maintainers on all of the cloud vendors.
If you find that something is broken and want to see it fixed, talk to me on Slack. I'm aware of at least Azure that has broken their Bucket Storage API since Workflow was originally published by Deis, and it hasn't been quite fixed yet.
Documented support for Google Cloud and AWS are both extant as well, although I've heard one person call into question whether Google Cloud storage will work out of the box, or if it still needs upgrades. We'd like to add DigitalOcean support as well, I already know it basically works, we just need to add documentation and probably also give it a quick spit-shine and polish.
Dokku on the other hand is less heavyweight and does not require as much work for maintenance, since it does not have to be decentralized or protect against any SPOF. It's a wonder that more people do not want to use this. I've heard of at least one more Deis Workflow fork in the wild, possibly in better or worse states of maintenance than Team Hephy, but if you are looking to get off of Heroku then you could certainly do much worse.
We do need volunteers as we do not have time to maintain everything by ourselves, (come talk to us on the Slack if you're interested in joining the fun!)
I’ve run high-ish traffic production sites on Dokku for years. If you need just one server, it’s a dream for Rails/PG/Redis setup. Amazing what reliability it provides. Almost completely written in bash!
Awesome. I’ve always worried what it can handle, and therefore only run projects on it until they were more serious. But in that context, I’ve never had a problem (and run them longer than that anyway). To around the 50-100k user per month. Mostly reads tho.
Could you share more, please? I use the very same stack and I think with the biggest VPS available right now I will have more than enough. It is basically a simple CRUD application.
Could you share how big the VPS yo used is (cores/Ram) and what traffic you got to manage with that?
Not the parent but to me dokku shines when putting multiple apps on a single server and the fact that deploying is a git push. Letsencrypt and other plugins are icing on the cake.
If you have one app then dedicate a server to it and run it right on the operating system. Maybe have 2 and a load balancer so you can do prod deployments with no downtime. The point is get dokku, docker, and all that abstraction between the network card and your app out of the way.
Yes, I love Dokku and like to use it as an alternative for some of my Heroku apps. However, the thing I miss most is Heroku including a nice dashboard showing several metrics for my Golang apps (memory usage, go-routines, etc) over time. Heroku has that out of the box and that makes it very convenient.
I cannot guarantee the cloud provider bits all work, I don't use them so I don't maintain them, but if you have Kubernetes with persistent disk provided, which any managed Kubernetes can most certainly do, it's easy enough to hook up generic Minio (which has the added benefit of working just as well on bare metal hosts), and I'm certain that does work as I use it.
> It is much easier to just use it than to try and re-invent your own
Now listen buddy... That CV is not gonna pad itself, ok?
Seriously though, if you have time and curiosity, I'd recommend putting together a monitoring stack by hand once. There's a lot to learn from that experience.
My go-to stack is Prometheus and Grafana with kube-prometheus-stack Helm chart for Kubernetes.
I'm sure I'm not configuring it well.
There are too many leaps I couldn't follow directly in how to make the config, and there's something about how arrays merge in YAML that makes it harder to write a config like this in Helm... so there is a lot of what I've written here that shouldn't need to be in my own config, because they are the standard default alerts, but I wound up having to include them to make my one extra alert join the rest (and this is my excuse for why it is several hundred lines long, when in reality it's mostly stock.)
This config goes so far as making alerts to Slack with Alertmanager that work out of the box!
A golang app exposes several metrics by default already. A common way is using Prometheus to collect the data and use Grafana to create a graphic dashboard. But it takes some configuration and needs those services running somewhere. Not something I want to spend much time on.
Similar to Heroku deploy flow, checkout Sailor, a tiny PaaS to install on your servers/VPS that uses git push to deploy micro-apps, micro-services, sites with SSL, on your own servers or VPS.
I see it's a fork of piku, but I don't see an explanation of why they bothered to fork. Do you know what the difference is? https://github.com/piku/piku
I didn’t know this existed (probably because my dokku setip had been running for years and I haven’t been back to the website). I will be throwing some bread your way:)
The single point of failure though, is something people worry too much about. If you are serious about what you host, you do need to have another host ready to go.
Majority of workloads can be down for a few hours without customers worrying anyway.
We actually use it for hosting quite large workloads, but we do have a few bar e metal hosts we manually provision different services across. At a moment's notice we can quickly push the app to a different server and would be down for a few tens of minutes at most, minutes normally.
I just don't get the expense of Heroku just because your (in reality) non-essential workload can't be down for a few seconds.
There are both Kubernetes[1] and Nomad[2] plugins. I'm also building schedulers for AWS Lambda, Compose (which I guess also sorta provides Azure ACI and AWS ECS support), and Swarm.
You can also scale individual process types (so anything in your Procfile) via our `ps` plugin[3]. All plugins should support this, so you don't need to learn a new set of commands for alternative schedulers.
Can’t you just put a load balancer in front of N vps running dokku? Although, I haven’t done infrastructure since before docker was invented so a little behind the times.
When it says free heroku alternative that runs on a single host/vps, then I assume the file system stays durable (as opposed to ephemeral). Is that correct?
Have been using Dokku in (small scale) production for years and absolutely love it. Was also recently pleasantly surprised to see that Dokku supports ARM... so looking forward to trying it out on my RPi4 next week.
I have used it quite a bit. What I hate about it is that it runs on my single machine and the underlying system updates feel a bit dangerous to do. Also at one point it would endlessly crash after adding another worker to a project and there is no way to debug it easily. I moved almost all the projects to DO Kubernetes now. I had written my own dockerfiles anyways since it means faster deploys. The fact that deployment goes through CI is more of a bonus. The Setup is more involved though
Docker updates are usually the stressful ones, not Dokku (I try to call out all deprecations/changes in our Migration guides[1]). You can turn on Docker live-restore[1] to make Docker upgrades safer.
I'd imagine the reason you have crashes is due to not having enough system resources (usually memory) to run your workloads. There isn't too much Dokku can do about that, though I would have loved to see a ticket or something on our chat venues to help debug.
Dokku also supports kubernetes[3] if you still want the Dokku experience, and you can deploy images built in CI[4].
Glad to hear you have a setup that works for you though :)
I think with moderns and dedicated VPsS this can work for a very long way.
Hetzner offers 48 dedicated vcores/192 GB RAM in a single machine for less than 500€/month. I can totally see many business working for years within these boundaries. Also, not every company need Google-grade high availability.
I’ll never understand why one stacks config syntax and semantics is seen as complicated while another stack of gigs and gigs of state is not.
A Linux host that pulls down a web server via its package manager is gigs of special state too. Where’s the simplicity? It’s no less complicated, maybe more familiar.
There’s way too much romantic and poetic day dreaming about what it is we do in IT.
You're right. But it is a little harder to get kubernetes up and running with a load balancer and your own domain.
Obviously not for people who are already familiar with it..
You can certainly roll your own setup and get the minimal functionality _you_ need. Thats the general "build vs buy" question.
Dokku itself comes with a ton of functionality and is actively developed separate from your app. It's been built for thoughtful extensibility (one person in this story mentioned adding TCP/UDP support in a day, as an example) so if it doesn't do what you want, you can add it. We also provide a "curated" experience that handles things based on years of working on other deployment tools (and not just simply cloning the Heroku CLI and experience, though it has had a very deep influence). If our workflow and experience are what you want, its there today.
With something you build/maintain, the system is often simpler. Maybe one or two tools with a couple hundred lines of code, all fairly grokable. If you need to extend it, you know exactly where and can do so. In fact, thats how a lot of Dokku alternatives come out - someone didn't like our codebase or setup and decided to write something else[1]. Building your own deployment stack is often how most companies start - roll your own against tooling that is close-by or familiar.
The unfortunate thing is you now own that experience, so if you need functionality, you need to build it, which can be distracting from your actual business goals (unless you're a deployment tooling company, in which case this totally makes sense!). Would you rather spend 10 hours working on a feature for your customers or hacking together a version of review apps? If this is for your own home cluster, maybe that makes sense, but even then, I'd assume most people _should_ just want to deploy their app and move on vs work on that tooling.
All that said, if Minikube + Ingress and a few yaml templates work for you, go to town. Feel free to try us out if you want a more curated experience :)
- [1] Piku is an example where they wanted ARM support and we didn't have it yet, while the Caprover developer wanted something that works with Swarm.
I’ve been dokku for a long time. I think before there were any plugins. Works just fine for me, but I’m not doing anything out of the ordinary. I run all my hobby and side projects with it on linode.
About 5-6 years ago I found out that "Dokku" means something like "crappy" in Telugu (I think). Lots of people seem to refer to it when talking about politics, theaters, and methods of transportation on twitter.
It's also the name of some famous Korean actor's Dog (I think they got the name from a Naruto character named Dokku). The dog is fairly new, and lots of folks stanning particular actors or actresses on twitter use the word `dokku` in their username.
Dokku Umarov was also a Chechen mujahid in both Chechen wars. References to him pop up every so often (he died in 2013, _just_ after the Dokku project started).
IIRC the name "Dokku" is a portmanteau of `Docker` and `Heroku`. How you pronounce it is up to you, though it seems I pronounce it very differently from others (I use "dough" instead of "dah").
Finally, "Dooku" is not how it's spelled, though lots of people seem to refer to Count Dokku of Star Wars fame :D
Yeah you can use preview/review apps via the `apps:clone` command[1]. It can be used in a pipeline to setup custom apps for code branches, allowing folks to stand up custom versions in CI for merge/pull requests[2]. If your deployment platform doesn't support this in some way, I would definitely recommend investigating it, as there is a _ton_ of stuff you can do with this.
Not familiar with Qovery, but yes you can create preview envs. They’re called “review apps” for Dokku and it’s super neat. It ties in really nicely with GitHub actions so you can spawn and tear down preview environments with each pull request: https://github.com/dokku/github-action/blob/master/example-w....
[0] https://caprover.com/