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.
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.
It's classic HN to criticize OP that their solution doesn't scale, and then for OP to respond by saying that they don't need the scale and anyway PG tells you to do things that don't scale.
SQLite is great for small-production scale. Don't let anyone tell you different. Just keep in mind that it's a pain to move if you ever do need to scale up. If it's a startup, you might. If it's a weekend hobby project you're building for your personal use only, you probably won't.
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.
Do you have any mechanisms in place to prevent two separate instances of OpenRun that share the same configuration from corrupting their shared S3 Litestream store?
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.
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 was unfamiliar with this stack and had an AI conversation about it to figure out what it meant, if I'm correct (not likely), this openrun+Go stack has a PHP FastCGI analogy:
Your web app can be HTML templated pages, with HTMX client interactivity and server interactivity provided by ~~PHP~~ Starlark, which does not have full OS access, but only what ~~CGI~~ OpenRun exposes as possible functionality, all of which happens in-process and per web route.
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.
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.
Very interesting project! I haven't fully read through yet - does it deploy to existing resources/infra, or does it handle resource/compute provisioning as well? How are you handling keys/creds?
Do you have any real users yet?
I'm working on a open resource/compute provisioning protocol/system (not released yet), targeting both cloud platforms as well as internal, which may go hand-in-hand with what you're building.
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...
IMO you should evolve also as a central platform to host AND build internal tools (eg with agents). Have you considered that? EDIT oh snap I see in the console tour that there's an AI App Builder section. Ok gonna have to try this out then!
Also does your git integration support self-hosted Bitbucket (I guess at the least generic git instance not just GitHub etc) ?
Also, pretty cool that you have a FastHTML spec.. I built this (well AI mostly did) with FastHTML: https://hn-readtheroom.exe.xyz/
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.
Thanks! That's sounds excellent. I love the Shelley Web Agent ( https://GitHub.com/boldsoftware/Shelley ), but guessing it would be hard to integrate that into your platform (although would be amazing if you could).
