ajayvk

I have been building https://github.com/openrundev/openrun. OpenRun allows you to build web apps, adding OIDC/SAML with RBAC to control who can access the apps. Supports MCP for app management. Also supports service bindings, which enables providing each app an isolated database account.

I have been building https://github.com/openrundev/openrun which makes auth (OIDC/SAML) with RBAC easy for self-hosted apps.

Great. The multi-player mode is also fun, that is what I play the most. You can create a challenge and send the link to friends or family. They can join and it keeps track of the leaderboard. Every player gets the same sequence of words.

I just made this 3 word challenge https://cowbull.co/challenge/6TQZ, try it

That comment was about what happens during an app deployment, to avoid multiple pods on Kubernetes from writing to the same volume. Multiple apps on one OpenRun have no issues, the replication will be identify them as different.

If by mistake you actually have two separate instances of OpenRun pointing to the same S3 volume and path_prefix (with single-node Docker or with Kubernetes), the generated S3 paths have an binding ID which should be unique across instances. I will check whether there is anything more which can be done to prevent any issues with such an incorrect config.

Not a company :-) OpenRun has been a passion project I have been building for last three years, trying to make declarative deployments easier

On Kubernetes, for apps using SQLite, maxReplicas is set to 1 and OpenRun uses the Recreate update strategy. This ensures at most one pod is active (requests are queued until the new pod is healthy). There should never be more than one pod accessing the SQLite database.

Without persistent volumes, every deployment of the app may require the SQLite data to be restored from S3, which can take time if database size is large. With PVC, regular app deployments use existing database, only a disaster recovery scenario restores from S3.

Yes, it feels magical to just recreate your namespace or even create a new K8s cluster and see all your apps (from OpenRun metadata) and app data restored automatically.

Built-in Litestream replication and automatic restore is a new feature I added in OpenRun (a self-hosted deployment platform for web apps). Apps can use SQLite with zero code changes while OpenRun handles backup/recovery. This works on a single node with Docker/Podman and also on Kubernetes.

Yes, OpenRun can deploy any containerized application and act like a proxy for the upstream application, no Starlark or any transformation in OpenRun. If the upstream container is serving JSON APIs, OpenRun can also be used to implement a Hypermedia based web app on top, using Go HTML templates and Starlark as the glue code.

The advantage is that you get the performance of Go while being able to hot reload applications and install new application dynamically without a process restart. I think of it as an application server for containerized applications.

Go backend with Starlark for dynamic behavior is a great combination. I have been building https://github.com/openrundev/openrun with that approach, mainly for teams to deploy internal tools. It can be used to deploy any containerized application. The management UI for OpenRun is built with the Hypermedia approach https://utils.demo.clace.io/console/

I’ve been working on making SQLite a first-class production option in OpenRun. OpenRun is a self-hosted deployment platform for web apps and internal tools which I have been building as a side project for last three years. Built-in Litestream replication and automatic restore is a new feature I added, so apps can use SQLite while OpenRun handles backup/recovery. This works on a single node with Docker/Podman and also on Kubernetes.

You define the S3 config once on the server, and every SQLite app gets continuous replication and automatic restore using Litestream. The app image stays unchanged. The server's own metadata is replicated too, through Litestream embedded as a Go library.

Custom agents can be added if it supports ACP, the console UI has the config options for that.

I have tested with GitHub and GitLab. OpenRun uses the go-git library, so BitBucket should work, not tried it yet.

FastHTML is great for internal tools use case.

The agent based app builder is pretty new, still improving it. It runs with Agent Client Protocol (ACP), with integrations for Claude Code, Codex CLI, OpenCode and Pi.

OpenRun runs on a single machine, with either Docker or Podman. All apps runs on that one machine. Idle apps are scaled down to zero, so resource usage is low even when hundreds of apps are installed. For scaling up, OpenRun can be deployed on Kubernetes. Each app deployed through OpenRun gets created as a Kubernetes deployment, again with scaling down to zero. Same declarative config moves from singe node to Kubernetes, no changes required.

I don't have any telemetry, so not sure about number of users. Based on issues filed, lots of users using the single node deployment (which is good enough for most use cases). Started with Streamlit/Gradio type apps, now users are actually using it for deploying vibe coded internal tools. See https://github.com/openrundev/openrun/issues?q=is%3Aissue%20...

There is too much friction in deploying internal tools. I have been building https://github.com/openrundev/openrun to solve that. Full GitOps (create/update your app through GitOps, not just updating app source code), staged deployments, service bindings (for getting a managed database credential, instead of creating a new database per app) and OIDC/SAML with RBAC.

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.