Apps and deployments

The app must exist first

An SDK cannot create an app by deploying to it. Create apps explicitly with POST /v1/apps, then connect each one to a repository. The app is also what decides a deployment's project — the caller never supplies a project when deploying.

id

Server-issued, prefixed app_.

project_id

The owning project. Set at creation and never moved.

name

1–120 characters, unique within the project.

created_at

Both timestamps are RFC 3339 with an explicit offset.

One deployment, one build

A deployment is one attempt at one commit, and a build is what came out of it. An attempt that failed has a failure and no build at all — deploy the commit again and you get a second deployment, not a second build under the first.

# every deployment for one app, newest first
curl -sS "$NEURUN_URL/v1/deployments?app_id=app_7QK2M0X4&limit=20" \
  -H "authorization: Bearer $NEURUN_KEY"

Runtime and entrypoint

runtime is python. It is a constant in the contract today rather than an open enum, so treat an unrecognised value as a server you do not understand rather than a runtime you can guess at. entrypoint defaults to main.py:handler and is normalized before storage.

Status mirrors the newest build

A deployment's status always reflects its newest build — uploaded before any build exists, then building, ready or failed. The invariant is enforced on every write, so you never have to reconcile the two yourself.

uploaded

Source fetched and stored, no build started yet.

building

The newest build is running.

ready

The newest build produced artifacts. Executions may pin to it.

failed

The newest build carries a failure code and message.

Deleting cascades