Skip to content
📌 Provide isolated databases for apps with Service Bindings.

Console Tour

A visual tour of the OpenRun management console, in two parts. First the deploy flow: creating a database service with its connection url stored as a secret, binding an app to it, deploying a containerized app from a git repo, and the operational pages. Then the RBAC flow: enabling role based access control from the console and working with team-scoped grants. The screenshots follow the site theme - toggle light/dark to see the console in the other theme. A live demo of the console is available. See console install for installing the console on your own server.

Overview

The console home page shows the system at a glance: apps, syncs, containers, services and recent activity. Every tile links into its area page.

Overview home page before the flow Overview home page before the flow

Create a service

Services are named backing resources (Postgres, MySQL) that apps connect to through bindings. The lock button encrypts the connection url into the secrets store; the service config keeps only the secret reference, so credentials never appear in config listings.

New service form with the connection url stored as a secret New service form with the connection url stored as a secret

The created service shows on the bindings page with its config keys - the values stay server-side.

Bindings page listing the postgres service Bindings page listing the postgres service

Create a binding

A binding gives apps access to a service. Creating it provisions a dedicated account (role and schema) on the database, so each binding is isolated.

New binding form sourced from the postgres service New binding form sourced from the postgres service Bindings page with the service and the base binding Bindings page with the service and the base binding

Deploy an app

Apps deploy straight from a git repo (or a server directory). The spec dropdown picks the app type for sources without an app.star, parameters are passed as key/value pairs (lockable into the secrets store), and the service bindings dropdown attaches the binding - the app’s container gets the database credentials as environment variables.

New app form with spec, params and the binding selected New app form with spec, params and the binding selected

Validate does a dry run: the source is fetched and checked, and the permissions the app will request are listed for review before anything is created.

App create form after a successful validate dry run App create form after a successful validate dry run

After create, the app is live with a staging environment alongside prod.

Apps page with the deployed app Apps page with the deployed app

The app detail page shows versions for prod and staging, the approved permissions, and links to open the running app.

App detail page with versions and permissions App detail page with versions and permissions

Operate

Containers for the deployed apps, with lifecycle actions, stats and logs:

Containers page with the app's prod and staging containers Containers page with the app's prod and staging containers

Every operation is audit logged, filterable by app, operation and status:

Audit page with the operations from this flow Audit page with the operations from this flow

Declarative GitOps sources keep apps synced from a repo on a schedule:

Syncs page with declarative sources Syncs page with declarative sources

The AI app builder creates apps from a prompt in an agent session:

App builder page App builder page

Server configuration - auth, git, secrets, RBAC and system settings - is editable from the console, with staged versions and history:

Configuration page Configuration page

Back on the overview, the deployed app shows in the apps tile and its running container is counted in the containers tile:

Overview home page after the flow Overview home page after the flow

Role based access control

The second flow enables RBAC from the console and walks a multi-team setup: eng and finance teams with builtin-auth users, developers scoped to their team’s paths, read-only users, and an operations group covering everything. Everything below is driven through the console UI.

Configure and publish

Without RBAC configured, every management call is admin-only:

RBAC configuration page before any groups, roles or grants RBAC configuration page before any groups, roles or grants

Groups, grants and the enable flag are staged as a draft: team developers get the openrun-developer role scoped to their team paths, domains, services and binding namespace; read-only users get openrun-user on the team apps; the ops group gets openrun-operator on all targets.

RBAC configuration with all grants staged as a draft RBAC configuration with all grants staged as a draft

Publishing makes the draft live server-wide, effective immediately - no restarts:

Published RBAC configuration with the grants live Published RBAC configuration with the grants live

Team setup

The operator creates the database services - a shared one plus one per team, each on its own database. The all-target grant shows every service:

Operator creating the shared postgres service Operator creating the shared postgres service All services visible to the operator All services visible to the operator

Scoped development

Grants are enforced per resource at action time. A developer can reach the create form (they hold app:create somewhere), but creating an app outside the team scope is denied:

App create denied for a path outside the team scope App create denied for a path outside the team scope

Inside the scope, the developer creates the team’s todo app bound to the team service - binding attach is authorized by service:bind on that service:

Apps page after the eng developer created the team todo app Apps page after the eng developer created the team todo app

Developers can derive restricted bindings from a base binding - here a read-only view with per-table grants - and build apps on them. The binding dropdown lists only services and bindings the caller can read; other teams’ entries never appear:

Deriving a read-only binding from the team base binding Deriving a read-only binding from the team base binding Creating an app on the derived read-only binding Creating an app on the derived read-only binding

Domain glob targets authorize apps on team subdomains too:

Domain app created through the team domain glob target Domain app created through the team domain glob target

The other team works the same way in its own scope:

Finance developer creating an app on their derived binding Finance developer creating an app on their derived binding

Every list is filtered server-side to what the caller can read - a developer’s bindings page shows the team and shared entries only:

Bindings page filtered to the eng team's entries Bindings page filtered to the eng team's entries

Read-only users and operators

A read-only user sees the team apps, with every write control disabled and labeled with the missing permission; nav areas without a read permission are disabled too:

Read-only user with disabled write controls and nav items Read-only user with disabled write controls and nav items

The operator’s all-target grant sees everything, plus approve/promote and the configuration pages:

Operator view with every app, service and binding visible Operator view with every app, service and binding visible

Per-resource denials and staged updates

Write attempts outside the granted targets - a service outside the team’s namespace, a binding outside the team prefix, a binding sourced from another team’s service - are each denied per resource, with the form re-rendered in place:

Scoped write denial re-rendered inline on the binding form Scoped write denial re-rendered inline on the binding form

Updates always apply to staging first; promoting to prod is a separate permission. The read-only user sees the pending promotion but a disabled Promote action:

Staged param update promoted to prod by the developer Staged param update promoted to prod by the developer

Dynamic grant changes

Grant changes publish without restarts. The operator loans the eng developer to finance - the finance apps, service and bindings appear on their next request:

Loan grant published by the operator Loan grant published by the operator Eng developer seeing the finance resources during the loan Eng developer seeing the finance resources during the loan

Deleting the loan grant reverts the access just as immediately - the finance apps drop out of the lists and their URLs 403 again:

Access back to the team baseline after the loan grant is deleted Access back to the team baseline after the loan grant is deleted