Open-source alternative to Heroku, Vercel, and Netlify | Hacker News Reader

Open-source alternative to Heroku, Vercel, and Netlify

github.com

133 pointssiumauricio100 comments

Open articleView on HN

This is not open source, just take a look at the license.

https://github.com/Dokploy/dokploy/blob/main/LICENSE.MD

ssddanbrown opened a discussion on the repo laying out the reasons why this is not an open source project.

https://github.com/Dokploy/dokploy/discussions/3

It's worse than that. The license opens with the standard clause:

"Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License."

But then proceeds to modify the license terms. This makes it definitionally -not- Apache 2 and no amount of word-smithing can get you out of that (appendix?).

There's a certain dishonesty in saying, "hey we're open source Apache" and then demanding a source available "something else". It's not even smart dishonesty... You offer the Apache original terms, but then you have to make it sufficiently clear those aren't really the terms enough that any fool can see this isn't the Apache terms after all.

Oof. OP, if you wanted to use terms like this you should have just picked BUSL. These "appendixes" were pretty clearly not written by a lawyer, they're redundant with each other (Appendix A includes the same content as Appendix B, just phrased less formally), and adding appendixes to Apache looks at best naive and at worst devious.

>>you may not use this file except in compliance with the License.

That means just the file "LICENSE.MD" is under that Non-Apache License. The rest of the project is something else.

Would be great to see a comparison to some better known alternatives like

- Dokku [0]

- CapRover [1]

[0] https://dokku.com/

[1] https://caprover.com/

It seems similar to https://swarmlet.dev as well (I’m the author). I’ve since abandoned the project for different reasons. Currently I’m using Dokku, and have been using it for ~8 years. It’s a lovely project and pretty mature. I would recommend Dokku to anyone who wants to do (cheap) self-hosting!

Same here: I've been hosting two dozen services on Dokku for a side-project in the past few years and it's been working flawlessly! Dokku and a Hetzner server makes hosting very easy

Same. Dokku has worked seamlessly for me for 6+ years now!

I should add one to https://piku.github.io (spoiler - this doesn't use Docker at all)

Dokku Maintainer here:

Piku is awesome! I've always thought the PaaS space is wide enough for many players in specific niches, and I love the approach of running processes outside of containers. About the only thing I would change is to utilize systemd (or similar) for spawning processes, but otherwise it's super neat. I've used it myself on a raspberry pi zero :)

Thanks! systemd would require more coding, because uwsgi does a lot automatically just by watching file creation/modification…

+ https://coolify.io/

I've been using coolify for all my apps for like 6 months or so now. I gotta say it's pretty impressive how well it works and the dev is quite responsive. I hope he can make it financially viable for himself.

It's still a little rough around the edges but quickly getting polished up.

I'm a bit down the kubernetes rabbit hole right now so I'm biased. Wouldn't it be better to have these solutions as kubernetes packages so that you could have the best of both worlds - flexibility and plug-and-play-ness?

Honestly I'm probably ending up reinventing the wheel a lot while going with kubernetes (on my personal projects) piecing together a lot of what these tools would give me with minimal configuration. And it feels like a lot of what I'm currently trying to work on in my side project is basically what I would get from these paas solutions but with the benefit of understanding and being able to tweak the various components better.

I had the same conclusion after evaluating those open source PaaS tools.

It just doesn't feel right for me. For small scale apps it's enough to spin up one or two VMs and run some containers with docker-compose (or just use Vercel/etc for a few bucks). But if it should scale, there is no alternative to kubernetes in the open source world.

My hypothesis right now is that if you know Kubernetes there's no "good" reason to not choose Kubernetes even if it's "overkill". You get a lot of flexibility this way but it's potentially a huge upfront cost with many options for shooting yourself in the foot. Understanding how to configure it without getting overwhelmed currently takes a lot of experience.

You can run Kubernetes for cheap on a single node and it seems you can configure it so that you only need to care about the configuration when you need flexibility. I think.

I get a similar feeling to how it was to set up a react project before you had create-react-app like tools. There's a lack of plug and play options that works for most use cases.

Then again I might just be sort of rationalising the amount of time I've spent on it on a personal project that doesn't really require it.

Dokku supports k8s as the "scheduler" (the term is weird...).

You can think of it as a much nicer CLI for k8s in that case. But it scales way down to a single machine deployment that is much simpler.

Dokku author here:

The "scheduler" term here _is_ a bit weird, but I couldn't figure a better term when I was abstracting the concept.

And yeah, the idea here is that the underlying scheduling system shouldn't matter too much to the user of Dokku, but rather that you get the same experience regardless of the scheduling system. That means that as a user, `dokku enter` (for entering a running container) should be the same if its on Docker Local, Kubernetes, or Nomad. Similarly, Dokku should abstract what it means to deploy a workload onto a system - for Kubernetes, we use Helm charts, but the user doesn't need to know about how helm charts work or anything like that.

We've traditionally focused on getting that single-server experience to a high quality, but now that the base is more or less complete, we can start looking at other integrations that help our users scale.

unfortunately, many (like me) don't have time for going down k8s rabbit holes, we just want to get back building features.

push heroku, done, get back to other things.

It would be nice if there were a packaging system (or maybe just a github action?) that got you a k8s with ingress to some pods that were just updated on merge to a main branch.

Yeah, I looked a bit now. It seems there are some serious attempts at this.

Like:

- https://www.cloudfoundry.org/technology/korifi/

- https://kubevela.io/

- https://www.crossplane.io/

Not sure if all of them are relevant and on first glance they all seem significantly harder to pick up than something like Heroku.

Found them through this reddit thread: https://www.reddit.com/r/kubernetes/comments/m8r5py/looking_...

Yes, I'm going down the rabbit hole so that I hopefully don't have to muck around so much down there in the future. I would love to find a k8s configuration that allows me to then focus on the application code. Push code to git and trust that my configuration takes care of the rest.

There's Porter, the "Kubernetes powered PaaS that runs in your own cloud".

https://github.com/porter-dev/porter

and Otomi, "self-hosted DevOps PaaS for Kubernetes"

https://github.com/redkubes/otomi-core

I'v tried these two and must say "it works out of the box" is only true maybe 50% of the time you try to deploy on them

Dokku Maintainer here.

I think myself - and folks maintaining other open source projects! - would love to hear feedback about what works/what doesn't. Feel free to reach via email (its in my profile) if you want, or our Discord/Slack.

I typically see users struggle with an initial deploy because their app depends on some variable or service running and that wasn't taken into account. This is pretty much the same as for general CI, where one might go through several commits before CI is running as you expect.

Very unfortunately, detecting these pain points requires work from both platform maintainers _as well as_ framework owners. The reason rails apps deployed so nicely across PaaS services in the past is because the Rails developers spent a ton of time ensuring applications _could_ do 12 Factor, while most PaaS services spent a ton of time working towards those constraints. Consequently, deploying other services that don't conform to this standard is a bit more difficult (though usually still possible).

I’ve been using Caprover for years, and haven’t experienced anything like your reported rate of failure.

I can vouch for Dokku being equally very reliable and surprise-free to use.

+ https://easypanel.io/

This seems nice but looks like it's closed source?

+ https://hatchbox.io

Dokku Maintainer here:

Hatchbox is pretty cool, but not OSS - also doesn't use Docker IIRC if thats something you were looking for.

There's certainly something to be said about managed services though. For folks that don't mind managing their infra, OSS systems allow customizations and extensions that you wouldn't see from a managed service, but you potentially trade that for reliability guarantees and general maintenance. With Dokku for instance, I see folks go quite a while without upgrading - potentially causing issues when they do, but mostly making it so they miss out on features and bug fixes. For managed services like Hatchbox, you get that for free, but then the system might change underneath at a cadence you're unhappy with.

Also which ones have native support for background workers and cron jobs.

The word "Open-Source" is misleading and should be removed from the title.

couple red flags: 1/ fake testimonials 2/ license that says "in case of conflict the terms of appendix will take precedence" followed by an appendix which says "yeah please don't change my code"

seems like open source for marketing's sake and not in any real terms

Also the name seems borrowed from Dokku, an actually open source product in much the same domain.

The name is not borrowed from Dokku, is taken from Docker, since when i was trying to buy the domain Dockploy.com was not available I just removed 1 char lol

Yes, but surely you can see the similarities in both name and use case.

By itself it seems innocuous but coupled with the blatant misuse of the term "Open-source", fake reviews and rather strange commit history, you can maybe understand why one might assume some malintent, or at least, somewhat shady intent.

Respect your opinion,

1. This will depend on each person who wants to interpret it that way. 2. About fake reviews, please review the others comment, I talked about this, this project initially was going to be a SaaS but at the last minute I decided to make it free, I already removed the testimonials. 3. Strange story commit, let me ask you a question, have you ever created some open source project? have you already checked the source code to say something is strange? check the others comment again this initially was going to be a SaaS i didn't have plans to release this for free, at the last minute i released and that's all, what's the purpose on see bad commits/code i have around 600 commits in another repository, I think it's a pleasure effect to see those commits or something because I see that people get excited, we DO NOT collect any tracking information or anything strange, you can review the code for yourself, I just want to have a clean repository that's all 4. About the license: This project was generally made for people who want to host their personal projects, mpvs or for agencies that want to do quick deployments on a simple vps server, maybe I'm wrong but 98% of people will use it personally and not a way to resell this same software without changing anything, so this probably won't affect you, as I say to almost no one, if you think you can take advantage of this project by selling it, let me know and I'll give you the permission you want, it's just asking, but People today criticize to get attention and it is valid. greetings!

you can check the docs commit at the last minute i added the open source term before https://github.com/Dokploy/docs/commit/456db4922538d8e4e8a12...

after https://github.com/Dokploy/docs/commit/e386b356550857a7282f9...

> About fake reviews, please review the others comment, I talked about this, this project initially was going to be a SaaS but at the last minute I decided to make it free, I already removed the testimonials.

You didn't talk about this though? I read all the comments and you just said that you changed from paid to free. That doesn't at all explain seemingly fake testimonials.

Are the testimonials real?

They’re all either freelancers or have very vague company names (Tech Innovations Inc, Dynamic Web Solutions) and the project looks brand new.

Vague company names and abbreviated surnames and random Memoji avatars for all of them.

If they are real testimonials then they've presented them in the most fake-looking way possible.

Hey! Thank you for your feedback, initially this product was going to be a SaaS, and I just forgot it to remove from the main website, but i change my mind and then make open to everyone, I just need to remove that, thanks!

If they were fake, "I had fake testimonials because I was going to charge customers for my product" is something you don't want to suggest.

Database hosting is often the costly and complex part of hosting. I have played with the idea before of setting up a Hetzner VPS with 2CPU/8GB RAM and harden the it and setting up backups and then use it for all my databases. I don't have performance/scalability concerns, but I would be concerned with reliability and potentially security.

I pay for a single RDS instance with daily backups and just shove all my dbs into that.

Same, but with DO managed Postgres. One place to do backups, monitor and easier to move apps between hosts if needed if they just talk to an external database instance not hosted on the same server.

Remember that post about the $104K Netlify bill? They said they'd introduce means to avoid this, but as of now, I can't find any such feature. I've finished a transition to CF Pages last week, but I still hoped Netlify would follow up on that promise.

have you tried https://github.com/taubyte/tau? it's easy to deploy and it's comparable to CF.

"We promise to limit our revenue"

Not really open source, plus it does not scale beyond one VM! tau (https://github.com/taubyte/tau) is a real alternative, to cloudflare & vercel and others, that is open source and actually scales -> https://taubyte.com/blog/be-competitive-in-few-minutes/

My go to for lightweight deployments is HuggingFace's Spaces, free 2-core CPU, anything else can go to either serverless container images on runpod or baseten.

Is it common for open source projects to start clean with a single commit containing all the code instead of keeping the history? If author/OP are around, what is the reason for this? I can imagine one trying to hide iterations of shitty code or even copies of third parties which is reasonable I guess ( and I personally wouldn't care as a user/contributor to the project)

Yes, I do the same. When I develop stuff, I tend to move quick and break things, which might involve swearing in git commit messages or just being plain stupid. I also have a habit of commiting sensitive information like host names, passwords or API-keys to private github repos, thinking not much about it.

If you take your scratch project to opensource, you typically don't have the time to make sure not only the current version, but also every intermediate result is free of flaws someone else might dig up.

So: mv private opensource; git init; git remote add ...; git push

An artist also wouldn't hang every draft drawing beside his gallery piece...

That is a terrible practice. The point of a commit history is to see the development progress, document why a change was done, and in the future be able to reference or revert a change. If you squash all of it before making it public you rob yourself and any future contributors of those abilities.

I also "move quickly and break things" when prototyping, but always go back and clean things up so that each change is atomic and well documented. In practice, this is not a perfect process, but being disciplined about this is worth it. Otherwise, you might as well not use version control at all.

This is also my argument against squashing PRs into a single commit (unless it's really a single isolated change). Sure, it's convenient to do so, and you end up with a "clean" history, but having granular changes is worth the time and effort, and it's something you should strive to do in general.

Open source maintainers don’t owe you the ability to see development process before the project was open sourced.

Squashing PRs is correct. Why would you need to see the hundred commits that lead to one working set of changes. The final changes are all that matter.

Making a project open source is an invitation for anyone to use, change and contribute to it. Purposefully hiding the history of how it was built makes the work of not only future contributors, but of the original maintainer, more difficult. If someone wants to remove a feature, they need to cherry-pick it manually. If an experiment was done early on during prototyping and was scrapped, this information is lost. If someone wants to know why a piece of code exists, this information is lost.

Keeping a clean history of incremental atomic changes is the entire purpose of using version control. It's not just common courtesy that I as an entitled user feel like I'm "owed".

The same applies for PRs, but I won't get into it any further.

I feel like there's a vocal segment of developers who don't understand the benefit of atomic commits, and by extension, version control, and are strongly opinionated in favor of the lazy approach. Working with someone like that can be a frustrating experience.

But please continue to downvote me because you disagree. :)

To be honest, opinions like these are why it’s so draining to be an open source maintainer.

Some open source projects are just that - open source. You get the source and nothing else. You are not owed anything and you are not invited to collaborate and contribute. And that’s fine. Fork it and do things your way.

The community would be much more pleasant and healthier if casual passersby were not demanding things be done a certain way without actually caring about or contributing.

This goes beyond open source, though. Someone doing this would act the same way when working in a team in a closed source project as well. I'm just saying that it's unacceptable in either case.

Open source is about fostering a spirit of sharing and collaboration. If developers don't align with those ideals, maybe open sourcing their work isn't for them.

"Open source" is abused too often these days as a marketing term, or something to fluff up your CV with, when it should be anything but that.

It sounds like maybe the open source ecosystem isn't for you, actually.

You don't get to dictate how others work, sorry.

I personally open sourced a project that started life as a paid product. The repository contained proprietary/customer information.

Are you suggesting I should have made this private information public? Or that I shouldn't have released the project at all?

As they said, open source maintainers don't owe you any of those nice conveniences you're missing with a clean commit history. If someone is embarrassed at their commit history or worried that they committed secrets at some point they're free to start clean and open source that. Don't put up artificial barriers to people releasing their code.

This fact (nothing is owed you) is entirely independent from the squash-or-not debate.

Hey! Initially the project is not going to be open, since i included some payment integration and credentials and more stuff, but at the end i removed, so that's why i pushed in to a new repo to prevent to leak this information

Nice project, but I'm interested in why the decision was made to flatten all commits for publishing? It makes it harder to understand the codebase, harder to contribute, and suggests a lack of commitment to the open-source model.

Is the plan to develop in the open from now on, or to drop releases developed in private in large flattened commits like this?

> suggests a lack of commitment to the open-source model.

I literally chuckled when I read your comment. It sounds reasonable to flatten commits before a release, as I, and others, who are hacking on code litter their history with "fix this" / "fix that" / "asjhdasjd" / "f**".

Open source model doesn't mean version control transparency. Open source model could also be development done in a private fork, and release commits dumped into a public repository.

I concur, my first commit was a big one, squashed to avoid showing my shitty history, after coding an MVP for 3 months. I initially had no intention to open-source, so I was caring at all about my commit history. I still had one or two questions like "is it even your code?".

Yeah, open source could mean code distributed in zip bundles. Git history is an orthogonal concern.

I said "open source model" rather than just open source. While open source is only about the licence, I think publishing on GitHub typically implies a further model of accepting contributions, developing in the open, and being a part of that ecosystem.

In my experience this is how open source projects tend to thrive in the last 15 years or so. Projects that are open source but don't accept contributions and just dump a zip on a website somewhere once a year are a very different thing and lose some of the benefits.

Hey! Initially the project was not going to be open, since i included some payment integration and credentials and more stuff, but at the end i removed, so that's why i pushed in to a new repo to prevent to leak this information and obviously i have alot of bad code/commits etc, so i preffer to start on a clean repo.

Can we get some screenshots of the dashboard? I tend to judge book by their covers

There's a link to their website[0] in the repo with a few screenshots and a video.

[0] https://dokploy.com/

Somewhat tangential, is there anything like this that can dump a bunch of nginx configs and not take over port 80 & 443? I’ve been thinking it doesn’t hurt to have a nice GUI admin interface, one fewer deployment script to write for every little project, one click rollback, etc., but I already got a pretty beefy server where most things are run from, so I don’t want something to manage nginx for me and push out every service I already have running for years. Admittedly I haven’t looked very hard in this space.

What makes you think these will only run on port 80 or 443. Almost all networked software allows you to configure the port.

Nginx Proxy Manager is a good one if you are looking for GUI of nginx

Thanks, but I’m more interested in the automated deployment aspect, nginx itself I’m too familiar with ;)

Have you checked the deployment tools mentioned in this thread? Such as dokku, piku and coolify

Yes, I think they take over 443.

to my knowledge if you stop the nginx proxy it doesn't take over 443 in dokku at least, no idea if it is persisted over reboots though

Thanks, it seems dokku does allow bringing in outside nginx vhosts, something I must have overlooked the last time I checked. I'll have to take a deeper look.

Dokku Maintainer here.

Dokku supports a variety of proxy implementations - nginx on the host, caddy/haproxy/openresty/traefik from within containers. The latter are managed via compose files, and can be customized to not listen on the host if you _really_ wanted to (and then proxied to from whatever your actual host system is).

While we optimize for the 90% case, I'd definitely be interested in learning more about your needs to see if we can maybe get closer to what you're looking for. On the nginx side, the port mappings are such that port 80 is used by default, but you could swap it to be something else (and also listen on localhost) and then proxy to nginx from your proxy of choice, allowing you to take advantage of Dokku while using whatever you currently use.

Feel free to hit us up via Discord/Slack.

As others have also said, the first thought when I saw 8 commits was "Oh, seems like a toy project". Only after surfing a bit around the code I saw it's more serious. Is your intention to also transform this into a platform like Vercel/Heroku?

What's the best way to simplify self-hosting static sites? Is there some sort of Netlify for self-hosting that also integrates with selected CDNs or similar?

I’ve been actually looking for some of these myself.

The two that I’ve used are cloudflare pages and bunny storage.

Cloudflare integrates with git and even runs builds for multiple static website frameworks (hugo, 11ty, etc)

Bunny storage is a bit clunkier when it comes to setting a ci/cd since it has nothing to support it. One can upload via ftp, web browser or API. And after uploading usually purging the cdn cache is needed to apply the changes.

I still prefer bunny because cloudflare give pages for “free”, which I don’t trust.

Cloudflare Pages has a free tier but also paid tiers.

Yeah, I've also experimented with BunnyCDN and KeyCDN. I'd like to stay with an EU provider if possible.

What more do you need than a web server?

Just set up a simple VPN with nginx and upload the page, done. Stop overthinking and overengineering everthing to smithereens.

True, was also considering this. Just thought having a CDN would be useful at some points (e.g. to compress/resize images, generate source sets of images automatically)

Setup a github action that compiles the static site and uploads it to a server with nginx/caddy/etc?

If you want it super self-hosted, then self-host gitlab and use their CI/CD instead of Github Actions.

Yes, that's one possibility I was also considering, thanks!

As the others said, you could simple use github pages, or if you want to have more features you can try different alternatives which relies on self hosting

dokploy coolify caprover

Using github or some other host that allows you to host static sites for free.

Looks pretty sweet, as long as there was a way to integrate it with nginx ingress controller somehow I'd say this is very interesting indeed.

I wouldn't consider this open source, the license [1] appears to put very non-open terms on the use, modification and distribution of the project.

[1] https://github.com/Dokploy/dokploy/blob/be56ba046cb3b2b8676d...

OSI would: https://opensource.org/license/apache-2-0

Edit: I'm wrong, see below.

It's Apache 2.0 + custom clauses excluding any commercial/for-profit usage.

My mistake, I should've paid more attention.

The Apache License is, however the additional terms the author has made to the license make it not open source; because the additional terms supersede the Apache License.

It looks like Apache Licensed but its the BSL (ElasticSearch, Redis, Mongodb license path) in disguise.

Author should have used AGPL if he wanted to make a product that isn't easily/eagerly SaaSified.

I've added extra explanation in a discussion I've opened on the project: https://github.com/Dokploy/dokploy/discussions/3

It probably was open source before the license was modified to prevent commercial use, which is not open source.

Reply on news.ycombinator.com