For those who have even simpler needs (like side projects, or 1 dev projects), I found using simply docker and git to be plenty enough.

Basically, you can create a bare git repository on your server (`git init --bare`), and put a `hooks/post-receive` script within it that will clone sources in a temporary directory, build the docker image and rotate containers. That way, you can `git push` to build and deploy, and it's easy to migrate server.

The added bonus is that you now have a central git repos that can act as backup, so you don't need github or gitlab.

The main painpoint, which I find dokku interesting for (and I assume caprover too) is zero-downtime deployment. But well, if this is critical, you probably need something more extensive.

Here is an example of post-receive script I use for that:

    #!/usr/bin/env bash

    export APP=appname
    export DOCKER_OPTS=""
    unset GIT_DIR

    rm -rf /home/username/apps/$APP
    cd /home/username/apps && \
    git clone /home/username/git/$APP && \
    cd $APP && \
    echo building image && \
    docker build -t $APP .
    if [[ "$?" != "0" ]]; then
      echo "error while building image."
      exit 1
    fi

    echo "Stopping previous container..."
    docker stop $APP

    echo "Starting new container..."
    sleep 1
    docker run -d --name $APP --rm $APP

You should at least use `set -u` in this script, otherwise, at some point, you'll fail to set $APP and end up running:

  rm -rf /home/username/apps/

Guess how I learned this lesson? :)

Ooooh, I need to start documenting my war stories. They'll make for a fun read at some point years down the line.

FYI, you can avoid the $APP directory removal and clone by doing:

    GIT_WORK_TREE=/home/username/apps/$APP git checkout master

Yes, that's true, thanks for mentioning it. It comes from a time when I did not use docker so I wanted to get rid of build artifacts, but building within docker, this is not a problem anymore.

If you need to use your "old way" for something else, you can use 'git clean -fdx' which will remove all files and directories that git does not track.

I actually developed a system similar to this but used docker compose as an alternative to Procfiles and nginx+le to handle dynamic virtual hosting. It's actually a golang app that will automatically provision git repos with the necessary hooks and also allow you to exec into a container directly over SSH. I had the thought of using docker stack to achieve zero downtime but haven't had a chance to try that out. Happy to open source it if anyone is interested in using it.

The problem with nginx based setups is that one wrong container option (label, env var, etc ...) may cause a syntax error in the nginx configuration file and then nginx won't start, so all services will be down. Loved apache, loved nginx, but I can see traefik is the only http server on my tech blog for the last years...

Nginx is made to load a configuration: you don't have the auto-configuration that comes with service discovery. Service discovery is doable with a standard HTTP API through /var/run/docker.sock or /var/run/podman/podman.sock in more advanced systems.

As such, service discovering HTTP servers are more reliable because it's built with a service isolation from the ground up: if one service has some poor value then it won't work, but it won't block the other services.

Nginx is too far behind now, they might have some service discovery module, but even then the thing that happens when your configuration autogenerates (like with snapshot testing) is that you still have to read the configuration it generates. Traefik offers a great dashboard for this so it's even more pleasant than reading a configuration file that you didn't even write ;)

For sure, I bet that in a patch into something like CapRover (or your own solution), changing nginx to traefik would end up removing quite a lot of code ;)

I'm not really sure what you mean "acheiving ZDD", ZDD is complicated any time there's a data schema migration, not to mention that containers deployment traditionally is "delete a container: KILL a process" and "create another one like cattle". uWSGI for example, could gracefully renew every worker process on SIGHUP, but re-creating the uWGSI process in another container defeats that. Maybe you have some kind of blue green deployment, maybe even canary, in this case I wonder if basing a container platform on configuration files such as those for nginx would really make it to ZDD. Would love to read more about your setup

These are all extremely valid points! I guess I should've clarified how things work a bit (which I am currently in the process of documenting how it works and how to deploy it).

Ingress management is done with the very useful nginx-proxy[0] service that loads virtual host definitions directly from the docker daemon and sets virtual hosts based on env vars set on the container. Configuration changes are loaded using an nginx reload, so even if there was an error in the configuration (which I personally have never run into though is likely possible), it wouldn't take effect. LE is then handled using the nginx-proxy-letsencrypt-companion[1]. My goal was to abstract away reverse proxy+cert management and I think any solution (traefik, caddy, etc) would work here and I'm more than happy to change it. More or less just went with nginx since it was easy and I didn't have to do any configuration other than adding it to a docker-compose file.

I guess my goal wasn't to handle ZDD for stateful applications. As you mentioned, there's a plethora of issues that arise and make that type of application much more difficult to do ZDD. I tend to write a lot of stateless web apps for simple use cases and like to have an easy way to deploy them. In the primitive sense, creating a new container, waiting for it to be ready, and then swapping the upstream used for the reverse proxy with the new pointer would be ideal but isn't supported directly with docker-compose (as mentioned).

Happy to talk this through also, especially if you'd be interested in contributing!

[0] https://github.com/nginx-proxy/nginx-proxy [1] https://github.com/nginx-proxy/docker-letsencrypt-nginx-prox...

Actually, the experience with broken config comes from using nginx-proxy (along with the le companion) in production for 18 months or something, that and other inconveniences pushed me to give Traefik a try and I was really delighted, no dealing a configuration template, and I can view the configuration from the web dashboard instead of having to ssh into nginx to get the config.

Traefik and Caddy are not comparable in my opinion because Traefik was literally made for self-configuration based on service discovery, see an interresting discussion here: https://www.reddit.com/r/selfhosted/comments/gq90aw/traefik_...

I completely agree with you about ZDD, 99.9% of uptime is plenty enough for 99.9% of the projects, and trashing the container to start a fresh process from a fresh system build does come with other advantages. Sure, any kind of blue/green deployment or canary would be really nice to see, but it wouldn't seem to create a lot of value for 99.9% of the projects, and for the rest well there's k8s that deals with clusto

Currently I'm just using a bunch of ansible roles with an ansible command line wrapper, so I'll do `bigsudo yourlabs.netdata @somehost` and it'll auto-install yourlabs.traefik if not already there, which will auto-install yourlabs.docker if not already there, and basically just leave me with `https://netdata.somehost.fqdn`

Thank you for the invitation to contribute ! As you probably guessed, I'm a bit like you in the sense that I cannot live without making my own system, and I have made different design decisions:

- Python for server side, I find it more fun than JS, nothing we can do about that

- Python for client side, because we maintain our crazy isophormic component library in python

- Not docker, but podman, which can run rootless and daemonless (thought we need the daemon that provides a docker compatible API to have Traefik service discovery)

- Not docker build, but something I'm cooking on my own ("shlax") that I find a lot better for my taste, and that uses buildah which can build rootless

- Not docker-compose, but shlax, which aims to support a broader range of use cases (such as backup/restore)

- The thing I'm building is first a really KISS Sentry alternative, then also a GitLab alternative, and I'm in the process of adding CI into it ... but I stopped doing that until I have finished my little Python lib ("shlax") that replaces docker/compose and ansible to have something to put in the CI test that's not tech that I'm trying to move away from, and so that it can build/test/deploy itself,

So, I suppose our goals and design decisions are a bit too different, but I can assure you that I'm always happy to see CapRover featured in social media, and I'm always happy to discuss rare passions like that, if you're looking for a crazy friend recoding his entire little world to just talk about these kind of things feel free to send me an email or give me a call ;)

please do!

Would love to see it!

Please open source it

That is what Piku (https://github.com/piku) is all about. You can easily deploy containers through it as well.

Really what I want for my side projects is just to be able to push my projects to github, and if they have a manifest file, they should just automatically spin up on a subdomain with the same name as the repository. I don't see why it should be any more complex than that, and I'd be happy to pay a small sum every year to have that.

Similar to this? https://www.digitalocean.com/community/tutorials/how-to-use-...

How exactly is the zdd you're talking about ? zdd for 100% of use case seems like quiet a rabbit hole, particularly when any kind of data migration needs to happen. I suppose my question is: at what point can we claim doing zdd ?

Caprover doesn't do zero-downtime deployment currently fyi

I have been using CapRover and love it. I donate to their OpenCollective[1].

For those noting "why don't you just use Linux / k8s / ...", that feels close to the original complaints re: Dropbox on Hacker News[2]. I've run clusters hundreds of nodes in size myself but CapRover gives me the pleasure of not having to sweat the small details. You can get this from other platforms but usually there's a dollar cost tied to each option. When I'm experimenting I don't want to have a dollar cost attached.

Deploys are trivial. The default nginx setup is most of what I'd want to do. LetsEncrypt is a single button click. Monitoring is included by default. If I need to scale up, everything I'm pushing is Docker containers. If I want to experiment, there's great fun in looking at the included "One click apps / databases" and just playing around.

CapRover is just a lovely freeing experience that will do what you need :)

[1]: https://opencollective.com/caprover

[2]: https://news.ycombinator.com/item?id=8863

Have you used Dokku before, or did you look at it before settling on CapRover? (I'm just starting to look at both)

I have experience with Dokku, Flynn (also look at this if you're looking at Dokku), CapRover, k8s, and a tiny bit of Nomad.

I think CapRover has the best experience out of the Dokku/Flynn/CapRover "group". Not a huge Dokku fan. Would use Flynn over Dokku again, but I'd rather use CapRover over both.

https://flynn.io/

If you're intent on using Dokku, there's a useful web console:

https://github.com/palfrey/wharf

I would agree with that. I’ve used most of the various options for a DIY PaaS and also prefer CapRover.

CloudRon [1] is actually really great, but its pricing is prohibitive (and changes frequently) for side-projects, which is when I most want to use something like this rather than just deploying/managing the k8a myself.

[1]: https://cloudron.io/

Would you say CapRover is 'more complicated' or more suited to bigger projects than Dokku? I gave it a good hard look before deciding on Dokku, as my use case was so simple, but wondering whether it'll scale.

I'm a very happy Dokku user, I've been using it for years with no problems, though CapRover seems very interesting.

Given your Dokku experience, do you mostly interact with Buildpacks or Containers? And why?

To chime in here, containers all the way. Started with buildpacks as that seemed like the ultimate zero-conf approach (like Heroku), but very slow, so switched to Containers. Works a charm.

How do you mean? I never touch the actual containers, I always just let Dokku take care of those, I just push the code with the Buildpack and Dokku handles the rest.

Oh wow, disregard that. I've never even touched buildpacks, didn't really know they were a feature. Everything I use is containers.

There is always a container in the end. But do you actually provide a Dockerfile along with your app code, or do you let buildpack create the container for you (ie. no Dockerfile in your source code)?

Yeah, it's all containers. Here's my template project:

https://github.com/skorokithakis/django-project-template

> If I need to scale up, everything I'm pushing is Docker containers.

Does CapRover manage a shared storage or do you still manage it yourself (ie. Ceph, gluster ...) ?

I have been using CapRover for about half a year now on my personal server running multiple projects. It does what you'd expect and the configuration format is pretty easy to use, using any docker image directly works without any extra steps, just enter the image name and it'll do the rest. I'm pretty happy with it and will probably stay with it for the time being.

It's not the best for hosting many static pages, as you'll need a HTTP server for each site anyway.

But my main gripe is that there is only single factor authentication and you can't easily secure it more other than using a strong password and a hidden subdomain. (because of webhooks, acme, etc. I guess)

If you have a vpn, you can edit the nginx config for the admin panel and make it only accept connections from your vpn ip address.

Single factor is more than fine in the case where you know the admin (yourself) is going to use a 30 char random password and use a password manager that won’t autofill it on phishing domains.

Hi sneak, I left a comment explaining my journey with CapRover in this HN thread. In there I explained one thing which concerned me was "netdata image in use is spyware #553" which you raised last year.

I haven't yet gone through the discussion but would you mind letting me know if you're satisfied with the outcome? You appeared to be fighting for increased privacy, so thank you.

Also you'll see that in my comment, I raised another issue RE: lack of two factor auth. I'm curious, why do you think single factor auth is fine? Simply because brute force for a 30 char password is not practical on todays hardware? Or is there something I'm missing?

Kasra here from CapRover. Regarding "netdata image":

- sneak and I have fundamental differences in what we call spyware. The issue that was brought up in that thread is standard analytics events - nothing like stealing passwords or etc.

- Regardless, CapRover uses NetData 1.8 [1] . According to NetData's github page, they added analytics in NetData 1.12 [2] , so even if you're concern with analytics events, this issue won't apply to you anymore.

Regarding two factor auth: CapRover blocks brute-force attacks by limiting number of wrong passwords per minute.

[1] https://github.com/caprover/caprover/blob/48440db14aa115aca1...

[2] https://github.com/netdata/netdata#quickstart

Thanks Kasra, yes it seemed 'spyware' was disputed and I didn't want to jump to any conclusions. But it's good to know it's a non issue.

RE: 2fa. Brute force protection is a step in the right direction, but passwords can leak in various ways, brute force isn't the only attack vector. I'll comment in the actual two factor auth discussion on the CapRover GitHub issue though.

The version of NetData included in CapRover is a version from before when NetData became spyware, so it’s fine. (Note that I haven’t audited it, that’s just what I’ve been told.) NetData is also optional; I use CapRover and do not opt to install it.

Brute forcing a 30 char (or even 20 char) password over the network is infeasible. Do the math. Regardless, as the CapRover developer pointed out in a sibling comment, it rate limits attempts, but in the case where you are using a long, random password, it would be fine even if it didn’t.

Could you quickly explain the math behind this please? Genuinely curious

For every character in the password, you have 26 possible letters to choose from in an English alphabet.

Brute forcing this, you would have to try every combination. Which means for a four-letter long password: 26x26x26x26 = 456 976 possible passwords.

For a 10 letter long password: 26^10 = 141167095653376 possible passwords.

You forgot the other 26 uppercase letters, and the 10 digits 0-9. Looks good otherwise, but the result is much larger with a base of 62.

Clarifying it further is “number of days to brute-force if you can try (eg) 10k requests/sec”.

Absolutely, you are of course correct. The uppercase letters and digits - together with the special characters like "!._-,...".

I kept it to 26 letters to keep the math simpler (or rather - the numbers smaller, for myself, really).

Number of days to brute-force if 10k requests/sec (26 letters still...):

4-length password = 45 seconds

10-length password = 453 years

Please give me a heads up if my math is off.

How does it handle upgrades ?

for me it was seamlessly and I needed to jump a few minor versions.

> you'll need a HTTP server for each site

isn't that what virtualhosts are for?

CapRover creates virtual hosts for each "app" which is then proxy_pass'ed to the container for said app.

You could try and mount the static site's container files to the local filesystem and serve from there I suppose, but there's currently no easy way to do so.

he's still in the early 90s

awaiting TIL..

Slightly nitpicky, but is something a PaaS if you run it yourself? Anything as a Service isn't a service if you're running it yourself. It's just ... infrastructure.

Not nitpicky at all - this is an important distinction to highlight for pointy-haired decision makers.

This product is undoubtedly the P in PaaS, but there is no service behind it. If your company uses this as an alternative to a real Heroku/AWS/xyz PaaS, you must have engineers at hand for 24/7 ops, scaling servers and fixing bugs. In my opinion, this is quite risky for anything running in production and should not survive a cost-benefit analysis.

> should not survive a cost-benefit analysis

I completely disagree, the difference of price between dedicated servers and even EC2 instances is completely amazing.

This is what you get for less than $200/month with a dedicated server:

1× AMD EPYC 7281 CPU - 16C/32T - 2.1 GHz, 2 × 1 To NVMe, 96 Go DDR4 ECC, unmetered 750 Mbps

In one of my companies the AWS bill is just completely insane, we have like half that hardware, with a really small bandwidth, which is metered, for more than $800/month, which is fine while we're on free credits.

I love working for cloud companies, it's a lot of fun, but when it comes to my money then I never go for anything but a dedicated server.

All these things are relative.

When you got applications that don't require high availability while needing a very low cost per CPU, dedicated servers just make sense. We are running a cluster of a few high-CPU dedicated servers for our data-science team, and it just makes sense: we don't need 99.99%+ availability, and the servers we rent are cheaper than the equivalent AWS storage cost alone ... The op cost of managing these is exactly the same as managing equivalent EC2 instances. We don't need backups either.

On the other side, we got some low-CPU web services that require high availability, redundancy and reliable backups. For these I just use Heroku. It's extremely reliable and easy to operate, while only costing about $100/month (a few hobby dynos + a fully managed PgSQL DB). Sure it's probably 5x more expensive than a dedicated server with 10x the performance, but I don't have to worry about backups, availability and scalability. And these apps just don't need this 10x faster CPUs anyway.

>web services that require high availability, redundancy and reliable backups. For these I just use Heroku.

How do you handle Heroku outages then?

Heroku outrage free was 99.9999%+ over the past 60 days[1], I'd have a hard time achieving this with a single dedicated server.

[1] https://status.heroku.com/

Do you really mean that you never had a server with 60 days uptime ? This is really insignificant to achieve, even a reboot per month is nothing, 99.9% of uptime is enough for 99.9% of projects, and a monthly reboot does not even get you close to that service level.

I am not affiliated nor haven't tried CapRover (for special reason of: coding my own for my tastytastes), but I would bet any standard system administrator could get a 99.9% uptime after the second month of production without particular effort (unless they don't know underlying technologies ie. "what a container" "what http" "what is namespace" "what iptables" ...)

I have a raspberry pi running on my desk that has been running for 60 days sitting on my desk with no outages. I don't even have a battery backup!

Maybe I am just an exception but I have 100% availability on one dedicated server for the last 2 years.

I love how there's this myth that servers and services just blow up every 10 minutes 24/7 and unless you have a legion of ops personnel you're going to get hours of downtime each year.

Servers, for the most part, just work. In DC climate-controlled environments, hardware failures is exceedingly rare. Apart from harddrives, most hardware will happily tick along for a decade, if not longer.

Sane production-grade OSes (read: not Ubuntu) will also happily run for literal years with zero human intervention. For obvious reasons, it's a bad idea to not patch your systems, but things will continue to "just work" pretty much forever unless you're running really shitty code.

For renting vs buying servers, there's upsides and downsides. Buying gear is far far cheaper if you plan to be around for more than a year, but renting dedicated servers gives you a lot more flexibility -- to provision a new server, you hit a button in their online panel, wait 15 minutes, then let your deployment strategy take care of the rest.

I find it almost mind-boggling that AWS and friends have convinced people that it's normal to spend ridiculous amounts of money for fairly "meh" service specs in what's essentially VMs.

The points you make are fine but I think the experience becomes more painful linearly with the number of servers you manage, since you're N times more likely to see something happen that takes down a server. It just happens more frequently. At some point that becomes often enough that you don't want to deal with it anymore.

I don't think you understand the sheer scale you need to be experiencing a failure more often than once a month. By my anecdotal experience you'd need at least 1k servers for that to happen... and if your company is big enough for $2MM capex for servers alone you can handle $100 remote hands and 30 minutes of engineer time.

Not to mention that at that scale you have plenty of redundancy and, if your ops team knows what they're doing, automagic failover / HA. Anything that happens can easily "wait till Monday", no need for 24/7 anything.

If it's often enough to be noticeable, your scale is large enough to pay someone to be ops full time.

That example is not realistic. You rent dedicated servers from a provider that will always have extra hardware at hand, and handle all of those steps; you don't rent hardware yourself and run it in your basement :)

What you just described is a kind of hardware service!

Or you rent managed servers or colo space from one of the many hosting providers that also offers cloud services, and pick and choose. That lets you migrate your base load to colo or managed servers over time, while you still have the nimbleness of being able to scale up and down dynamically if you want or need to.

And my experience from providing devops services to clients on a contract basis is that the clients who use cloud services tends to need more, not less, devops assistance.

Certainly hardly anyone should be physically managing their servers. The relevant comparison is between getting 1GB RAM in the form of a $50/month Heroku dyno and getting it with a $2/month VPS (actually with Hetzner that will get you 2GB, they don't go below 1GB).

Nope, you have IaaS (Infrastructure as a Service) like OpenStack, and PaaS (Platform as a Service) like OpenShift, KelProject, CapRover ...

The idea is that you ask OpenStack a VM and it will give it to you, dealing with the lower level details for you.

PaaS means that you ask it to deploy a service and it will deploy it for you, dealing with lower level details for you.

Neither you nor the parent are wrong but I'd argue that you don't really see IaaS or PaaS used all that much for on-prem platforms these days. (And the definition of PaaS was always a bit fuzzy--something like an abstraction that is in between IaaS and SaaS.

You're probably more likely to see OpenStack called a private cloud or on-prem cloud than "IaaS" these days. And OpenShift is usually called a Container Platform rather than a PaaS.

The definitions have always been pretty clear to me, but all right then, thanks for the heads up, I guess CapRover people and I are also what we call "old school devops" these days.

"Container platform" seems pretty vague to me, PaaS means something I know right away.

I mean, k8s is a container platform too isn't it ? But you'll need to build what we called a PaaS on top of it yourself (or use something like Kelproject, OpenShift ...)

Yeah, the terminology isn't always super-clear. Yes, k8s is a container platform. OpenShift, depending upon how you use it, can span a range from being an integrated k8s distribution to something a lot more like what was commonly called a PaaS with developer tools, CI/CD pipeline, registry, etc.

PaaS isn't a verboten term or anything like that. But it turns some people off because it was most associated with services/products/projects that mostly focused on a simplified developer experience at the cost of flexibility.

Well, for me PaaS is a software built uppon bricks like an image registry (also present in IaaS), authentication registry (also present in IaaS), developers tools ie. to log into a system (also present in IaaS). But, with the IaaS you get an infrastructure of bare virtual systems, emulating a physical world, and with PaaS you get deployments of code. A PaaS works on a IaaS, but can also run on baremetal, it doesn't matter for the PaaS in general. With PaaS, you don't need to define bare system provisioning, PaaS does it for you, many IaaS teams ended up implementing their own PaaS one way or another, back in the days you are refering to I guess.

k8s for me is a framework, OpenShit, Rancher, KelProject would be "distributions" of k8s, just like Linux kernel and distributions including it.

As a person who writes technical requirements and implementation document, it strikes to me when I'm asked to document implementation of a "SaaS" that there will be paid accounts and billing.

Maybe CapRover will provide paid accounts on managed servers in which case they would be creating a SaaS with their PaaS solution.

But again I'm not talking from a "managerial" perspective of the definitions, rather from a technical one. I suppose at this stage CapRover is trying to attract technical users rather than managerial ones (unless they have something to sell for cash but I didn't see it on their site or just missed it)

PaaSS - Platform as a Self Service

”Service” to me is just ”delivery of something with a specific scope and a defined contract”, not so much about who delivers said ”service”.

Many IT depts would do themselves a massive favor to deliver actual services instead of “just infra and some stuff thrown on top” and call it service delivery.

Tools like in this link can help, but a big part is simply about automation and delegation/self provisioning.

You can't just decide that words mean different things to "you".

Platform as a Service or anything "as a Service" means someone else provides it as a service (ie subscription). The Platform part is all this is offering. So it is not a Platform as a Service.

Yes, ”someone else” - be it delivered internally from one team to others or b2b.

It is not necessarily hard tied to a business model, but of course I understand that this is the common usage.

It’s really about abstractions and consumability.

This is my interpretation of the NIST meaning of aaS.

I just read it as short for "cloud infra project with controls modeled after popular PaaS products"

The distinction you are drawing sounds to me like the difference between "managed" and "unmanaged."

My read on whether something is a service or not is, can I make a request of the thing in simple terms, and have the thing carry out all the messy details on my behalf?

maybe you want to decouple sysadmins from devops? sufficiently large orgs with sufficiently large on-prem infra have these kinds of problems.

Yeah, it's more like a PaaS alternative

I was just thinking the same thing - maybe we can call it self-hosted PaaS.

Curious as to how this compares to Dokku (http://dokku.viewdocs.io/dokku/)?

CapRover has support for multi-server deployments using Docker Swarm. It also has a nice dashboard with built-in monitoring and such. There is a marketplace of sorts with single-click deployment for certain applications.

Dokku on the other hand has support for buildpack deployment as well as Procfile support for running multiple processes.

I prefer Dokku. The main reason is that I only need a single server for my apps and running Docker Swarm adds complexity.

I wrote about some other differences in my blog: https://www.mskog.com/posts/heroku-vs-self-hosted-paas/

Dokku supports multi-server deployment via Nomad and Kubernetes as well.

- https://github.com/dokku/dokku-scheduler-kubernetes

- https://github.com/dokku/dokku-scheduler-nomad

Do these work well? I've never heard of either.

Fantastic write-up, thanks!!

There is someone working recently on swarmlet (https://github.com/swarmlet/swarmlet) - a Dokku inspired Docker swarm solution.

Swarmlet seems to be very young and not production ready. Still, I am exited to see how this project will evolve with time.

Their copy writing is funny and honest, I like it!

When it comes to operations I often feel overwhelmed, even though I've done DevOps and automation work in the past.

Most of the things I'm working on professionally don't need the "scale" part, but the "robustness" and especially "ergonomics" parts. When I look at most infrastructure solutions, then I often get a combination of "this is too complex" and "I don't need this".

So I was drawn to solutions like Heroku at some point, but there you cannot even do the most basic thing: persistently writing to the filesystem. So you are forced to introduce system level complexity and coordination for such a fundamental feature.

Naturally I tend to prefer simple tools that enable things rather than constrain them.

Side note: I think when the "code has to run on some computer" problem is finally solved, then we likely see an explosion in productivity in our industry.

Dokku is best if you only need a single repo support, caprover if you will have multiple apps, and or multiple servers.

How so? I use dokku on A DigitalOcean server for a dozen apps. AFAIK cluster support is different (it exists). What else?

Another great alternative in this space is dokku[0]. Haven't tried CapRover recently but it looks fantastic.

[0]: https://github.com/dokku/dokku

I've been using Dokku for a side-project, and it's a really nice tool! My only gripe with it is that it's not easy to deploy an existing docker image. You have to pull it, then transmit it over ssh with "docker save" and "docker load".[1]

Migrating the docker image building from the dokku server to a CI would be easier to do without this. On top of that, deploying an existing software into your machine would be easier.

[1] http://dokku.viewdocs.io/dokku/deployment/methods/images/#de...

dokku is also meant to build a custom image on deploy : rather than using heroku's buildpacks, you can put a Dockerfile at the root of your project and it will be used instead.

So basically, you could put a Dockerfile file container just FROM and MAINTAINER, referring the image you want to use in the FROM, and dokku will download and execute it on `git push` (provided it can access to the image repository).

This is good at first, but I deployed on a very small machine, that couldn't handle the live application + the Docker image being built, thus why I wanted to build the image in my CI pipelines.

+1 for this -- requiring the docker image to be built/managed on the machine it's being deployed on is the simpler architectural choice (easier to debug, etc), but it doesn't necessarily make sense for production.

I wonder if there's a ticket about this on dokku already

[EDIT] - Couldn't find anything... Some tickets about how the containers are built and changing the base image but not much about.

I wonder if you could jury rig something like kraken[0] and make sure wherever your building images is a peer or something... Of course the simpler solution might be to add a CI step that just pushes the image (via the working `docker save` method) to the deployment machine(s)? Maybe if you have a staging environment, let CI push there, then if that machine is peered (via something like kraken) with production, production will get the image (though it may never run the image).

[0]: https://github.com/uber/kraken

You can deploy a custom image via the `tags` plugin.

I've recently learned about exoframe as well, but haven't tried it yet. https://github.com/exoframejs/exoframe

i used dokku a couple years ago for a side project. It worked really well ( especially the newer versions ). It was super nice when the letsencrypt plugin came out, SSL support with trusted CA signed certs built right in!

I can recommend in getting in k8s with something like microk8s from ubuntu:

You will learn k8s and you will get the same thing as they do but with open components, industry standards and a whole industry moving in this direction.

I have already microk8s running at home with argocd. I have never had IaC that quick and that simple setup.

With traefik you can have your domains as well. Then just go to gitlab (or now to github, haven't checked out yet if i wanna migrate back) and register your microk8s cluster as a buildrunner.

Thats it you are set. Quite future proof setup, modern, stable, easy to use.

How does the deployment process differ from CapRover/Dokku?

Deploying a simple app with a database with Dokku is something like: 1. Run command to create a database of your choice(Postgres, MySQL, Redis etc) 2. Run command to create application 3. Run command to link the database to the application 4. Push to the Dokku repo to deploy the application.

Don't bother k8s is like the lvl of the dragon in front of something like dokku, If you don't really look for auto scaling, or you are running a business alone, don't go for k8s

Both can solve the same issue and both are similiar as they orchestrate your platform.

Kubernetes is just the future, used by much more people and you have the additional benefit of learning kubernetes which might help you in your job/day to day business etc.

If you are already thinking of operating CapRover/Dokku, i would strongly considering using kubernetes instead.

This tool looks really cool. The section where it listed reasons for using it really struck a chord with me. I am not the most comfortable using all the Linux tools when it comes to setting up servers / system administration. This product looks to be a really good bridge between devs who dev primarily, and those with skills in deployment. Super cool. Thanks for sharing, I will be using this!

Isn't that a setup waiting for disaster to happen? Everything is happily running up to a serious production problem, at which point you miss the experience to debug and fix it.

Then I will have to learn then. I feel most productive and comfortable working on a hobby project if I don't need to spend all of my time dotting the i's and crossing the t's with cli and configuration files. I just want to build. I don't see the value investing my time learning the ins and outs of tooling that I will use maybe a few times when it makes minimal impact, as it comes with an opportunity cost for me elsewhere. That's just me though, I have no gripes with people who love to tinker with their set ups. It just isn't my thing.

I absolutely agree, were it something commercial these things would need to be considered.

Are there any tools you recommend looking into, were I to take the next step? I don't plan on depending on CapRover to fill gaps in my knowledge for too long, but for now this product really is a good start for me.

No problem in depending on CapRover, as long as you are at least somewhat familiar with the tools it sets up for you. Combine that with some crude generic UNIX skills (quickly analyze cpu/ram/disk usage, search in logs, transfer files, modify configs etc.) and you're way better prepared.

Ironically it's best learned "on the job" (for me at least); just try to deploy your app from scratch. Play around with nginx/apache, letsencrypt, your db stack, packages installation etc. and get a working product.

I'm no expert by far in any of this, but think that knowing "just enough" about these tools really helped along the way. Up to the point where I can now use CapRover like tools with some degree of confidence, closing the full circle ;)

Thanks for the info. I look forward to learning from it. I will try the 'on the job' approach as that's how I learn most effectively. :-)

There's also the issue of security. How do you know there's not a big security hole and it's just a matter of time before your data gets stolen or your server becomes part of a botnet or starts serving illegal content?

The same thing applies with these turnkey admin panels like cPanel or Plesk and which is why I don't recommend getting anywhere near those.

Well, I wouldn’t say I miss it ....

A few weeks ago I mentioned on HN [1] I was looking for something where I can take a $5 VPS and install a bunch of Node.js apps easily. I did this with DigitalOcean + CapRover and it was extremely smooth. Initialising the app, enabling SSL, deploying - everything just worked. It was great.

I was hoping to move over, but I won't just yet. Was hoping for two factor auth support [2]. The dashboard was publicly facing and only guarded by a password.

There was also an issue which concerned me: 'netdata image in use is spyware' [3] - however I have not digested that thread and its related discussions to understand if it's a genuine issue yet.

Finally, I was hoping to understand more about the motivations of the project. Who's funding this project? The OpenCollective [4] page shows an annual budget of $529.55 USD? What are the long term goals? How can they sustain themselves?

I use PM2 for running some of my Node.js apps, but I can see there's also PM2 Plus and PM2 Enterprise [5] which helps me understand how they're able to sustain the free version.

I don't mean to be pessimistic towards a piece of software which actually works extremely well. Just want to better understand its long-term suitability for deploying production-grade applications.

[1] https://news.ycombinator.com/item?id=23278095

[2] https://github.com/caprover/caprover/issues/493

[3] https://github.com/caprover/caprover/issues/553

[4] https://opencollective.com/caprover

[5] https://pm2.io/pricing

Caprover is a great tool to have in one's kit but coming from Dokku [0] i think it lacks a certain flexibility when deploying applications with worker processes. You can get around this by creating multiple "captain-definition" files in your project but i prefer Dokku's adherence to Heroku's "Procfile" approach. However Caprover's web admin/dashboard and docker swarm features are a nice touch.

  [0] https://github.com/dokku/dokku

I'm using CapRover on a personal server of mine and it's pretty awesome. I use it for side projects and tinkering and tooling (analytics, bitwarden). it's very stable with lots of "one click app deploys" of popular open source software.

Combined with portainer (which u can install with caprover) I'm improving my docker knowledge. I'd recommend it for someone starting out with containers and "home labs".

CapRover was mentioned in the thread about the coinbase stack [1] - I guess that's why it's popping up here now.

As I said in that thread - this looks interesting, but the installation instructions put me off a bit. Open a port on your server, and don't change the default password `captain42` - then run a cli tool from your dev machine.

1: https://news.ycombinator.com/item?id=23460066

Can some developers explain to me why they don't want to set things up themselves? If you already know how to do it, it's not very time consuming. If you don't yet know how to do it, learning how it all works only benefits your understanding of the service you're providing, and empowers you to fix it. It's almost like learning a new trade, and can give you a new perspective how your code runs.

Maybe it's because there's so much arduous research required to finally figure out what magic commands to run to get something to work. Would having a set of HOWTOs that just explain the steps to set up each component work as well for you as a turn-key solution? (It would be great if we could start a trend of people writing a HOWTO.md after writing their README.md)

I mean, speaking for myself — I know how to set things up for myself and have done it plenty of times, but sometimes for side projects and playing around, I just don’t want to go through that process. I like having a dashboard I can login to, I like having to install one thing rather than having to setup my environment from scratch the same way every time. And I like that if I have to let someone else have access to something, I can give them something without having to pray they don’t break something or teach them.

Honestly, I do a lot of the setup work for my actual job — including documenting/creating demos and examples for others — when I’m doing my own side stuff, I really just don’t want to bother, especially if it isn’t in production and it’s just on the home lab.

To use a crude analogy, I could build my own robust NAS with hardware components and a BSD or Linux distro optimized for storage and acting as a home server with better performance at a lower price than a Synology system. Or I could continue to use my 8-bay Synology NAS (that I really want to upgrade), because the appliance nature is worth the extra cost and pure performance deficits. There was a time I took great pleasure in maintaining all that stuff myself but honestly, I just want to plug it in and know it’ll work with all my machines without having to think about it.

it isn't about how time consuming it is, it's about consistency with the deploys and consistency with the environments. you want your development and production environments to match.

Since someone was happy with this before, I’d like to recommend https://github.com/exoframejs/exoframe again for a more console oriented way of doing this same thing.

Shameless plug: If you don't want to use containers or are using resource-constrained Linux boxes, have a go at https://github.com/piku :)

Looks solid. I am all set for the wave of fully controlled PaaS solutions coming our way. Most of the innovation has stayed locked behind closed rooms at AWS, Microsoft or one of the major cloud companies. This brings in more control and an extra dimension to optimize.

Looks like an open, free, very very early re-implementation of a solution such as Cloudron.io .

Very cool!

Background info: https://www.freecodecamp.org/news/how-i-cut-my-heroku-cost-b...

this makes me so happy - to see a PAAS on Docker Swarm!

However, I wish the caprover had built this experience on top of kubernetes (or k3s) instead of Swarm. The future of Swarm is really unknown and the ecosystem is undoubtedly behind k8s.

but swarm is much more simpler, I'm concerned about future too.

How does CapRover work with databases? Does it replace something like RDS?

What does PaaS stand for? The website doesn't say. Platform? Product?

Platform as a service. It's like a step up in abstraction from IAS, infrastructure as a service. The lines begin to blur near the edges though, it's a marketing thing really. Just like "cloud" means many different things to many different people but it's a simple one syllable word perfect for brochures.

Does Caprover support multiple "ingresses"? In that I can have an external load balancer balancing between my clusters servers? I can't seem to find any info on that in their docs.

Should be possible it uses Docker Swarm, which can handle multiple ingress. https://docs.docker.com/engine/swarm/ingress/

You can expose some ports on different nodes and point your external LB (for ex. cloudflare)

I'd be interested to know how people who use this kind of thing (or Dokku, etc.) keep their OS, database, applications, etc. up to date, for security reasons if nothing else.

You update your image, stop the container, start the container (with the new image). That's all.

You can create complex containers that could update with security fixes without restarting. But it is easier to update an image e.g. once per week/day and auto restart the containers.

I've been using portainer for managing a handful of basic containers on my home server (zoneminder, deluge, jellyfin, unifi controller). Overall I really like it, but some kind of feature to do this is probably the #1 thing I'm missing. It even lets you launch "stacks" from a compose file in a git repo, but doesn't have any facility to remember that info or do a redeploy, so you're basically starting from scratch every time:

https://github.com/portainer/portainer/issues/1753

Cool, thanks for the info!

I wonder about the underlying instance's OS, though... in the past, for home servers, I've set up cron jobs to get OS updates and reboot, but that seems wrong for a web server I'd like to be always up.

Maybe create a new instance, update the OS, install the app, switchover? Is there automation for this kind of thing?

I wonder what happens if something (like mysql) crashes for some reason or something like that happens, would something like that be easier to handle?

it will restart the container if the docker healthchecks fail

Can I say it's a poor man's Kubernetes?

K8s does not deal with CI/CD of your source code, nor can it automagically package your code out of the box. You need to compile your source and bundle it in the form of a docker image, host it and provide access to K8s to pull it. K8s is like Linux kernel, it's not usable for most people unless you package it with GNU utilies and other components people expect out of a distro.

Sort of yes, for personal projects and small business I would go for something like this or dokku and try to split services as much as I can, rather than managing k8s in my own

But if the K8s cluster is managed by cloud (e.g. AWS, Google, even DO), is this/Dokku still worth it (easier)?

Yes dokku still worth it https://news.ycombinator.com/item?id=23460066 and most importantly much easier

I can see exactly why this exists. It won't suit hard core roll your own developers - any more than WordPress theme generators suit DIY web developers - but for those who may be light on skills and time, this could be a superb way to get an MVP going really quickly and easily. Very nice tool to fill a gap.

(non dev) looking to run my own installation of https://github.com/excalidraw/excalidraw for team. Could I use this app? Straightforward to do? How would I estimate the costs?

As long as you have a (sub) domain you can use and a bit of free time, you could go to your favourite cheap 'cloud' provider, i.e. Digital Ocean, Scaleway, ...

Spin up a cheap instance (DO has a preconfigured image ready to go), git pull and caprover deploy to test. I am pretty sure even the cheapest ones will be able to run that.

A friend often tells me “you’re only ever one CloudFormation template away from your ideal PaaS”.

ahaha I like how this comes after the thread about k8S https://news.ycombinator.com/item?id=23460066

Is there anything like this for non web based applications? Looking for hosting for some Python apps pre-procssing data before delivery to clients.

Have a look at piku (https://github.com/piku). I built it especially for that kind of thing.

The web-app integration is completely optional and you can disable it for each app individually.

E.g. your database can be an app that doesn't have any web frontend.

You could probably use something like this or dokku? They don't only host web based apps.

Caprover can run non-web too, from databases to apps

how is this any different than setting up grapahana, nginx-proxy with letsencrypt companion etc with docker-compose and just replace my app image?

I was thinking the same. I guess it has a user friendly UI and monitoring features at the same time?

Quick tip on messaging on the homepage - replace _a developer who..._ with the feature highlighted (ie simplicity, batteries included, etc)

Is there something similar and user friendly, but built on top of kubernetes? I like the one-click app approach.

Can I deploy apps on different machines with this? E.g. can I run my app on 3 servers with a load balancer?

Yes, that is easy and work right out of the box. You should deploy it with 3 nodes and lat the manager work as the LB (is a single point of failure, though). A more complex solution would be deploying it with an external LB EDIT: Rephrased

Does CapRover support all configuration via files? Can I use it for cattle servers not pet servers?

this is a bit like sandstorm.io, which is also an open source platform for web applications. I've used it for a couple of years, and love it. It's cool to see other people exploring the same software space.

Care to elaborate on this? Which http server do you use?

HAProxy is what we switched over to at work. I'm not informed enough to give you the pros and cons of each.

See my other comment for my reasoning.

On the second point, I vary between Caddy and Traefik, depending on the use case.

Is there something wrong with nginx?

I can't trust something that may now be under the control of the Russian state.

The code is open, and is being analyzed by the entire world. This seems paranoid.

But you're fine with Caddy or traefik "that may now be under the control of the United States"?

All 3 of these are open source on github with widely used code bases that are free to view and read as you want.

The US government hasn't raided the homes of the primary developers of those, though.

I'll admit that the open source nature limits the damage a state actor can do, though.

That you know of ;)

If you are going to go full paranoid, you can't pretend that the media is 100% trueful at every aspect, especially when it comes to internal US affairs.

Yeah, the difference is at least some of the media can at least attempt to be truthful with limited chances of accidental novichok exposure, falling through the window or accidentally falling on a knife multiple times. etc.

Which is why I'm only 1/8th paranoid, not full paranoid. =P

Also, while every media source is biased, if you review enough angles on a given story, you can arrive at some semblance of a true account.

Would you mind to elaborate? I haven’t heard anything about Nginx being “compromised” before

Awesome.