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.

Super cool project!

If you ever get this working for Kubernetes, I'd love to add it to https://canine.sh for a one click deploy, been looking for something like this.

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

This will set up a scheduled sync, which will look for new apps in the config and create them. It will also apply any config updates on existing apps and reload apps with the latest source code. After this, no further CLI operations are required, all updates are done declaratively. For containerized apps, OpenRun will directly talk to Docker/Podman to manage the container build and startup. There are lots of tools which simplify web app deployment. Most of them use a UI driven approach or an imperative CLI approach. That makes it difficult to recreate an environment. Managing these tools when multiple people need to coordinate changes is also difficult.

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.

A recent improvement in import map support in the browser https://shopify.engineering/resilient-import-maps

The interesting bit is this: https://philipwalton.com/articles/cascading-cache-invalidati... Without that one sentence, the entire article is moot because I thought bundlers solved the problem.

I haven't thought about that in years. I didn't realize it had been solved.

Browser support looks pretty good.

I guess now I have to figure out how to get this to play nice with Vite and TypeScript module resolution.... and now it's starting to hurt my brain again, great.