Dokku can run against a Kubernetes cluster: https://github.com/dokku/dokku-scheduler-kubernetes

I assumed that Knative [1] is the canonical self-hosted PaaS for Kubernetes. It is branded as Cloud Run [2] by Google. I'm not sure how it compares feature-by-feature with Dokku nor a 12-Factor App PaaS like Heroku.

[1] https://cloud.google.com/knative

[2] https://cloud.google.com/run

This is pedantic, but Knative and Cloud Run aren't quite the same thing.

Knative is the "serverless" (bit a weird term in this context) eventing/serving framework, and Cloud Run is a managed Knative service.

You can self-host/install Knative to your k8s cluster and the experience you end up with is pretty PaaS-ey.

Less known is this space is Rio by Rancher Labs, which is also great + similar:

https://rio.io/

Isn't Knative for functions & serverless only? That's not my main scenario at home.

If Knative is more self-hosted FaaS than PaaS, that explains the core use case for Apollo; a traditional 12-Factor App PaaS for Kubernetes/Docker-Swarm. Knative supports a Serving Spec for routing (like AWS API Gateway) but doesn't seem to have buildpacks for 12-Factor App frameworks, as far as I can see.

Apex Up [1] deploys web apps on top of AWS Lambda using Amazon's API Gateway as the RESTful routing proxy. Maybe something like Apex Up is required to transform Knative into a PaaS for historical 12-Factor App frameworks. ZEIT Now 2.0 did the same thing for Serverless (Cloudflare Workers only?) but the company has been renamed Vercel and has pivoted around Next.js.

[1] https://github.com/apex/up

AWS now also provides native support for deploying 'regular' web apps using lambda + API gateway. I've been using this for my hobby projects - https://github.com/awslabs/aws-lambda-go-api-proxy

CapRover uses Docker Swarm internally, even if you're only running one node, which really sucks because it invokes the docker userspace proxy, killing the L3 source IP for connections in to your containers.