Skip to main content
Build and run web apps, websites, agents, databases and background workers on Uniac, the cloud platform for AI agents.

Accounts, projects, and applications

An account can own multiple projects. Each project is a deployment destination with its own services, volumes, and private network. Project names are unique within an account; the platform also assigns each project a slug. An application is made up of resources that run together in a target project. Its local description belongs to one project root with one remote project binding. A standalone description can contain one or several services. A workspace combines descriptions from included package directories under the same owner and destination. The workspace’s optional name describes the local system, and the project binding selects the remote project.

Services and communication

A project runs an application’s services as containers on a private network, with public HTTP and TCP endpoints and persistent volumes. Services represent the application’s microservices. Each service has an identity within its project, which other services address on the private network. Each running copy, or replica, is a container running the application’s OCI image. The service identity stays the same as its replicas change. A public endpoint allows clients outside the project to reach a service. A stateless service can run multiple interchangeable replicas behind that identity. Connections may reach different replicas, and each replica keeps its own memory and local files. Services that need shared or persistent state communicate with the component holding it.

Singleton services and volumes

A singleton service runs at most one replica at a time: during replacement, the previous replica stops before its successor starts, which gives the service’s volume a single writer. Both service kinds keep their network identity across replacement. A volume supplies durable storage that survives replacement of the container using it. A singleton service can attach a volume, and data that must outlive a replica is written to its mount. The volume has its own identity and lifetime within the project, and its data stays when it is detached or its service is deleted. For example, an application can have a stateless API and a singleton database. The API’s replicas reach the database through its service identity; the database’s replica stores persistent data on its volume. Public clients need an endpoint for the API, while the database can remain private.

Project lifetime

The project keeps its services running independently of the application description: a service stays until it is deleted, including after its declaration leaves the description. The dashboard opens an account’s projects and their services without a local application description. A project’s Settings offers Delete project, confirmed by typing its name. Deletion destroys its services, endpoints, and every volume and its data, including detached volumes.

Describing the application

A composition describes the resources making up an application and how they connect. A service definition supplies reusable image and runtime configuration. A deployment declaration instantiates one definition as a service in a target project, and the declaration’s name is the service’s name. A service runs once a declaration instantiates its definition, and several declarations can instantiate the same definition. Deploying the project creates or updates the service of every deployment declaration in its packages. Each service runs the replicas its execution type allows. A package is a directory containing a description. Each package keeps its own resource and reference scope: workspace inclusion combines the packages’ deployments, and each package’s definitions and environment references stay within that package. Service names are unique across the project. Composition in YAML introduces the description file and combines these parts in an example. Detailed configuration and lifecycle information is available for Service and Volume.