ajayvk

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.

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.