Comments URL: https://news.ycombinator.com/item?id=47770182

Points: 4

# Comments: 3

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.

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.

There are many tools which try to simplify application deployments, but not many support declarative deployments. Even if app sources are fetched from git, creating new apps or updating app config requires imperative commands. Kubernetes is the dominant declarative approach, but it takes too much YAML to manage an app with Kubernetes. OpenRun supports a limited use case, deploying web apps for internal users across a team. For that use case, it supports declarative deployments on top of Docker/Podman or Kubernetes, with a very simple config.

Some of the unique features of OpenRun are:

- All apps have a staging env, code and config changes are staged before being promoted to prod

- Supports OIDC/SAML integration, allowing you to control access to apps using RBAC policies

- Full solution which handles builds, CD and request routing. Does not require additional tooling like Jenkins/ArgoCD etc

OpenRun can run on a single machine, in which case it directly deploys the container to Docker/Podman. When deployed to Kubernetes, OpenRun builds the images using Kaniko and deploys apps as a Kubernetes deployment, using server side apply to make updates.

The whole Starlark based config for creating apps is just:

    app(path="/streamlit/uber", source="github.com/streamlit/demo-uber-nyc-pickups",
        spec="python-streamlit") # python-streamlit knows how route requests for Streamlit
    app(path="/myapp", source="github.com/example/example",
        spec="container") # container spec works for any app which has a Dockerfile

Comments URL: https://news.ycombinator.com/item?id=46965662

Points: 21

# Comments: 0

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.

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.

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.

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.

Comments URL: https://news.ycombinator.com/item?id=45621063

Points: 2

# Comments: 1

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.

Comments URL: https://news.ycombinator.com/item?id=45609363

Points: 4

# Comments: 1

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.

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

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.

Kubernetes is the standard for declarative deployment. OpenRun supports only web apps, there is no plan to add support for deploying databases or queues etc with OpenRun. That makes OpenRun much simpler, a single binary which implements the web server and application server with GitOps driven deployments. Deploying and managing stateful database type services is much more complex. Declarative web app deployment is much easier.

The goal with OpenRun is to support declarative deployment for the 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 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.

OpenRun makes it easy to set up OAuth/OIDC/SAML based auth, with RBAC. This makes it possible to share your apps securely, see https://openrun.dev/docs/use-cases/ for a couple of such use cases. Outside of managed services, I have found it difficult to implement this type of RBAC with any other open source solution.

Comments URL: https://news.ycombinator.com/item?id=45550188

Points: 3

# Comments: 2

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 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.