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