Output and errors

Channels and formats

deploy prints one final text report to stdout, containing its execution record followed by the state it could report. status prints the state and, if its read fails, an error block. service delete and volume delete print their outcome or the same error block, and ask their confirmation question on stderr. These reports are text; plan --json is the JSON output. Help and argument-parsing errors go to stderr and leave stdout empty. Deployment progress uses stderr. By default, a terminal with usable width gets a live display that clears when the run ends. UNIAC_PROGRESS=1 streams plain progress lines; UNIAC_PROGRESS=0 turns progress off. These settings affect stderr only, and progress display applies to deploy. link writes its listing, prompt and confirmation to stderr, including when deployment opens the picker. Other commands write results to stdout and errors to stderr. A failure to render a status report can also write stderr.

Plan output

The text preview names the local project and root directory, its optional description, and the digest of its complete generated description. It then shows shared image work under Building and named services under Deploying. Service rows include sources, declared public exposure, volumes and a declared replica count, grouped by package for a workspace. --full adds environment values, the start command, and the source definition’s name. plan --json emits {project, digest, deployable, declarations}. project contains root_dir, name, optional description, and packages with each package’s relative path. The root package is .. declarations associates each service with its package, its deployment declaration, which has the service’s name, and its from definition. deployable is the complete generated service description. Environment and start-command fields are included whether or not --full is supplied. Composition in YAML defines the generated description and what its digest identifies.

Deployment record

The root line names the local project. Its children report plan, link, build, push <service>, submit <service>, and observe <service>. They include the digest of the generated description, project slug, image count, pushed image digest and observed status when available. Displayed digests are shortened, and image references and digests appear in the record section. ✓ marks completion and ✗ marks failure. On failure, the root line carries an error code and the failed stage includes its retained progress and error message. An interruption is classified under the stage in flight, and a nonzero exit can still leave a report and project or service rows.

Per-service release outcomes

Each release block identifies the service, its package and its deployment declaration. It records whether the image was pushed, the submission outcome, returned deployment and task IDs, whether service state was read, and any failure phase or warnings.

Submission	Established fact
`not attempted`	No registration was initiated for this service.
`accepted`	The server acknowledged registration; observed state is reported separately.
`rejected`	Registration received an explicit client-error refusal.
`acceptance unconfirmed`	Registration was attempted without a conclusive response; the server may have accepted it.

Failures retain earlier receipts and identify later unattempted work. An image push, accepted request, or cancellation does not establish the state of the running service. Releasing again starts a new operation.

State rows

Service state is explained in Service observation, public addresses in Networking, and durable storage state in Volume lifecycle.

Row	Representation
`project`	The linked project’s name; deployment falls back to its slug.
`platform`	The platform API origin, shown only when it differs from production.
`root`	The resolved local project directory, included in deployment reports.
`service`	A service name, followed by `v<N>` when a serving version was read.
`status`	Reported status, followed by the `(observed/effective)` replica counts.
`kind`	Reported service kind, omitted when unavailable.
`lifecycle`	Reported serving-deployment phase, omitted when empty or `active`.
`deploying`	The in-flight task state and its current step when reported.
`replicas`	`<N> requested`, shown when the requested and effective counts differ.
`endpoint`	`<type> <address> → :<container-port>`; type and container port are omitted when unavailable.
Indented `volume`	`<name> at <mount-path>` on a service.
`hold`	A platform hold code.
`warning`	A platform warning or a CLI observation/recording warning.

The endpoint address is the complete address a client uses. A TCP address includes its allocated public port; the number after → is the container port. Columns align within each block, so their character offsets vary. Whole-project status lists services in name order and adds project volume blocks after them. Each volume block has its name, size in GB and state, including the holding service when available. deploy and single-service status show service mounts; whole-project status also lists unattached volumes.

Partial observations and warnings

HTTP 401 or 403 from the platform or project API fails the command. The following observation fallbacks apply to other errors. A failed service-detail read during whole-project status leaves that service’s name and summary status but omits its additional details. A failed volume read omits the volume section. Either can occur with exit 0. Missing rows therefore do not establish that the corresponding remote facts are absent. When deployment otherwise succeeds but its read of a service’s final state fails, it reports state unread as a warning. A failed local release-record write produces release record not written: <error>; the remote deployment remains in place. These warnings leave the exit code unchanged. A name-only service row means registration was accepted but service state was not read; it does not establish a running service. Rejected and unattempted submissions appear in release outcomes only. Platform warnings are passed through, including unresolved environment references.

Deletion output

A successful service delete prints its first line below, and the second for a volume the service held; a successful volume delete prints the third:

Deleted service <name> from project <project>.
Volume <volume> is detached and keeps its data; `uniac volume delete <volume>` destroys it.
Deleted volume <name> and its data from project <project>.

When the platform differs from production, on <platform-url> follows the project name. A failure prints the error block below.

Errors and exit codes

A status error block contains error <code>, a human-readable message and retryable yes when reported. Deployment puts the code on the root line and annotates a retryable failure there. retryable means the same operation may succeed without changes; error messages are explanatory prose. The following exit codes apply to deploy, status, service delete and volume delete:

Exit	Code	Condition
0	—	The command succeeded.
2	`usage`	Invalid invocation, a delete without `--silent` and without a terminal, or a typed name that does not match; nothing is deployed or deleted and no code is printed on stdout.
3	`auth`	No locally usable credential, or platform/project API HTTP 401.
4	`not_linked`	Missing binding after credential selection, project absent or mismatched with the binding, `UNIAC_PROJECT_URL` naming no project on the account, binding/platform conflict, or deployment’s picker found no projects.
5	`manifest`	Local project ownership, description validation or deployment-shape failure.
6	`build`	Docker daemon, image-pull or build failure.
7	`push`	Image upload failure.
8	`deploy_failed`	Deployment request/task failure, observation deadline expiry, a refused platform read, a delete the platform refuses (including a missing service or volume and a held volume), or a service deletion still running at the deadline.
9	`unreachable`	A platform request was classified as unreachable.
10	`pending`	Reserved.
70	`internal`	Unclassified failure.

These commands use the codes above. Some conditions use a code whose name describes only part of the cause:

status without a binding or target override exits 4 when a credential is available; without a usable credential it exits 3.
Deployment’s project picker reports unanswered-input failures as 70; no projects produces 4.
Missing build directories or Dockerfiles produce 5 during planning; Dockerfile or daemon failures during image work produce 6.
Platform/project API HTTP 401 produces 3; HTTP 403 during project checks, registration or observation produces 8. Docker registry credential rejection remains a push failure (7).
A deployment observation deadline produces 8 while the accepted work continues. After a successful first task read, later task-read failures fail the command using these classifications.
Project checks, status reads and deployment push/request operations classify transport errors and HTTP 502, 503, 504, 521, 522, 523 and 530 as unreachable (9). Other refused API reads, including HTTP 500, produce 8.

Other commands use 0 for success, 1 for command failure and 2 for invalid invocation. A description failure produces 1 under plan and 5 under deploy. Bare or unknown invocations exit 2; help and version exit 0.

Getting help

docs.uniac.ai is the current documentation; its index lists every page.
The Uniac Discord community is where people ask for help with a deployment.
support@uniac.ai handles account matters.

Joining the Discord or writing to support is the user’s action: a sign-in or deployment failure that the documentation does not resolve is reported to the user together with these places.

​Channels and formats

​Plan output

​Deployment record

​Per-service release outcomes

​State rows

​Partial observations and warnings

​Deletion output

​Errors and exit codes

​Getting help