Projects and secrets

You do not have to call this before deploying

A deploy registers the project it names, so the CLI and a CI job can skip this. What it adds is a name, a display name and a repository to show before the first build has run.

Any member may create one, and the name is checked here

No admin role is needed. The slug follows the same rule elan.yaml is validated against — it becomes a Kubernetes namespace and an image path — so a name the spec would refuse is refused now rather than at the end of a build. A credential scoped to one project is not stopped from creating another.

A project nobody registered still appears

One that exists only because something was deployed to it is listed with registered: false, so the list is the index of everything rather than of what somebody typed into a form.

The whole tenant, whatever the credential

A credential scoped to one project still lists every project.

Refused while anything is still deployed

Removing the record of a project whose agents are running would leave workloads, a database and an egress port that nothing claims. Destroy the project first, then remove it.

digest is per agent, and agents move independently

A deploy moves only the targets it changed, so two agents of one project can be running different images. This is the answer to "what is my agent running", one row per agent.

manifest is a summary, and absent means not recorded

kind says agent or workflow; input_names lists a workflow's declared inputs by name (their types and defaults are in your own manifest); billing, limits and tools are what the agent declared. An agent last deployed before a field was recorded simply lacks it — read that as unknown, not as "declares nothing".

workload is the pod it runs in

Its own slug for an isolated agent; its group's name for agents that share a pod, restart together and scale as one.

project is required, and that is not pedantry

Agent slugs are unique within a project, not within a tenant, so two projects may each have a worker. Leaving project out is a 422 rather than a guess.

Type the name back

confirm must equal the agent's slug, or nothing happens and you get a 409. The workload leaves the cluster first and its dependencies go second, so nothing restarts against a database that no longer exists. A database is snapshotted before it is dropped. The image is left alone: the agent's siblings are running it.

A grouped agent leaves the shared database behind

Agents that share a pod share its database, which outlives every member but the last. The response names them in kept_for, so "destroyed" does not read as "all of it gone".

The project is a query parameter, so a scoped credential's claim is not checked

Unlike destroying a project, this route checks the tenant and the admin role and not which project the credential was issued for.

The same teardown as one agent, for all of them

confirm must equal the project's slug. The response has the same shape, and re-running is safe. Removing the project's registration afterwards is a separate call.

unprovisioned is the one to read first

An agent that is running and has no invoke topic recorded: its pod is healthy, the console shows it, and every invocation goes nowhere. Redeploying the project finishes provisioning it.

Ghosts, not orphans

A ghost is a resource the record lists and the cloud no longer has. Something that exists with no record cannot be found by asking the record, so it is not reported here. unknown is what could not be checked at all.

Two kinds, and elan.yaml decides where each lands

llm is a model provider key, referenced from llm.keys. secrets is anything else, referenced from a target's secrets: list and read from the environment inside the pod.

A running pod keeps the value it started with

Setting a new value is not live until something replaces the pod — the next deploy that moves it, or a restart.

Tenant-wide, and no admin role needed

Secrets belong to the tenant, not to a project, and any credential in the tenant can set one — including a service user issued for a single project without Can write.

Only what was set through this API

The list is the platform's own record of what it stored, so a value written into the secret store some other way works and is not listed.

The failure it causes is delayed

A pod already running keeps the value it read at startup, so nothing breaks at once — and then the next restart does not start at all, because there is nothing left to fetch. Remove the reference from elan.yaml and deploy before deleting a secret something uses.

Send the manifests to get the crosscheck

With spec_yaml alone only the file is checked: that it parses and that its tenant is yours. With manifests — what your agents export about themselves — it is also checked against them, which is where most refusals come from: a target declared with no agent behind it, a secret referenced and never declared.

Every problem, not the first

An empty problems means a deploy would be accepted. A non-empty one lists all of them, each with where and message, so one round of fixes is enough.