Skip to content
Kodela

Demo real UI · synthetic data

Run it on your hardware
STEP 1 / 26

Auto-playing · click the demo to take over
kodela.example.test/portal/workspace/acme/demo-app synthetic
/acme/demo-app Running guarded acme/demo-app
runningacme/demo-apporxy V1.5.2

Synthetic data throughout: organisation acme, workspace demo-app, developer dev@example.test. Nothing on this page talks to a server; the agent, terminal and preview are scripted.

How a workspace connects

A workspace has no direct way out. Pick a request and follow it: each one passes an enforcer on the host, and each one lands in the audit.

One way outsynthetic
The workspace connects to GitHub only through the git broker, to the model provider only through the model proxy, and to everything else only through the egress proxy and firewall. Each enforcer writes to the audit log. Workspaceacme / demo-app Git broker Model proxy Egress proxyfirewall · DNS filter GitHub Model provider registry.example.test Audit log · hash-chained DENY

git push → Git broker. The broker holds the GitHub token; the workspace never sees it.

record → push, decision and authorship label.

Limits: the egress proxy decides by hostname; it does not terminate TLS or inspect payloads. Egress ships in observe, which logs what it would refuse and lets it through. The audit is tamper-evident on your host, not protected against host root. The full architecture

Recorded from the real app

The replica above follows the real screens. These are the screens themselves, captured from the app's offline harness.

Recorded from the Kodela app (orxy V1.5.2) on synthetic data. In the recordings, terminal and preview output is a scripted stand-in: the harness has no live container behind it.

Thirteen chapters

What each part of the tour shows. Open any chapter in the replica, or watch its recording.

  1. Sign in

    The Developer Portal. You sign in with the account your organisation invited, and land on Your workspaces: one card per workspace, with its state and owner. Your computers (new in orxy V1.5) lists a member’s own laptop or desktop hosting their workspaces; egress there is observed, not enforced, and only Windows has been tested end to end.

  2. The workspace

    One screen per workspace: a bar with its state, profile and Stop; a tab strip of shells, Start app, Preview and Git; a rail of panels and tabs; a status bar. The workspace has a Docker card (new in orxy V1.4–V1.5.1): the workspace’s Compose containers, their logs, and whether its agents may run Docker. Since orxy V1.7.1 it also has a Docker tab. Docker is off until your organisation allows it.

  3. Chat with the agent

    The Workspace Agent in five modes: Ask, Plan, Build, Run / Debug, Review / Test. A turn streams as rows: what it read, what it edited, what it wants to run.

  4. Approvals

    Commands wait for you. The card says what will run, where, with what timeout, output cap and network, and records Approve or Refuse. Keep these changes hands the result to Git.

  5. Start the app

    Library runs the start command in the App console. A checklist shows the approval, the console, the command and the preview; Preview :3000 then shows the app.

  6. Shell

    A terminal in the workspace container. In this demo it is scripted: a few commands answer, the rest tell you what to try.

  7. Files

    The project tree, a viewer, and a guarded editor with Edit, Save changes and Discard changes.

  8. Git and push

    Review changes, commit with a message, Validate, Push. The result names who made the tip commit: agent, human-console or unattributed.

  9. Pull requests

    Open and merged requests for the repository, their files and review comments, and an Open PR form.

  10. The gate refuses

    With the validation gate on (it is off by default), a commit that has not passed the organisation's checks is refused at the broker, with the sentence that says how to fix it.

  11. Logs and egress

    The App console, and every outbound request by host with its decision. A denied host offers a request to an administrator.

  12. Admin console

    Every workspace on the host, the Create workspace dialog, the Egress monitor, and the Audit log with its Authorship column.

  13. How it connects

    Git through the broker, model calls through the model proxy, everything else through the egress proxy and firewall, and all of it into the audit.

What this demo does not show

It is a replica on synthetic data. Here is where it stops.

  • No real network. Nothing on this page leaves your browser; the hosts, requests and decisions are synthetic.
  • No real model. The agent's turns are scripted. The model name is the one the real app shows; nothing here calls it.
  • A scripted terminal and preview. Here and in the recordings, shell output and the preview app are stand-ins.
  • Not every console page. Some admin pages are summarised in a sentence rather than recreated.
  • No IDE or streamed browser. The code-server tab and the headless-browser tab are described, not embedded.
  • acme's settings, not the defaults. Egress ships in observe and the validation gate is off; acme's admin turned both on.
  • The record's labels, not its proof. The authorship record is an HMAC on your host, verifiable there and not by third parties, and not yet seen on a live GitHub push.
  • Real timings. Delays here are staged; a real host's depend on its hardware.

Now run the real one

One host, your hardware, your repositories. Or talk to us about a pilot.