Service binding is a feature that only large systems like Cloud Foundry support till now. Even Kubernetes does not have a functional implementation, the Red Hat operator is deprecated. It is a very useful feature, it allows you to configure a Postgres/MySQL service once and then each new app can easily bind and get a unique schema/database within the main database instance. Much simpler than the alternative of managing a separate database service for each app or sharing a service by either using same credentials or manually provisioning unique credentials.

I have been building the OpenRun https://github.com/openrundev/openrun project over the last three years. Recently added support for Postgres and MySQL service bindings. The flow is configure the admin credentials for your database service. After that, any new app can just ask for a binding and get a unique schema/database. Backups, monitoring, capacity planning etc can be done once for the main database, instead of repeating it for every new app.

Kubernetes offers powerful low-level primitives that can support virtually any deployment architecture. However, working with these primitives directly requires significant YAML wrangling. It makes sense to build specialized solutions on top of Kubernetes that simplify common deployment patterns. Knative is one such solution. Any solution that tries to expose all underlying primitives will inevitably become as complex as Kubernetes itself.

I have been building https://github.com/openrundev/openrun, which provides a declarative solution to deploy internal web apps for teams (with SAML/OAuth and RBAC). OpenRun runs on a single-machine with Docker or it can deploy apps to Kubernetes.

Makes no sense if you look at the start menu as an interface to the operating system.

Makes perfect sense if you look at it as one more place to show ads

Have been building a project https://github.com/openrundev/openrun/ which aims to make it easy for teams to easily deploy internal tools/webapps. While creating new apps has gotten easier, securely deploying them across teams remains a challenge. OpenRun runs as a proxy which adds SAML/OAuth based auth with RBAC. OpenRun deploys containerized apps to a single machine with Docker or onto Kubernetes.

Currently adding support for exposing Postgres schemas for each app to use. The goal is that with a shared Postgres instance, each app should be able to either get a dedicated schema or get limited/full access to another app's schema, with row level security rules being supported.

Cloud Run makes lots of sense when running lots of small apps, apps scale to zero automatically.

I have been building https://github.com/openrundev/openrun which provides similar scale down to zero functionality, on a single machine with Docker or on top of Kubernetes.

Another recent article on this topic https://www.arthurcnops.blog/death-of-show-hn/

Authentication and authorization are important requirements for internal tools. Low-code platforms support authn/authz for app access. Building internal tools with code is much easier now with GenAI, but ensuring proper RBAC access controls remains a challenge.

I have been building https://github.com/openrundev/openrun to try and solve internal tooling deployment challenges. OpenRun provides a declarative deployment platform which supports RBAC access controls and auditing. OpenRun integrates with OIDC and SAML, giving your code based apps authn/authz features like low-code platforms.

Building https://github.com/openrundev/openrun, a platform for declarative deployment of web apps.

OpenRun runs as a web server, which does GitOps driven app deployments. You can currently deploy apps on a standalone machine, on top of Docker/Podman. Working on adding support for deploying on top of Kubernetes. On Kubernetes, OpenRun will replace your build jobs (Jenkins/Actions etc), CD (ArgoCD etc) and IDP (Backstage etc). The same declarative config which works on a standalone machine will work on Kubernetes, with no YAML to maintain.

https://devpu.sh/ is another alternative, it has a nice UI built with Hypermedia (HTMX).

I am building https://github.com/openrundev/openrun/. Main difference is that OpenRun has a declarative interface, no need for manual CLI commands or UI operations to manage apps. Another difference is that OpenRun is implemented as a proxy, it does not depend on Traefik/Nginx etc. This allows OpenRun to implement features like scaling down to zero, RBAC access control for app access, audit logs etc.

Downside with OpenRun is that is does not plan to support deploying pre-packaged apps, no Docker compose support. Streamlit/Gradio/FastHTML/Shiny/NiceGUI apps for teams are the target use case. Coolify has the best support and catalog of pre-packaged apps.

This post looks at the experience with using Starlark as against YAML for deployment configuration.

Starlark can result in much more concise and flexible config. It does require extra work on the part of the developers who are writing the code (to read the config), but it can make things easier for end users writing the config.