Guides

Check before you deploy

Validate the manifest, preview what the deploy would apply, and run the app's checks after it lands — from the CLI or from a connected agent, without building anything twice.

A deploy that fails at the build is annoying. A deploy that succeeds and applies the wrong shape is worse — and the only thing that separates the two is checking what the deploy would do before it does it. Dibbla splits that check into three instruments, and this page is the order to use them in:

Validate the manifest — does it parse, and does it hold against the rules? The CLI can answer the schema-level half of that locally; the platform can answer all of it, including the parts that need your organization’s quotas.
Preview the deploy — given the manifest, what exactly would be applied? Services, ports, replicas, resources, what is public, what a profile skips. Nothing is built and nothing is applied.
Run the checks — after the deploy lands, prove the app does its job with the checks its manifest ships. Application checks are the instrument; this page is where they fit in the deploy flow.

The same rules, one authority

Local validation is a convenience: the CLI carries a copy of the schema rules and says so when a rule needs the server. The platform’s own deploy path is the authority — dibbla preview and the agent’s preview tool run the platform’s real parse, resolution and quota check, which is why their answer can differ from the local one in your favor’s direction: they know your organization’s limits.

From the CLI

$dibbla manifest validate
$dibbla preview
$dibbla deploy
$dibbla apps checks run my-app

dibbla manifest validate never contacts the server; it validates dibbla.yaml (and any dibbla-checks.yaml beside it) against the rules that do not need deploy-time context. dibbla preview uploads the archive the deploy would use and answers with the resolved result instead of a build: active services, skipped services and why, the public route, warnings and any findings — each finding a stable code, the path in the manifest, and a sentence. A preview with findings is an answer, not an error.

After the deploy, apps checks run polls the app’s checks to a terminal outcome and exits with a product code your pipeline can gate on: 0 pass, 8 fail, 9 error, 10 indeterminate, 12 canceled, 13 skipped because another run holds the app’s lease. The full ladder and the JSON contract are in the apps checks reference.

From an agent

A connected agent gets the same three instruments as tools, and the flow is the same: validate, preview, deploy, check. The scopes are read-class and separate from the deploy scope, so you can let an agent check its work before you let it publish — the checking tools cannot deploy, and the deploy tool cannot be reached through them.

For the pre-deploy half, request the preflight scope in the client’s MCP configuration — scopes = ["platform:deployments:preflight"] — and for the after-deploy half, the checks scopes: scopes = ["platform:checks:execute"] to run them and scopes = ["platform:checks:read"] to read them.

platform_deployment_preflight with depth: validate — send the whole dibbla.yaml as text plus the alias it would deploy as. The answer carries the same findings the CLI prints, plus the server-only rules (env-aware resolution, quota limits, multi-public detection), each with its code, path and detail.
platform_deployment_preflight with depth: preview — the same call, answered with the full resolved shape a deploy would apply: services, images, ports, replicas, resources, dependencies, what is public, what a profile skips. Read-only and annotated as such; nothing is built or applied, and the manifest’s own values are not echoed back.
Deploy with platform_deployment_start, then run the app’s checks with platform_app_run with kind: checks — it waits a bounded time (default 300s) for the terminal outcome and translates it: pass, fail (with the failing check and its reason), error, indeterminate, canceled, or skipped_concurrent when another run holds the lease. A failing check is a result, not a tool error — the agent asked exactly the question the failure answers. platform_app_checks shows what is defined and whether the nightly schedule is on; the same tool with view: history reads past runs newest-first, one check or all of them merged.

Exit codes do not cross the MCP boundary

The CLI’s numeric exit-code ladder is a terminal contract. Over MCP the outcomes arrive as words with their meaning beside them — the number 8 would be a thing to scrape, the word fail with its reason is a thing to act on.

When a check fails

The run tool names the failing check and carries its bounded summary — the reason, without secrets and without internal hostnames. To dig further, read the app’s logs for the window around the run, fix, redeploy, and run the checks again. If your organization routes check events to Slack or email, the failure lands there too (notifications).

An app in another organization is not visible from any of these tools, in either direction: it answers the same absence as an app that never existed.