---
title: "Update and redeploy a function"
method: PUT
path: "/functions/{id}"
tags: ["Functions"]
---

# Update and redeploy a function

`PUT /functions/{id}`

Replaces the function's source code with the body's `code` and
triggers a redeploy. Same size limits as `POST /functions`.
Use this verb to push secret writes into the running handler:
passing the same `code` re-runs the deploy and refreshes the
binding set with the latest values from the secrets table.

On deploy failure, the previously-deployed code stays live; the
runtime never serves a half-built bundle. The response uses
`error.code` `deploy_failed`, and the function's `deploy_error`
field carries the latest deploy error for dashboard/API reads.

## Request body

- object
  - `code` string — New pre-built handler. Same rules as CreateFunctionInput.code. Provide either `code` or `files`, not both.
  - `sourceMap` string
  - `files` object — Source files for a managed build, as a map of path to file contents. Provide this INSTEAD of `code` to rebuild and redeploy from source. Same rules as CreateFunctionInput.files.
  - `managedRelease` object — Strict exact-redeploy claim for a prepared managed-agent Function. Valid only with `code` and an unscoped organization API key. The uploaded code must match the prepared release runtime bundle exactly.
    - `releaseId` string, uuid, required — Prepared managed-agent release UUID.
    - `expectedManifestHash` string, required — Exact lowercase SHA-256 manifest hash returned by release preparation.

## Response `200`

Updated function

- object
  - `success` true, required
  - `data` object, required — Full function record returned by GET / PUT.
    - `id` string, uuid, required
    - `name` string, required
    - `code` string, required — The bundled handler source. UTF-8 string up to 1 MiB. The same value most recently passed as `code` to POST or PUT.
    - `deploy_status` 'pending' | 'deployed' | 'failed', required — Lifecycle state of the latest deploy attempt: * `pending` — deploy in flight; the runtime has not yet confirmed the new bundle is live. * `deployed` — the running edge handler is the latest code. * `failed` — the most recent deploy attempt failed; the previously-live code (if any) is still running. The `deploy_error` field carries the error message.
    - `deploy_error` string, nullable — Error message from the most recent failed deploy, or null after a successful deploy. Surface this to users to explain a `failed` status without polling.
    - `deployed_at` string, date-time, nullable
    - `created_at` string, date-time, required
    - `updated_at` string, date-time, required

## Other responses

- `400` — Invalid request parameters
- `401` — Invalid or missing API key
- `404` — Resource not found
- `424` — The operation depends on another service or step that failed.
- `429` — Rate limit exceeded
- `503` — Primitive is temporarily unable to process the request

## Changes

- **2026-07-26** `c2299d28022c` — 1 info
  - added the new optional request property `managedRelease`

[Change history](https://skmtc.dev/primitive/apis/primitive-api/changes/functions/:id/put.md)

---

[API](https://skmtc.dev/primitive/apis/primitive-api.md) · [All operations](https://skmtc.dev/primitive/apis/primitive-api/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/primitive/primitive-api/revisions/c2299d28022c/schema)