Dokku: My favorite personal serverless platform
hamel.dev
hamel.dev
https://github.com/Dokploy/dokploy
It's similar to Dokku but has a nice web UI, makes it easier to deploy Docker/Compose solutions and auto LetsEncrypt functionality is built-in by design (not as a separate plugin).
I've also built a GitHub Actions workflow to trigger off a deploy to apps hosted on it (basic cURL command but works well). https://github.com/benbristow/dokploy-deploy-action
And put together some pre-configured Compose files you can deploy for various apps. https://github.com/benbristow/dokploy-compose-templates
I'm still waiting for something built on a rootless container solution and with everything defined in git (i.e. no or limited cli commands) so that exactly what is being deployed is, at all times, tracked in git.
I'm pretty sure you can run both Dokku and Dokkplay using podman. It's a drop-in replacement for docker that runs just fine rootless.
> Apologies for the very off-topic reply ... it does seem like here at HN ...
There's nothing more HN than filling the first page of comments with discussion of everything except the linked article.
Since it's Hacker News, not Old-But-Stable-Project-News, that seems expected? The other way it also happens, and has been happening forever, I published a new OSS project of mine ~10 years ago, went to the front-page, and 8 of 10 comments were recommending other pre-existing tools.
Here's an analogy from the physical realm: "presenting shovel, a customizable tool for removing dirt".
- doesn't work well for rocky terrain, but I'm working on DigBar, which can outperform Shovel in many high performance workloads.
- it's a lot slower than Hoe, if you're only going down 4" of topsoil
- I wrote a custom frontend for Shovel call Flatend, it carries more volume for loose loads
- theres a paid product called posthole that is worth buying if you build fences, uses shovel under GPLv3
I'll check out dokploy now that I see it has multi-node support.
One thing I wish it had to preview deployments though. Coolify had that. But I can live without it.
I've landed on Dokku in the end as it's the one with the least amount of "magic" involved and even if I stopped using it I could just uninstall it and have everything still running. Can highly recommend it!
The developer is also super responsive and I even managed to build a custom plugin without knowing too much about it with some assistance. Documented this on my blog too: https://blog.notmyhostna.me/posts/deploying-docker-images-wi...
Like, was it a years-long journey or is this the type of thing that becomes immediately obvious once you start working w/ N servers or something?
I'm trying to learn the space between "physical machines in my apartment" and "cloud-native everything" and that's led me to the point where I'm happily using cloud-init to configure servers and running fun little docker compose systems on them.
https://www.proxmox.com/en/proxmox-virtual-environment/overv...
If all you do is ssh into a system with docker compose installed, you will hardly benefit from cloud-init beyond the first boot.
1) Run curl command to install Dokku
2) Set up domain to point to my server
3) Run 3 Dokku commands (https://news.ycombinator.com/item?id=41358578)
4) Add remote git url to my repository
5) Git push to that remote
6) Done
2) Create a playbook which pulls from your GIT, sets the DNS and installs Caddy (or apache+certbot or whatever) (~5min)
3) Run Ansible
You now don't need docker, can change to any other cheaper hoster any time you want and you don't have the limitations of "serverless" services
Look, I used Ansible for years. And chef. And puppet, so I've been around that particular block a bunch of times. There's no way you legitimately think that someone can, with no previous experience, create a playbook that does all you need in "~5min".
I ansible a good tool? Absolutely. Does it do what a tool like Dokku (or some of the others mentioned) do? Absolutely not. They aren't meant to compete, either.
Dokku is not one of those, it does what it does well and aside from a couple of cli argument ordering quirks it's been great for my light usage. If I was using it more I'd probably want to configure entire architectures with declarative config files, I have no idea if it can do that though.
If there are too many open PRs, or unresolved tickets, OR there are too many _new_ ones, I would rather start searching for something else
A few years ago it became popular to document the project processes, but it all turned into generic code of conduct garbage and abstract governance pillars, as if they were writing a constitution. So looking at GitHub issues and commit history is still the best way. And very well invested time.
I was so positively surprised that I got help so quickly after asking that I started to sponsor it via GitHub immediately.
In general, I really love the idea of running all your stuff on a server you own as opposed to e.g. Heroku or AWS. Simple predictable monthly bill really gives you peace of mind.
Have you found hosting you like with bandwidth expense caps? I'm looking for something like this but I don't want surprise network bills if I misconfigure something.
Not exactly what you're looking for, but solves the same problem in a different way:
I've been quite happy with using Hetzner's dedicated servers which come with 1 GBit unmetered connection (unlimited bandwidth), so no surprise network charges :)
Would love to be shown a counterexample provider.
aws will just charge you regardless.
You are very unlikely to replicate this running any type of personal infrastructure. Or anything that's not specifically this.
My concern around Swarm is around the Docker corporation, which appears to be struggling.
As a competitor, we have Nomad, but with the recent IBM acquisition, I'm concerned about Nomad's future.
For Lunni, my plan is to add support for another orchestrator while keeping the developer experience of just working with docker-compose.yml. I really didn't want to do K8s, but given it's essentially an open standard now, it should be a safer bet than Nomad. I guess we'll see when I can get to it!
Nomad was always much better than k8s, sad that it never got the same kind of traction or mindshare.
I'm a swarm user, but using single node swarms. It's the best solution I found for deploying apps. A lot of projects publish docker compose files, and those are easily usable with Swarm after some small modifications. I'm using the setup described at dockerswarm.rocks [1] and it's smooth sailing.
It's a real pitty, and still surprises me, Swarm is not more popular. It's still maintained [2] but few people still recommend it (even dockerswarm.rocks doesn't anymore). I've switched to it in 2022 [2] thinking I didn't take a lot of risk as starting with it is a really a low investment, and I'm still satisfied with it. I've deployed a new server with it recently.
1: https://dockerswarm.rocks/traefik/ 2: https://www.yvesdennels.com/posts/docker-swarm-in-2022/
I'm looking into K8s and other orchestrators like Nomad and perhaps will add support in Lunni at some point, but for now I believe Swarm is the sweet spot for smaller deployments (from single server up to maybe a couple hundred nodes).
Etcd requires 3 boxes for HA, but nothing stops you running a single node etcd.
I personally run single master clusters, because if the master goes down, you lose management as opposed to actual service availability, so mostly I don't care.
Now that there's anything wrong with your preference.
Swarm still works pretty smoothly for me, although I'm worried about the Mirantis situation, too. I'm currently working on a new backend, which will also enable us to plug in other orchestrators if need arises.
> Coolify can enable organizations of any size to host an arbitrary number of free, self-hosted software easier than ever.
https://github.com/coollabsio/coolify
> An open-source & self-hostable Heroku / Netlify / Vercel alternative.
Hopefully you do use TLS between Cloudflare and your Dokku (even with a self-signed cert or something), otherwise your personal sites (which are apparently sensitive enough to put behind basic auth) are being transited over the internet in plaintext.
Alternatively, you can use Cloudflare Tunnel, and then block all incoming connections.
(the term they use is “authenticated origin pull”)
1: https://maxschmitt.me/posts/tutorial-deploy-apps-websites-do...
https://www.cloudflare.com/bandwidth-alliance/
That should alleviate egress costs. Bonus that storage is also way cheaper.
That doesn't sound cheap...
I was sad when Flynn died (https://github.com/flynn/flynn), but it's great to see Dokku doing well.
Would you mind elaborating a bit on this? I'm exploring some serverless options right now and this would be useful info. Do you mean it's not really designed out of the box for resilience, or that it fails certain assumptions?
Dokku essentially just started a container. If your server goes down, so did this container because it's just a single process, basically.
Other PaaS providers usually combine it with some sort of clustering like k3s or docker-swarm, this provides them with fail over and scaling capabilities (which dokku historically lacked). Haven't tried this k3s integration either myself, so can't talk about how it is nowadays.
With a cluster, if a server goes down, it can reschedule your apps on one of the other servers in the cluster (assuming that there's RAM/CPU available on another server). If you have a cluster of 3 or 5 boxes, maybe you lose one and your capacity is slightly diminished, but your apps still run. If your database is replicated between servers, another box in the cluster can be promoted to the primary and another box can spin up a new replica instance.
Dokku without a cluster makes deploys easy, but it doesn't help you handle the failure of a box.
Note: I am the Dokku maintainer.
Otherwise: totally agree, great tool for self hosting.
Disclaimer: I am the Dokku maintainer.
Essentially something that captures all dokku invocations and could be transferred to another machine. Is app.json this?
Long term, I'd like to port the ansible modules over to being maintained internally by the dokku/omakase project, and then maybe that could be a plugin that folks could run from within their deploy.
For example for a static site that would be the following:
dokku apps:create dewey.at
dokku domains:set dewey.at dewey.at www.dewey.at
dokku letsencrypt:enable dewey.at
Or just add `set -o errexit` at the top of the script. Or use make.
Right now I keep the list of commands more as a reference to look up things like how I mounted a volume or my naming scheme for data directories.
I use it with rails but it works with any containerized web apps.
Did I misunderstand something there?
Edit: turns out (thankfully) that it's only the author of the article using that term. The project site (https://dokku.com/) is very descriptive.
> Dokku is an open-source Platform as a Service (PaaS) that runs on a single server of your choice
This is the first paragraph in the article
But I never really got it, so I may be completely wrong.
Infrastructure as a Service (IaaS) - you rent a VM with a publicly accessible IP address. Everything else – patching/updating the OS, deploying your application code or binaries, process lifecycle management, logs, TLS certs, load balancing multiple servers and more – is your responsibility. Example: EC2.
Platform as a Service (PaaS) - the provider also manages the OS for your VM, including deploying and running your code on it, restarts, a logging pipeline, providing a HTTPS URL, scaling to multiple servers and more. All you have to do is write your application code to start a web server and listen for web requests on a particular port. Example: Heroku.
Functions as a Service (FaaS) - this goes one step further, and the concepts of web servers, ports and HTTP requests/responses are also abstracted out from your application code (hence "serverless"). You write a function with a set of inputs and outputs, and it's up to the platform to execute this function whenever demanded. The request can be sent via HTTP or a message queue or something else entirely. Your code itself doesn't have to care. Example: AWS Lambda
Don't convince me it is like AWS serverless. Convince me to give up VMs and docker images.
Dokku looks great but what is the value of using it over "run your container" platforms like Google Cloud Run, Digital Ocean App Platform, or Fargate.
In term of your personal time, well, you'll not grow a business on it without hiring people to maintain it or spend a lot of time doing devops
I am in the same boat. Using VMs and docker images and not sure how this would benefit me.
I have looked AWS serverless stuff. They appears to solve problems I don't have.
Quoth the raven, “servermore”…
You write narrow business-level functions that take inputs, do their business, and give you the output. They're called, they run, they terminate and carry nothing forward. You deploy them to a hosting platform which will handle making them available, routing requests, and all the other stuff that's incidental to doing the work. The only thing that's your concern is the logic that turns inputs into outputs. At least that's the pitch.
Technically a PHP script that you run as CGI through Nginx is "serverless" that way, though of course it's hosted with a software server running on a hardware server. It's serverless because you write a PHP script and it doesn't care what runs it or what's going on around it. It doesn't need to work within the context of an application server like an endpoint in a Django or a Rails app would.
Someone else could own a bunch of servers running Nginx, you'd give them prettyprint.php, and it would pretty-print your JSON or whatever at the URL they'd give you.
Services that do this are called serverless platforms. The hosting model is called "functions as a service" (FaaS). If you like the architecture but you don't want FaaS from Amazon, Heroku, or some other third party, you can host yourself a mini FaaS with something like Dokku.
this appears to be a project to give you the niceities of a PAAS, without actually providing the platform.
https://docs.podman.io/en/latest/markdown/podman-systemd.uni...
edit: looking into traefik docs and perhaps not what I would call simple, probably would use caddy as reverse proxy instead.
When you're hosting a single-node cluster, what value do these docker-based tools offer? Is it the fact that you can use a dockerfile to declare your OS-level dependencies consistently?
I initially setup Dokku on K8s, but since it would just deploy to that same server it makes more sense IMO to just use K8s
But... wow. For my single non-k8s server at home, Dokku makes getting stuff running behind HTTPS about as simple as I could hope for!
This project looks great, and is obviously far less complex than Kubernetes. I was asking for advice about my particular situation. I wasn't saying that someone should choose Kubernetes over Dokku.
Though, I do see many advantages of Kubernetes for a homelab environment, mainly that you get experience using K8s which can transfer to a professional context.
The problem with Dokku is that, while its easy to use if you have experience in devops, well.. you still need to know devops! That's not what I call serverless...
With respect to AWS, where we currently host DBOS Cloud, we rent baremetal machines and built the entire hosting layer using Firecracker, Postgres, and other well known frameworks that we can bring to other metal providers (https://www.dbos.dev/blog/anatomy-of-dbos-cloud).
From the standpoint of a cloud user, the kind that likes Dokku, the experience is cheaper/faster/more secure if the infra uses uVMs vs containers.
https://github.com/skateco/skate
It's daemonless, multi-host with multi-host networking, service discovery and like I said, allows you to create deployments, cronjobs, and route traffic via ingress resources.
Comes with letsencrypt out of the box.
The GitHub readme is well documented but hard to know how that translates into the dev exp, like with scaling or upgrades and if its features are comparable to managed Postgres providers (I'd assume no but happy to be proven wrong!)
Nowadays I just run Postgres directly on my Debian box and just create a new user/DB for ever application, then set an env variable for the Dokku app to connect. Postgres is so solid to begin with that it requires no babysitting unless you have very intense workloads (at which point either use a hosted solution or start thinking about how you’ll do your own DBA).
I really don't long for a gem breaking when i go to update my system. self contained binaries ftw.
1. 10 minute to learn, simple syntax, rich functions
2. deploy with standard tools like ftp
3. easy scaling with php-fpm.
4. not exactly docker, but vhost works in most cases. And vhost can be containerized.
5. insta hot-reload
6. dirt cheap cost. Hi dreamhost
7. no vendor lock-in bullshit, supported by everyone everywhere
well, at least it was the case used to be
But yes, you're right that PHP is still a great choice for building the "web application" portion of your infrastructure.
SSL was provided by the php-fpm part, with either Apache or nginx, like most "platforms" do. Modern platforms may choose less-popular fronts like Caddy, and Caddy does support php_fastcgi.
Dokku in turn is a replacement for those platforms and makes it easy to host your own [insert some part of your platform stack here]. That is the purpose of a PaaS, which is what Dokku is and what PHP certainly is not. Yes, the OP maybe should've said "My favorite personal PaaS", but that is less catchy, and I think calling it a "serverless platform" is close enough to the truth and gets the point across.
> Dokku in turn is a replacement for those platforms and makes it easy to host your own
I tried to search
database site:dokku.com/docs/
or
queue site:dokku.com/docs/
But failed to find anything relevant. Am I doing this wrong? Where does Dokku as a "replacement platform" provide the database or queue capability?
> purpose of serverless is to provide scaleable infra which you don't need to manage
> Dokku is an extensible, open source Platform as a Service that runs on a single server (from https://dokku.com/docs/)
and how does Dokku on a single server solve the "scaling" problem exactly?
> As you noted, it doesn't even do the web-serving
Technically speaking, php can. https://github.com/swoole/swoole-docs/blob/master/modules/sw...
it's just not widely used.
Dont get me wrong, Dokku is a fine project of its own, but it doesn't seem to tackle the problems you mentioned either. On the other hand, if php is not enough, the LAMP can do everything.
Dokku is Docker + Buildpacks + Orchestration. You give it a buildpack (developed/popularized by Heroku) to specify your application, which is the main "serverless" part. Then you tell Dokku that you want datastores or queues or whatever, via plugins[1]. Dokku handles pulling the relevant docker images, running them, and linking it all together. In other words, Dokku is open-source Heroku, where you can add databases and such with a single command, specify your app with a buildpack, and you're off to the races.
If Dokku only did the application via buildpack part, people would not find it nearly as useful and PHP on a webhost somewhere would indeed be a good alternative.
But Dokku is not that, it is a PaaS, so it can also run your PHP application just as easily. And if you're self-hosting Postgres and RabbitMQ via Dokku, why would you run your PHP on Dreamhost? You probably wouldn't, you'd throw a PHP buildpack up there and call it a day.
[1] https://dokku.com/docs/community/plugins/?h=plugins#official...
And I really do hope scaling should be as easy as "pulling docker images"
> "I'd recommend reading more thoroughly about Dokku (or PaaS in general) since it is somewhat clear you don't understand the value prop."
My cynical and uncharitable translation of this and the rest of your post for the GP: We've invented platform or PAAS or devops so that we can carve-away work from devs that used to traditionally do this kind of stuff in partnership with infrastructure, and you're just not understanding it because you're coming from a dev perspective.
It's all just evangelism/marketing-push to gather the online webosphere mindshare and capture the development process so that all that's left for the downstream individuals (developers) is nothing but config/yaml/plugin-ecosystem and even that stuff only the ordained priests of DevOps understand (or are allowed to touch), again leaving developers with even less, making them glorified code-monkeys that need to spit out CRUD screens. It's either that, or put "DevOps" on your resume or title, almost like a mafia-style shake-down.
It works, sure, provides immense value sometimes and gets you to market quickly sometimes, sure, etc. But damn is it toxic and detrimental for our community in the long run. In an alternate universe or timeline we could have gone some other direction, but this is what we have for now, so we have to live with it. DevOps and UX will many years from now be known as two very bad paths that we allowed our industry to be dragged down into.
I am a dev, so your translation is indeed cynical and uncharitable (and inaccurate).
I also don't understand what you have against DevOps or UX. DevOps is just how you actually run the applications/services/etc (that you've written with code) in production. DevOps can be done by a developer or by people dedicated solely to that task. UX is just caring about how end users actually interact with the application/services/platform. This can also be done by developers, or by designers, or by UX specialists, or whomever.
These concepts exist regardless. Sure, you can choose not to care about how your application and its required dependencies are run. Sure, you can choose not to care about how your users interact with the things you are building. But not caring about those things doesn't mean they go away.
By that I mean that if the programming model has a way to automatically capture state, an implementation framework can manage it automatically on behalf of the application, while the user (person writing the app logic) doesn't have to care about the state.
> not exactly docker, but vhost works in most cases
You are understanding Docker and Vhost wrong then..
Have you tried write anything with those on serverless™ platforms? They don't do things properly, serverless makes coding harder, yield more errors and poor performance.
> better performance
PHP8 JIT offers outstanding performance.
> You are understanding Docker and Vhost wrong then..
chroot/jail'd multi-worker with inetd port fowardng solves the same problems as cgroup'd process and netns do. I'd argue it's a sidecar before it's cool.
If you take extra steps like wrapping LXC for your web workers, you may even call your platform, wait for it, Heroku. https://devcenter.heroku.com/articles/dyno-isolation
According to the first thing I googled, it’s more popular than Go, and even higher up the list if you remove languages like C/C++ that aren’t typically used for web.
https://www.hackerrank.com/blog/most-popular-languages-2023/
Disclaimer: I am the Dokku maintainer.
The main issue is that it's for playing a game, and the game is held in-memory, and once a day heroku restarts their servers, so everyone gets kicked out of the game they're in when it restarts with cleared process memory. I need to fix this by migrating and I don't have time.
If anyone feels like this migration would be something that they have relevant experience for and which they could do confidently, please get in touch. Email in profile.
Good solve!
- used a VPS - made a docker file
So what does doku actually do?
All I do on top of what you said is use Traefik for reverse proxy and let's encrypt.
https://github.com/daitangio/misterio
I created it for managing my homelab, it works great and it is a thin layer over docker compose
No one will be stealing your data as the big corps do.
Less chances to overrun your budget because of how cloud platforms conveniently have no breaks on utilisation of resources.
We take care of that ourselves by self-hosting and having faulty or unmonitored backups :)
I don't see any added benefits in therms of the extent of configuration I need to deploy. What is the new thing Dokku and other similar services bring to the table? What is the extra configuration I don't have to do if I go with it?
Is it the case that there is no visual in the free version? Just hacking around some files? That is not that user friendly and certainly does not really remind me of Heroku.
The GUI you get with the Pro version looks good. and only a bit more than $800 for life.
I pay a monthly support to dokku. You should too. Jose will help you either way, but I feel slightly less guilty when I ask questions and he immediately resolves them for me in the slack channel. Don't you want to use this incredible piece of software guilt free?
You may wish to look into a message processing system in your language of choice and run that as a daemon in Dokku. We have plugins for various datastores, and commonly I see folks just connect their worker processes to that. It's much lighter weight than spawning new containers for each workload.
(sorry)
This is the service I have been working for the lasts months alongside my 9-5. Heavily inspired by Coolify, but it is based solely on Docker Swarm to save the development efforts on other features.
Also, it is a bit opinionated to adjust the UX to what I need myself, so there are slight deviations from the way how others work with Swarm.
I have a short vid which I have recorded today on how one could easily deploy WordPress to any VPS: https://youtu.be/k34Zdwcsm6I
It covers usage of the 1-Click apps templates which speed up everything "a little bit".
https://dokku.com/docs/deployment/zero-downtime-deploys/
This has the added benefit of warming up the app before traffic ever hits it, something I was always surprised that even heroku didn't do (at least, the last time I used it ~6 years ago)
Disclaimer: I am the Dokku maintainer.
Zero-downtime does sound interesting though, and is probably better than `traefik.http.middlewares.test-retry.retry`.
ARM64 should be fine, with some caveats:
- Dockerfile/nixpacks support is great! Just make sure your base images and your Dockerfile supports ARM64 building - Herokuish _works_ but not really. Most Heroku v2a buildpacks target AMD64. This is slowly changing, but out of the box it probably won't build as you expect. - CNB Buildpacks largely don't support ARM64 yet. Heroku _just_ added ARM64 support in heroku-24 (our next release switches to this) but again, there is work on the buildpacks to get things running.
I run Dokku on ARM64 locally (a few raspberry pis running things under k3s) and develop Dokku on my M1 Macbook, so I think if there are any issues, I'd love to hear about them.
Disclaimer: I am the Dokku maintainer.
But it worked for Salesforce, which is a software company whose slogan is "no software".
While it is being used a bit recklessly here, taking it literally is about as insightful and constructive to discussion as pointing out that "cloud" servers are located on the ground.
I would even defend its usage here by pointing out that it's entirely possible to use this at a company in which the servers are managed by one person or team, and the developers building applications simply interact with the service and never touch a server themselves. Neither team has to touch each others scope, making it indistinguishable from conventional "serverless" approaches in which the decoupling occurs across company rather than across team within one company.
Maybe call it "server-agnostic" or "OS-agnostic" then.
https://readwrite.com/why-the-future-of-software-and-apps-is...
In it, he points out:
>The phrase “serverless” doesn’t mean servers are no longer involved. It simply means that developers no longer have to think that much about them.
I don't know how anyone could interpret "serverless" as meaning there's no server involved at any point in the application's execution, and if they did, I'm not sure what harm it causes? It seems like the only objection here is a pedantic urge to be more correct.
Serverless refers to the fact that you can launch individual workloads on the platform while abstracting away the underlying infrastructure. Yes, to set up dokku you still need to provision a server. But to deploy an application onto dokku after it’s been set up, you do that without worrying about provisioning new infra for your app. That’s what is “serverless” about it, and it’s a perfectly acceptable use of the term.
2- Then getting a third party to set up Dokku and then using that would qualify (Because it'd be the same as getting AWS to setup their server abstraction) The platform is serverless, you hosting it probably not, maybe server-light, as you setup the abstraction and use that for many apps
Then maybe people shouldn't use a term that means "there are no servers". One doesn't get to complain if they use a word to mean something the opposite of its actual meaning, and then people don't like it.
It's just annoying.
Lol
What about things like scaling, or even just what if your one server runs out of resources to fit more apps on?
One server scales vertically and can serve a good number of projects and users. Huge spikes eg. due to attacks, lead to outages instead of runaway bills.
Premature optimization for 99% of people's projects. Once you run into "scaling" issues you can always run it on a more powerful server.
To get started in a simpler way, and in a way that solves 80% of use cases. Once you need to scale, then you can scale. Why worry about that upfront with all the complexity it entails?
>what if your one server runs out of resources to fit more apps on
There's vertical scaling. Rent a bigger server.
Disclaimer: I am the Dokku maintainer.
Does the k3s scheduler work with existing non-k3s k8s clusters as well?
Disclaimer: I am the Dokku maintainer.