HN user
Building https://github.com/claceio/clace, a platform for deploying internal tools.
Targeting a specific use case (internal tools) should hopefully help avoid feature creep. Also, the goal is that an OpenRun config should work on a single-node with Docker and with Kubernetes. That limits the types of features which can be implemented (for example no Docker Compose support, no Helm support).
I don't think you can provide all the features of Kubernetes while reducing the complexity. What is possible is to support a subset of the features of Kubernetes while making it easy to use.
https://github.com/openrundev/openrun is a project I am building. It supports declarative deployments, on a single-node with Docker or onto Kubernetes. The target use cases is limited to standalone web app, like internal tools. No support for stateful services, you manage stateful services yourself. With that simplification, OpenRun provides a much easier developer experience.
Been working on making it much easier for application deployments to get access to a isolated database/schema. The usual pattern currently is to assume that each app creates a new database, which ignores the backups, monitoring etc required for each database. Implemented support for Postgres and MySQL.
Wrote up more details at https://openrun.dev/blog/service-binding/
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.
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. After you configure the admin credentials for your database service, 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.
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.
There has been lots of discussions about the issues with YAML and other config languages. This post looks at the experience with using Starlark as the configuration language for infrastructure deployment using OpenRun.
Starlark can result in much more concise and flexible config for end-users. It does require extra work on the part of the developers who are writing the code which reads the Starlark based config.
Yes, had similar questions. Wouldn't tuning the settings for the buffer table have helped avoid the TOO_MANY_LINKS error?
If you are fine with running lots of apps on one beefy machine, the project I am building https://github.com/openrundev/openrun provides a similar abstraction as App Runner and Cloud Run (automatically deploy web apps from source). It supports scaling down to zero, but does not yet scale an app beyond one container.
I have been building OpenRun, a declarative web app deployment platform https://github.com/openrundev/openrun. It is an open source alternative to Google Cloud Run and AWS App Runner, running on your own hardware.
OpenRun allows defining your web app configuration in a declarative config using Starlark (which is like a subset of Python). Setting up a full GitOps workflow is just one command:
openrun sync schedule --approve --promote github.com/openrundev/openrun/examples/utils.star
Any repo which has a Dockerfile can be deployed directly. For frameworks like Streamlit/Gradio/FastHTML/Shiny/Reflex/Flask/FastAPI, OpenRun supports zero-config deployments, there is no need to even have a Dockerfile. Domain based deployment is supported for all apps. Path based deployment is also supported for most frameworks, which makes DNS routing and certificate management easier.
OpenRun currently runs on a single machine with an embedded SQLite database or on multiple machines with an external Postgres database. I plan to support OpenRun as a service on top of Kubernetes, to support auto-scaling. OpenRun implements its own web server, instead of using Traefik/Nginx. That makes it possible to implement features like scaling down to zero and RBAC. The goal with OpenRun is to support declarative deployment for web apps while removing the complexity of maintaining multiple YAML config files. See https://github.com/openrundev/openrun/blob/main/examples/uti... for an example config, each app is just one or two lines of config.
OpenRun makes it easy to set up OAuth/OIDC/SAML based auth, with RBAC. See https://openrun.dev/docs/use-cases/ for a couple of use cases examples: sharing apps with family and sharing across a team. Outside of managed services, I have found it difficult to implement this type of RBAC with any other open source solution.
Any repo which has a Dockerfile can be deployed directly. For frameworks like Streamlit/Gradio/FastHTML/Shiny/Reflex/Flask/FastAPI, OpenRun supports zero-config deployments, there is no need to even have a Dockerfile. Domain based deployment is supported for all apps. Path based deployment is also supported for most frameworks, which makes DNS routing and certificate management easier.
I have been building an app deployment service https://github.com/openrundev/openrun.
For the use case of network routing for services running in containers, OpenRun provides a simpler abstraction. It does the container management and the network proxying.
Clace is built to run on a single machine without needing Kubernetes. The plan is to add support for Kubernetes hosting later, but running on one or a few machines should not required Kubernetes.
Clace is built for the use case of deploying internal tools, so it comes out of the box with CI/CD, auditing, OAuth etc. With Kubernetes, you need to glue together ArgoCD, an IDP etc to get the same.
A recent improvement in import map support in the browser https://shopify.engineering/resilient-import-maps
https://github.com/claceio/clace is project I am building which gives a Cloud Run type deployment experience on your own VMs. For each app, it supports scale down to zero containers (scaling up beyond one is being built).
The authorization and auditing features are designed for internal tools, any app can be deployed otherwise.
I have been building https://github.com/claceio/clace, an application server for deploying containerized apps. Docs are at https://clace.io/.
There are many deployment tools focussed on simplifying containerized apps deployment. Most of them are built as wrappers on top of Nginx/Traefik/Caddy etc. Clace is a single binary which implements a web server and an app server. This allows Clace to implement features like OAuth and atomic updates which are not possible for other solutions. Clace focuses on making it easy for teams to deploy Streamlit/Gradio/FastHTML type apps with no config required.
Clace has a imperative CLI and it has a declarative GitOps interface. For example https://github.com/claceio/clace/blob/main/examples/utils.st... is a config which defines seven apps. Using Starlark (pythonic syntax) allows easy config without the YAML insanity.
Running a command like
clace sync schedule --approve --promote github.com/claceio/clace/examples/utils.star
I have been building https://github.com/claceio/clace, an appserver for deploying containerized apps. Docs are at https://clace.io/.
There are many deployment tools focussed on simplifying containerized apps deployment. Most of them are built as wrappers on top of Nginx/Traefik/Caddy etc. Clace is a single binary which implements a web server and an app server. This allows Clace to implement features like OAuth and atomic updates which are not possible for other solutions. Clace focuses on making it easy for teams to deploy Streamlit/Gradio/FastHTML type apps with no config required.
Clace has a imperative CLI and it has a declarative GitOps interface. For example https://github.com/claceio/clace/blob/main/examples/utils.st... is a config which defines seven apps. Using Starlark (python like) for config allows easy config without the YAML insanity.
Running a command like
clace sync schedule --approve --promote github.com/claceio/clace/examples/utils.star
Starlark does allow for much more concise and powerful config specification. I am building https://github.com/claceio/clace, which is an application server for teams to deploy internal tools.
Clace uses Starlark for defining apps, instead of something like YAML. https://github.com/claceio/clace/blob/main/examples/utils.st... is a config file which defines around seven apps (apps are downloaded and deployed directly from git).
Clace uses Starlark for defining app level routing rules also. This avoids the need to use a nginx like DSL for routing.
Having a single process web/app server simplifies things operationally. I am building https://github.com/claceio/clace, which is an application server for teams to deploy internal tools. It runs as a single process, which implements the webserver (TLS certs management, request routing, OAuth etc) as well as an app server for deploying apps developed in any language (managing container lifecycle, app upgrades through GitOps etc).
Thanks. Clace is built for teams to be be able to deploy internal tools (Streamlit/Gradio etc). That use case requires some extra features (OAuth/Auditing/Declarative config etc). Kubernetes with ArgoCD plus IDP seems to have become the default solution, which is overkill for such use cases.
The Hypermedia based app support was added to be able to build a management dashboard for Clace itself, without going down the SPA route. It made sense to expose that for end uses to be able to build their own apps.
Another option you could consider is a tool I have been building for deploying webapps across a team. https://github.com/claceio/clace has the usual deployment related functionality like gitops, TLS certs.
It has some unique features like supporting OAuth authentication for the apps, staging env for each app (code and config changes are staged before deployment), supporting declarative update, supporting hypermedia based apps natively etc.
I have been building a platform [1] which makes it easy to deploy internal tools. Instead of taking the config file approach, it allows you to install each app at a unique location (domain name + url path). Within its location, the app owns all the URLs and can managing request routing without requiring a global config update.
The advantage is that new app installations cannot interfere with an existing app. I wrote more about this approach at https://clace.io/blog/webserver/