When you drag a Frontend, a Backend and a Database onto the LineXa canvas and wire them together, a lot has to happen before anything runs in the cloud: container images, services, a managed database, networking, certificates. We did not want any of that to be hidden magic, and we did not want it tied to the canvas itself. So everything goes through one intermediate format: the Universal Project Model, or UPM.
What the UPM describes
The UPM describes your application the way a developer thinks about it, not the way a cloud provider configures it:
- The project: its name, region, environment and branch.
- Each component: its type (frontend, backend, database, cache, cron job, firewall), its language or engine and version, the repository that holds its code, and how it should scale.
- What depends on what, taken straight from the connections you draw.
There are no IAM bindings, subnets or provider-specific resource names in it. Those are decisions LineXa makes for you when it compiles the model.
Why an intermediate model
- It is readable. You can look at the UPM of a project and understand the architecture in a minute.
- It can be validated. Before anything is generated, the server checks the model, so a malformed canvas is rejected early instead of failing halfway through a deploy.
- It separates what from how. The canvas only has to produce a correct model, and the deploy engine only has to turn a model into infrastructure. Each side can evolve on its own.
From model to real infrastructure
When you deploy, LineXa compiles the UPM into real Terraform and Dockerfiles, one isolated set per environment, and streams the actual output to the studio's terminal. Nothing is simulated: what you see scrolling past is the real apply.
The How it works page walks through the whole pipeline step by step.