OpenRun: A Declarative GitOps Platform for Internal Tools on Docker or Kubernetes

The Problem OpenRun Solves

OpenRun targets teams that build internal tools and web apps and need a deployment platform that does not require a build server or manual CLI steps for every change. The README positions it as a GitOps platform: after initial setup, creating an app or updating its config is done by editing a config file in Git, and a background sync applies the changes. This is a direct answer to the pain of imperative deployment, where app creation and updates are manual, and only source code changes go through Git. The intended user is a platform engineer or a team that wants version-controlled, reproducible deployments for many small services, with built-in auth and database provisioning. OpenRun is not for deploying arbitrary multi-container stacks; it explicitly states it does not support apps requiring Docker Compose. Instead, it focuses on single-container web apps, with optional sidecars for workers.

How OpenRun Works: Declarative Config and Sync

The core mechanism is declarative app management. Apps are defined in config files in a Git repository, and the command `openrun sync schedule` sets up a background sync that creates and updates apps as config and code change. The README gives an example of a config file, `utils.star`, which is a couple of lines, contrasting with pages of Kubernetes YAML. This declarative approach means all changes are version controlled, and rollback is a matter of reverting a commit. The platform also supports imperative management via `openrun app create` and the management console UI, so you can mix modes. The architecture is a single binary that acts as a web server, not relying on an external web server like Nginx or Traefik. This design choice is what enables features like scale-to-zero for app containers, because OpenRun itself can proxy requests and wake up idle apps. It also simplifies deployment, as you run one binary on a server or point it at a Kubernetes cluster.

Getting OpenRun Running: Commands and Config

The README does not provide a full installation guide, but it points to a quick start at `openrun.dev/docs/quickstart/`. From the material, the key commands are `openrun sync schedule` for GitOps sync, and `openrun app create` and `openrun app update` for imperative management. The platform is a single binary, so running it on a server with Docker or Podman is the single-node path, or you can deploy to Kubernetes. The declarative config is written in Starlark, as seen in `utils.star`, which is a Python-like language. The README says each app is a couple of lines of config, but the exact schema is not shown in the provided material. For setup, you would likely need to run the binary, configure an OIDC or SAML provider for auth, and then define your first app in Git. The documentation site is the primary source for detailed setup steps, which are not reproduced here.

Unique Features: Service Bindings and Scale-to-Zero

Two features stand out in the README. First, service bindings provision isolated database accounts per app, supporting Postgres, MySQL, SQLite, and Redis, with more databases available through binding providers. This means each app gets its own credentials and database, which is a strong isolation model for internal tools. Second, OpenRun scales idle apps down to zero. Since OpenRun acts as the web server, it can intercept requests to an idle app, start the container, and proxy the request. This is a cost-saving feature for low-traffic internal tools. The README also mentions managed SQLite with continuous Litestream replication to S3 and automatic restore, which is a nice touch for apps that use SQLite as a primary store. These features are not common in simpler PaaS-like tools, and they are possible because OpenRun controls the entire request path.

Deployment Targets: Single-Node to Kubernetes

OpenRun can run on a single machine with Docker or Podman, or it can deploy apps to a Kubernetes cluster. The README claims that upgrading from single-node to Kubernetes requires no config changes. This is a significant promise, as it means the same declarative config works across both targets. The architecture likely abstracts the container runtime behind an interface, so the app spec is identical. However, the README does not detail how Kubernetes is used, such as whether it manages Deployments or uses raw pods. The advantage is that teams can start on a single server and move to Kubernetes as they grow, without rewriting their app definitions. This is a differentiator compared to tools like Coolify or Dokku, which are typically single-node only. The trade-off is that you are tied to OpenRun's abstraction, and if you need advanced Kubernetes features like custom resource definitions or network policies, you may hit limits.

Limitations and When It's the Wrong Tool

The most explicit limitation is the lack of support for Docker Compose or multi-container apps. If your internal tool requires multiple containers that need to communicate, OpenRun is not suitable. You can use sidecar containers for background workers, but the primary app must be a single web container. Another limitation is the dependency on AppSpecs for zero-config deployment of frameworks like Streamlit or Gradio. If your framework does not have an AppSpec, you must provide a Dockerfile. This means the zero-config promise only holds for a limited set of frameworks. Additionally, the README does not mention how OpenRun handles stateful apps beyond SQLite. For databases, it provisions isolated accounts, but the actual database server must be external, which adds operational overhead. Finally, scale-to-zero introduces latency when an idle app receives a request, as it must start the container. This is a trade-off for cost savings, and it may be unacceptable for latency-sensitive internal tools.

Alternatives and How They Differ

The README itself compares OpenRun to Coolify, Dokku, and CapRover. The key differences are that those tools are imperative for app creation and updates, while OpenRun is declarative. They also do not support Kubernetes deployment, whereas OpenRun does. Another alternative is Kubernetes itself, with tools like Helm or Kustomize for declarative config. However, Kubernetes requires writing pages of YAML, which OpenRun aims to avoid. A more direct alternative is something like Porter or Kubevela, but the README does not mention them. The practical difference is that OpenRun aims to provide a higher-level abstraction with built-in auth and database bindings, while Coolify and Dokku are simpler but less declarative. If you need Kubernetes support and declarative config, OpenRun is a candidate; if you are happy with a single node and manual CLI, Coolify might be simpler.

Maintenance, License, and Upgrade Costs

OpenRun is licensed under Apache-2.0, which is permissive and allows commercial use without copyleft obligations. The project is actively maintained, with recent releases including v0.19.2 in August 2026, indicating a steady release cadence. The README mentions a roadmap, but the details are not in the provided material. For maintenance, the platform is a single binary, which simplifies upgrades: you replace the binary. However, the declarative config and sync mechanism mean you must keep your Git repository and the OpenRun server in sync, and any changes to the config schema across versions could require migration. The documentation site is the source for upgrade notes, but they are not included here. The use of Litestream for SQLite backups adds a dependency on S3 storage, which is an operational cost. Overall, the maintenance burden is moderate, but the lack of multi-container support could force you to redesign apps if your needs grow beyond single containers.

Editorial conclusion

Adopt OpenRun if you manage many internal web apps and want Git-based declarative deployment with SSO and RBAC, especially if you plan to move from single-node to Kubernetes without rewriting config. Avoid it if your apps require Docker Compose or multi-container orchestration, as OpenRun only supports single-container apps with optional sidecars. Before adopting, verify that your target frameworks have an AppSpec or that you can provide a Dockerfile, and confirm that the scale-to-zero behavior works for your latency-sensitive workloads. Also, review the current state of the database binding providers for your specific database needs, as the README mentions only Postgres, MySQL, SQLite, and Redis out of the box.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes