About

What is OpenRun?

OpenRun (previously called Clace) is an Apache-2.0 licensed project building a web app development and deployment platform for internal tools. OpenRun is an open source alternative to Google Cloud Run and AWS App Runner. OpenRun is cross-platform (Linux/Windows/OSX) and provides a GitOps workflow for managing web apps.

Project Goals

The goal of this project is to make it easy for individuals and teams to develop and manage lightweight full stack applications in a secure manner. OpenRun aims to make it easy to install and manage secure self-hosted web applications with minimal operational overhead. Easy integrations to enable SSO/SAML based authentication and authorization controls, audit logs and integration with secrets manager for managing credentials are goals.

A single developer should be able to manage the full application lifecycle: frontend and backend development and production deployment. Deployments should support a GitOps approach, with automatic preview environment to verify changes before making them live. It should be easy, for the original developer or a new one, to make application code changes and deploy - after six months or after six years.

FAQ

How does OpenRun compare to other deployment solutions like Coolify/Dokku etc?

The main differences are:

  • OpenRun is declarative. After initial OpenRun setup. Instead of using CLI commands or UI operations, all operations including creating new app and updating config for existing apps can be doing by updating a config file in Git. With most other solution, app creation/update is through CLI or UI. Only app source code update can be done through Git.
  • OpenRun is implemented as a web server, it does not depend on external web server like Nginx/Traefik. This simplifies end-user usage and allows OpenRun to implement features like scale down to zero (for app containers) and OAuth/SAML/Cert based auth with RBAC.
  • OpenRun implements features like staged deployment and automatic dev env setup which are not available in other solutions.
Why is declarative configuration useful?

Imperative CLI or UI operation are easy to start with, but they make it difficult to track changes and rollback updates. With a declarative config, all changes are version controlled. It is easy to create a new environment, since everything is in Git. If multiple folks are making config changes in a team, declarative systems are easier to manage.

Declarative configuration is what makes Kubernetes and Terraform useful. OpenRun brings declarative configuration to web app deployment. Instead of writing pages of YAML, each app is specified as a couple of lines of Starlark (python-like) config. For example, see utils.star.

What types of apps can be deployed with OpenRun?

OpenRun can deploy any web app which runs in a single container. OpenRun supports AppSpecs which allow zero-config deployment of frameworks like Streamlit/Gradio/FastHTML/NiceGUI/Shiny/Reflex based apps. For frameworks which have a AppSpec, no Dockerfile is required, no code changes are required in the app source code. For frameworks which do not have an AppSpec defined, a Dockerfile needs to be present in the app source repo.

OpenRun does NOT support apps which require multiple containers using Docker Compose. The target use case is internal tools talking to existing API endpoints and web apps where the database is externally managed.

Does OpenRun support deployment of internal tools by teams?

Yes, deployment of internal tools by teams is a target use case. Features which are built for this use case include:

  • Declarative Config: Manage apps by declaratively in git, allowing team to do follow regular SDLC for config
  • OAuth/OIDC/SAML with RBAC: Manage who can access which app using RBAC
  • Audit Logs: All operations and API calls are automatically logged in audit trail
How is OpenRun deployed?

OpenRun can be deployed on a single node easily (Linux, Windows or OSX), using a SQLite database for storing metadata. Docker/Podman is the only dependency. OpenRun can be deployed across multiple machines, using an external Postgres database for storing metadata.

Support for Kubernetes based deployment is being implemented. On Kubernetes, OpenRun will avoid the need to setup a build system like Jenkins, CD with ArgoCD and an IDP like BackStage.

How is OpenRun implemented?

  • Single binary web application server (in golang), with a set of plugins built in (also in golang) which allow access to external endpoints. The server is statically configured using a TOML file.
  • Applications are configured using Starlark, which is a subset of Python. Python is an ideal glue language, Starlark is used to configure the application backend logic
  • Multiple applications can be dynamically installed, an embedded SQLite database is used to store application metadata (Postgres support is in the roadmap).
  • For applications using the container plugin, OpenRun works with Docker or Podman using CLI to build and run the containers.
  • Path based routing, each app identified by a unique path. Also, domain based routing, which allows multiple domains to point to the same OpenRun instance, with path based routing being done independently for each domain.
  • Automatic TLS certificate management for each domain to simplify deployments.
  • A sandboxing layer is implemented at the Starlark(python) to Golang boundary, allowing the implementation of security and access control policies. Go code is trusted, Starlark code is untrusted.
  • For Starlark based apps, the application UI is implemented using Go HTML templates, with HTMX for interactivity. Go templates support context aware templating which prevents encoding related security issues. They also work well with the HTML fragments required for HTMX.
  • No need to install any additional components like Python or NodeJS/NPM on the host machine. Integration with tailwindcss-cli is supported. esbuild (using the esbuild go library) is supported out of the box for importing ESM modules.

Current Status

The current status is:

  • Client and server (in a single binary) for service management and configuration.
  • Support for application development with Starlark based configuration.
  • Container management support with Docker and Podman
  • Auto-idling of containers to reduce resource usage
  • Go HTML template loading and caching for request processing.
  • HTTP plugin for communicating with REST endpoints.
  • Exec plugin for running system commands.
  • Built in admin account for local development.
  • Auto-sync (file system watcher) and Auto-reload using SSE (automatic UI refresh) for speeding up the application development cycle.
  • Admin functionality using unix domain sockets for security.
  • Application sandboxing checks to ensure only audited operations are allowed.
  • Staged deployment support, preview app creations support.
  • App data persistence to sqlite with managed tables.

Who is behind this project?

The project was started by Ajay Kidave. Ajay’s background has been in database systems and enterprise integration tools. OpenRun was started to find ways to reduce the development and operational complexity in tooling for internal applications.

How to stay in touch?