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.
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
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 :)
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.
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.
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.
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.
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).
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.
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
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.
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!
> 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.
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!
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.
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.
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.
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.
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?".
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.
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.
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 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.
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.
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)
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
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.
https://github.com/Dokploy/dokploy/blob/main/LICENSE.MD