UCloud logo UCloud logo UCloud
v2025.1.0
  1. UCloud/Core
  2. 1. Introduction
  3. 2. Projects
  4. 3. Accounting
  5. 4. Orchestration
  6. UCloud/IM for Slurm-based HPC
  7. 5. Installation
  8. 6. Architecture and Networking
  9. 7. User and Project Management
  10. 8. Filesystem Integration
    1. 8.1. Inter-provider file transfers
  11. 9. Slurm Integration
    1. 9.1. Application Management
    2. 9.2. Built-in Applications
  12. 10. Reference
    1. 10.1. Configuration
    2. 10.2. CLI
  13. 11. Appendix
    1. 11.1. Built-in Application Index
  14. UCloud/IM for Kubernetes
  15. 12. Installation
  16. 13. Architecture and Networking
  17. 14. Filesystem Integration
  18. 15. Compute Jobs
    1. 15.1. Public Links
    2. 15.2. Public IPs
    3. 15.3. License Servers
    4. 15.4. SSH Servers
  19. 16. Integrated applications
    1. 16.1. Syncthing
    2. 16.2. Integrated terminal
  20. 17. UCX applications
    1. 17.1. Hello world
    2. 17.2. Data binding
    3. 17.3. UI events
    4. 17.4. Component reference
    5. 17.5. API reference
  21. 18. Reference
    1. 18.1. Configuration
    2. 18.2. CLI
  22. H: Procedures
  23. 19. H: Procedures
  24. 20. H: Introduction
  25. 21. H: Auditing
  26. 22. H: Auditing scenario
  27. 23. H: GitHub actions
  28. 24. H: Deployment
  29. 25. H: 3rd party dependencies (risk assesment)
  1. Links
  2. Source Code
  3. Releases

UCX applications

UCX is a backend-driven UI and orchestration layer used for building advanced UCloud application flows. It is useful when a plain static application definition is not enough, for example when a workflow needs to:

  • create multiple resources as one logical stack,
  • react to user input in real time,
  • attach links/networks/IPs/jobs dynamically,
  • and keep a custom UI synchronized with backend state.

UCX can be used in two main modes:

  • Custom application creation: You provide a full UCX application that controls the entire creation process of an application. This replaces the normal YAML driven application development flow with a UCX one instead. The application YAML will simply refer to the container hosting the UCX application.
  • Inside a running job: You expose UCX-powered controls from an existing workload to customize job behavior while it runs.

This is typically needed for advanced stacks such as managed Kubernetes control planes and other multi-resource services.

Mental model

A UCX application is a Go type implementing ucx.Application:

  • UserInterface() returns a UI tree (ucx.UiNode).
  • exported struct fields are the model state sent to the frontend.
  • OnMessage(...) handles incoming model input and unhandled UI events.
  • Session() gives access to RPC calls (ucxapi) and helper services (ucxsvc).

At runtime:

  1. ucx.AppServe(factory) accepts a session.
  2. frontend sends SysHello.
  3. backend sends UI mount + current model.
  4. user interaction generates model input or UI events.
  5. backend updates state and streams model patches.

Recommended structure

For provider implementations, this structure works well:

  • Keep UI logic in UserInterface().
  • Keep validation and state transitions in OnMessage(...) and event handlers.
  • Use ucxsvc for stack/resource helpers.
  • Use direct ucxapi calls for functionality not covered by ucxsvc.
Previous Integrated terminal
Next Hello world