I really like Dokku. I recently wrote a plugin to automatically expose the apps I add on it on my local network as subdomains of the host via MDNS (https://github.com/calyhre/dokku-mdns), perfect for hobbyists
Or you can use something with straight-forward pricing, like Digital Ocean. I don't understand why AWS is default for everything. People need to snap out of that racket.
Digital Ocean is even on the expensive side these days. There are a lot of vps providers that offer decent pricing and include bundled bandwidth. Some of the hosts may not be good for business-use, but should be fine for personal stuff.
IMHO Dokku still outperforms all other open-source alternatives for deploying Rails apps. There are a few proprietary alternatives that still manage the job with far more simplicity, but those are paid... I have tried to deploy with Kamal, DHHs Junta preferred way, but is still not better than Dokku in it's management and simplicity, and top of that, if follows the framework's latest trend of poor-to-no documentation.
The documentation is a major turn-off. I havent revisited the situation in a few months, maybe things have changed, but could not deploy a single app to my traditional cloud vm's... I never struggled that much with Dokku, that's why the comparison...
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 have actions on my projects to build & publish container images to GitHub's container registry. The deploy trigger from the workflow makes Dokploy get the latest image from the registry and run it.
Thanks for the recommendation. I've just given it a try and it looks great. I had tried coolify.io before, but the multi node/swarm support wasn't great, and the registry didn't work. Dokploy seemed to work straight out of the box.
One thing I wish it had to preview deployments though. Coolify had that. But I can live without it.
Apologies for the very off-topic reply, but I can't help but find it a little funny that on a thread exalting a particular tool, the top comment at the time of this writing is a link to another, newer tool. Not that there's anything wrong with sharing the link, but it does seem like here at HN we have a bit of a grass-is-greener thing going on. I would understand it more if the discussion was around how bad a tool is and someone chimed in with an alternative. And it's not like I don't want people to share these other projects but personally on a thread about a particular topic, the comments I find the most useful are those from people with experience in that topic sharing their opinions, tips, etc. In this case, the comment our community found the most valuable on the topic of Dokku seems to be a link to Dokploy, a project that judging by the commit history is new as of this past April.
I find it helpful to have other tools listed. I already know a decent amount about Dokku and clicked on these comments specifically to find out what other tools might be up and coming or otherwise mentioned in the space.
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 think I was respectful enough to word the original comment I made to the difference between Dokploy & Dokku, not just saying one is better than the other. I've used both successfully and think both are great products - just wanted to share my experience. There seems to be an umbrella recently of self-hosting tools like Coolify/Dokku/Dokploy etc. so wanted to contribute to the discussion in that way. Dokploy is also an open-source project so thought the exposure might be positive on a high ranking HN post.
My comment came out crankier than I intended. I do think comments like yours are valuable, and I agree that you were respectful and informative. I'm just genuinely amused that the top comment is for a completely different tool. That's more an observation about how we vote as a community, not about your post. I include myself in that group though as I have in the past been drawn to the new and shiny over the already known.
I personally appreciate it - I really like going to the comments to see other approaches and alternatives whenever something is on here. I don't think it's an insult nor do I think it's out of place if done correctly. HN is one of the only places left on the internet where I expect good value in the comments section and this is one of the reasons.
Same here. Actually I regularly revisit threads about Dokku, Coolify and CapRover because I know that there are references to other projects that I might have missed.
> it does seem like here at HN we have a bit of a grass-is-greener thing
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.
My theory for this, at least in this case when the featured article is about a software program, aka a tool, then it really becomes a discussion about the tools that serve the purpose of that in TFA.
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
For a while dokku was selling a pro version with a web ui and json api. I don't really mind the CLI so while we bought it I don't really use it. I see there hasn't been much activity on pro, I wonder if it is still a focus.
After seeing a recent HN post about Dokku, I started going into the nitty gritty of deploying it before finding out there is no multi-node support at all. So if you ever get to the point where you want to scale beyond one server, dokku can't do it which seems like most of the point of using a Heroku-ish tool (I've tried k3s in the past but Kubernetes always seemed like overkill for a non-enterprise setup).
I'll check out dokploy now that I see it has multi-node support.
That's also one of my wishes to get improved, currently I just have a long text file where I store them so that if I move servers I can just re-run them if needed.
Could you put them in a .sh file and then just run `sh setup_dewey.sh`? Maybe put `&&` between them so that if one fails, it won't keep running through the script?
Yep, in theory I think that should work nicely. So the recovery procedure after a server died would be to restore the dokku data directory from backup and then re-run all the commands. I haven't tested that but I think that should do the job.
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.
Exactely, I was really surprised that dokku isn't all based on storing these commands in a config/script which gets executed every time you change something.
We have ansible modules (https://github.com/dokku/ansible-dokku) that cover the majority of app management if thats what you want. The reason I am hesitant to do it in something like `app.json` is purely because one might expose Dokku to users who only have push access and some of those commands can be fairly destructive.
I’d love this feature too. Why not add it as an optional thing to enable and let users decide? Maybe just put a big warning in the docs and make it opt-in?
I really hate adding knobs - it increases the amount of work I need to do to maintain and support the project.
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.
I've been using a different tool that provides great developer UX for managing containerized web apps on your own servers. Its dead simple and does things like zero-downtime deploys and remote builds.
I've looked into this too, but it always felt like it's best suited for a "one app per server" model, and not really like Dokku which makes it easy to run many workloads on a single server.
I've never tried the many-apps-per-server use case and I don't think it's supported. We use it in production where its more common to have many-servers-per-app.
I’ve got two apps running on two servers (ie both on both) using Kamal and Traefik and it works great. I didn’t set it up but I deploy with it almost every day.
I already run multiple apps on a single server with Kamal and it works fairly good. Sometimes there are some issues especially if you use similar resources across system such as redis. But overall it is stable and works good.
No. With Dokku you can just push to git remote and it'll build, deploy the image, set up LE certificates, roll out the app with zero downtime (if you want). To get this running you'd have to do some manual stuff with git commit hooks, but that's just one small part of Dokku.
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)
I see compose in production all the time - especially from folks that want compose support _in_ Dokku. I bought this up with the compose project manager a few months back. It seems like an interesting use case but it didn't seem like the Docker folks were... aware that this was how folks used docker compose? There is a project out there - Wowu/docker-rollout - that sort of provides this but it has some rough edges.
My understanding is that they are focused on the local development loop at the moment, especially with the acquisition of Tilt. That said, I don't work there so take this all with a grain of salt.
You can still solve for that just fine in a multi-Dokku setup. It's just that Dokku won't do the coordination for you. Sometimes you do want something more integrated like k8s/openshift/nomad instead; sometimes not.
Dokku's multi-server offering is based on k3s. We interact with k3s but offload any actual clustering to k3s itself as it does the job better than Dokku could :) You can also just tie Dokku into an existing K8s cluster on your favorite cloud provider instead.
It‘s a tradeoff: a real PaaS is more managed, fault tolerant, and scalable, Dokku is much less expensive, especially with multiple projects.
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.
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
We've supported multiple servers for a few years and have had official k3s support since the beginning of the year, so not just one server anymore. We even support managing the servers associated in a k3s-based cluster.
Ohhh, I stand corrected. I don't think that was an option the last time I looked at Dokku. I see the schedulers section in the docs now, thanks for pointing it out!
Does the k3s scheduler work with existing non-k3s k8s clusters as well?
Can we not do this? Everyone knows that “serverless” doesn’t actually mean there are no servers. It’s not productive to do this “haha gotcha!” trope every time someone uses the serverless term.
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.
"Serverless" means 1- pay for what you use. 2- No infra setup, ever. Dokku requires a server that you have to manage. It is not serverless. You should never hit a scaling wall.
Azure Functions are serverless to us, but for the team developing and deploying that feature they are not serverless.
Dokku provides a tool so that once you deploy projects they can be ‘serverless’.
1- That would throw out serverless with (free) unlimited use (A la PocketHost)
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
> Can we not do this? Everyone knows that “serverless” doesn’t actually mean there are no servers.
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.
Are you the sort of person that says "ackshewelly people in orbit aren't weightless" or complains that wireless headphones technically contain wires, or that motionless rocks are actually moving really fast because the Earth is moving through space...
The actual meaning of words is defined by how people use them. Serverless has a very specific, well-defined meaning despite its seemingly contradictory etymology.
Most of the time I see "serverless" used these days, it's referring to the fact that server specifics are abstracted away from the application itself's deployment artifacts. Instead it just runs on a platform of some kind without worrying about having to be built for this version of this OS, etc.
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.
>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.
It is, but "We provide a programmatic interface for deployment that allows deploying docker containers on a VPS or server that you control" doesn't have a good buzzword.
I always understood "serverless" as, your main application isn't running all the time, but once you make a request to it, another process starts your main application and then your request gets forwarded to the "main" application.
But I never really got it, so I may be completely wrong.
Practically, it's always running, as otherwise you'll get a cold start delay, but that's close enough. It doesn't mean there's no server, so the "lol how is it serverless if you have a server" meme is tiring.
Kinda, but you are describing an implementation detail. More broadly, here's how it works:
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
But the article starts with "I run a Dokku server on a $7/month VPS", so author meant something else (probably just wrong usage). Maybe Dokku has 2 modes, where you can launch it on classic server (fixed price per month) or deploy on pay-as-you-use platform (https://www.cloudflare.com/learning/serverless/what-is-serve...). Calling something serverless without trying it first is deceiving.
I was looking at many of these "selfhosted Heroku" type of solutions recently and read many HN discussions about the different options (coolify.io, ploi, ...) as I migrated to a new server and always copying, adapting nginx configs got a bit old.
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!
How long did it take you to go from "making a new server / copying configs is fine" to "this is tedious enough I'd like to abstract it?"
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.
That's where I am too right now for personal projects, and I ended up reimplementing parts of Dokuploy for that, but I don't feel much of a need to move from "fun little docker compose" for some reason
For homelab (but not only) you can install Proxmox Virtual Environment on your physical machine. You end up with a way to create VMs and containers with a web UI. It supports cloud-init too. If you have a spare machine it's excellent for experimenting and learning.
I wanted to self-host more of my Rails projects and Dokku comes with nice Buildpack support so I can just push a generic Rails app and it'll run out of the box. That plus that I had to set up a new server after many years made me look into that more.
cloud-init is good, but it assumes that you treat your VMs like containers and that means you will need a lot more VMs that you constantly create and destroy and you will have to deal with block storage for persistence.
If all you do is ssh into a system with docker compose installed, you will hardly benefit from cloud-init beyond the first boot.
That's pretty much the opposite of what I'm searching for. Getting a static site running with https on Dokku on a fresh server is done in under 2 minutes if you type quickly.
That reads like "draw a circle; draw the rest of the owl".
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 really neat! I've been using it before moving to building my own Docker images and deploying with Swarm. It was also (partly) the motivation behind my own take on self-hosted PaaS, Lunni (shameless plug): https://lunni.dev/
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.
Do you mind if I ask why you chose Docker Swarm? I don't know that much about Swarm and I'd love to know what you think about it compared to K8s (in terms of ease, nice things, things missing, etc.)
The main reason probably was the fact that I was already familiar with Docker and Docker Compose. Kubernetes introduces a whole lot of concepts that I didn't feel like studying up, plus there was a 3-node minimum requirement. I just wanted to be able to start with a single node and be able to scale up if needed, so Swarm just felt like a natural match here.
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).
Not too bad, except I have no idea how many users we have :')
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.
There isn't actually ( nor was there ever ) a 3 node requirement for k8s.
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.
I might be misremembering it, huh! Yeah, it's pretty much the same as Swarm then (any odd number of manager nodes is valid, and if more than a half go down you only lose the management ability and everything else stays up).
I'll look into it, thank you so much! Way back then there wasn't a lot of choice though. I think I've played with Minikube but that was not recommended for production, and all the other distributions were huge (or at least I thought so!).
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.
> 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.
> Have you found hosting you like with bandwidth expense caps?
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 :)
Yeah, I think plenty of VPS providers do unmetered traffic too. Mine has a limit but it's something like 8 TB/mo, so I'm not particularly worried either.
Note that if you saturate that 1Gbps link they will almost certainly ask you to stop. Lots of VPS offer "unlimited" but it's really not. It's only unlimited within their "fair use" restrictions, ie only as long as they think it's reasonable.
That's cloud, non-standard NICs, load balancers or vSwitches. Their standard 1 Gbps link does not charge usage fees. The one person that reported it did it on several servers, over 3+ months - and they weren't charged, just asked to slow down or upgrade to a dedicated link.
This happened once (?) in the history of LowEndTalk and Hetzner, and that was someone who was using several servers, 27/7, over several months at 100% link utilization to shovel raw footage around.
You are very unlikely to replicate this running any type of personal infrastructure. Or anything that's not specifically this.
I do have some concerns about Docker Inc. and Mirantis (which now owns Docker Swarm I believe), yeah. Swarm is pretty mature though, and while I don't think it's going anywhere soon, I don't think we'll get any more core features anytime soon.
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!
My gripe with nomad was that it didn't have init containers. You were basically forced to either have an endlessly growing job specification file or put consul-template in every single container image.
Delighted to see dokku on here. It's an amazing product and the founder is super humble and helpful.
I can't afford to throw much money at it now but it would be great if more people supported it financially
My experience with dokku was pretty poor. It was quick to start with but on my VPS crashing and restarting, my apps would not relaunch. I'd have to re-run the dokku commands again. Perhaps I did something wrong but I inevitably switched to a single-node k8s setup as it ended up being more reliable
This comment to me is another upvote to use dokku. Been a happy user for years myself. If you do need help, the discord is pretty responsive and always helpful.
One more upvote for Dokku. Been using it for as long as I can remember hosting things on servers. It is such an incredible piece of software. And open source to boot. If any of my projects ever make money, Dokku will be the first project I'm funding.
Sometimes the slighly more complicated (Dokku is still a very thing bash wrapper around running git, ssh and docker commands) is simpler just because they have a great documentation and other people using it.
Dokku is great, but historically it didn't really handle resilience. It looks like there's now a K3s scheduler (added earlier this year) which would mean I could have use a Kubernetes operator for a replicated database as well as have the app running on multiple boxes (in case one fails). It looks like it'll even setup K3s for you. The docs don't seem to go into it, but hopefully the ingress can also be setup on multiple boxes (I wonder if it uses a NodePort or the host network).
> Dokku is great, but historically it didn't really handle resilience.
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?
I'm not the person you're responding to, but I believe I can answer that question as well.
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.
Yea, this. Dokku was basically a single-server thing. If that box dies, your site goes down until you launch it on a new box. That might not be a huge deal for smaller sites. If my blog is down for a day, it's not a big deal.
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.
Yeah the k3s scheduler is basically "we integrate with k3s or BYO kubernetes and then deploy to that". It was sponsored by a user that was migrating away from Heroku actually. If you've used k3s/k8s, you basically get the same workflow as Dokku has always provided but now with added resilience.
Any suggestion for a simple FaaS platform that isn't OpenFaaS? Fn Project looked promising, but their repo looks abandoned (more than one year without commits).
Salesforce's "no software" slogan dates back to a time when software was sold in boxes on store shelves. They were one of the first (possibly the first) cloud-based business app. The slogan only looks weird in hindsight because the term "software" now includes SaaS apps.
I dropped armhf (32 bit arm) a few releases ago. It was painful to maintain and the few users of that were older Raspberry PI installs. I think there are other tools out there that better support low-powered platforms (piku comes to mind).
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.
It’s the backend that implements serverless architecture. A serverless server, I guess. Roll your eyes if you like, but “serverless” is still a snappier term than “declarative on-demand server provisioning, configuration, and scaling” and most people are into that whole brevity thing.
Except Dokku doesn't do those things. Dokku doesn't scale your app automatically and it doesn't shut it off when it's not being used. It runs your web server process continuously, handles some 12 factor config, and does some nginx stuff for you. Until this year it didn't support managing a cluster at all and was entirely focused on single box deploys. The scale command just runs more processes on the same machine which if you're not using Node is probably not even a good idea to do.
Here's a better question. For people that roll their eyes at the mere mention of "serverless" (like me), what is the value proposition of Dokku over VMs and your own dockers?
Don't convince me it is like AWS serverless. Convince me to give up VMs and docker images.
One benefit for me was that a vps with 2vcors and 2-4gig of ram is about the same price as one of these app engine services. So I can run 3 or 4 dokku apps including Postgres, redis, memcache connected to them on my own vps and still have margin when inspiration strikes. I moved a production app from heroku to dokku and saved hundreds a month and still got tons and tons more compute.
Well its problem is that you still have to... install the entire thing. Whatever serverless means, it should allow programmers to focus on their code, not on the platform. Like, at all.
278 comments
[ 2.9 ms ] story [ 266 ms ] threadGood solve!
Disclaimer: I am the Dokku maintainer.
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 really don't long for a gem breaking when i go to update my system. self contained binaries ftw.
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
One thing I wish it had to preview deployments though. Coolify had that. But I can live without it.
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
https://github.com/Dokploy/dokploy/releases/tag/v0.7.2
I'll check out dokploy now that I see it has multi-node support.
Otherwise: totally agree, great tool for self hosting.
https://dokku.com/docs/deployment/deployment-tasks/
For example for a static site that would be the following:
That's also one of my wishes to get improved, currently I just have a long text file where I store them so that if I move servers I can just re-run them if needed.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.
Or just add `set -o errexit` at the top of the script. Or use make.
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.
https://kamal-deploy.org/
I use it with rails but it works with any containerized web apps.
Did I misunderstand something there?
Zero-downtime does sound interesting though, and is probably better than `traefik.http.middlewares.test-retry.retry`.
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.
Lol
What about things like scaling, or even just what if your one server runs out of resources to fit more apps on?
Disclaimer: I am the Dokku maintainer.
Premature optimization for 99% of people's projects. Once you run into "scaling" issues you can always run it on a more powerful server.
Related: https://twitter.com/dhh/status/1827322640685506895
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.
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?
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.
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.
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
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...
https://proxmox-helper-scripts.vercel.app/
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.
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.
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).
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.
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.
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/
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.
You are very unlikely to replicate this running any type of personal infrastructure. Or anything that's not specifically this.
aws will just charge you regardless.
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.
https://github.com/daitangio/misterio
I created it for managing my homelab, it works great and it is a thin layer over docker compose
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.
But it worked for Salesforce, which is a software company whose slogan is "no software".
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.
Quoth the raven, “servermore”…
Don't convince me it is like AWS serverless. Convince me to give up VMs and docker images.
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.
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