Runtime capabilities

The tables below list the current runtime capabilities of an application.

Publishing and deployment

Capability	Status	Notes
Worker → version → deployment	Supported	Creating a version does not put it live; a deployment does. Set `deploy: true` when creating the version to do both in one step
Rollback	Supported	Create a deployment for an older version again; no files are re-uploaded
Whole-site replacement	Supported	Each version's file manifest must list every file of the site; only files whose content changed are uploaded
Gradual rollout	Not supported	A deployment puts exactly one version at 100%
Retained versions	Limit	The latest 100 versions
Script size	Limit	10 MiB compressed
Deployment timeout	Limit	A deployment that does not finish within 10 minutes fails

Static assets

Capability	Status	Notes
Content-addressed deduplication	Supported	Identical content is stored once; republishing does not upload it again
Paths and size	Limit	Up to 100000 files per version, 25 MiB per file
`html_handling`	Supported	`auto-trailing-slash`, `force-trailing-slash`, `drop-trailing-slash` or `none`
`not_found_handling`	Supported	`none`, `404-page` or `single-page-application`
`_headers`	Supported	Applies only to static asset responses; up to 100 rules, 2000 characters per line
`_redirects`	Supported	Applies only to static asset responses; up to 2000 static and 100 dynamic rules, 1000 characters per line

_headers and _redirects do not apply to responses your Worker code generates. For cross-origin access, set the CORS headers in code:

const CORS = {
  "access-control-allow-origin": "*",
  "access-control-allow-methods": "GET, POST, OPTIONS",
  "access-control-allow-headers": "content-type",
};

export default {
  async fetch(request) {
    if (request.method === "OPTIONS") return new Response(null, { status: 204, headers: CORS });
    return Response.json({ ok: true }, { headers: CORS });
  },
};

Outbound requests

Capability	Status	Notes
Public addresses	Supported	`fetch()` in your code can request any public address
Other applications on the platform	Supported	Requesting another application's address returns that application's response

Bindings

Type	Status	Notes
`d1`	Supported	Declared when creating a version
`kv_namespace`	Supported	Declared when creating a version
`r2_bucket`	Supported	Declared when creating a version
`secret_text`	Supported	Declared when creating a version; the value is written through the secrets endpoint
`plain_text`	Supported	Declared when creating a version
`json`	Supported	Declared when creating a version
`praxis_token`	Supported	Enable platform API access as the owner organization; no token is injected
`praxis_vault_ref`	Unavailable	Cannot be used at the moment
Other types (such as `service`, `queue`, `durable_object_namespace`, `ai`)	Not supported	Creating a version returns `UNSUPPORTED`

Secrets

Capability	Status	Notes
Write a secret	Supported	`PUT /application/v1/workers/{id}/secrets/{name}`. The write derives a new version from the current one and deploys it
Read a secret value back	Not supported	Values are write-only; no endpoint returns them

Compatibility flags

Capability	Status	Notes
`compatibility_flags`	Supported	Pass them when creating a version; they take effect as given
`global_fetch_strictly_public`	Always on	Added to every version and cannot be turned off; passing `global_fetch_private_origin` or `no_global_fetch_strictly_public` returns 400

Calling platform APIs

Declare this binding in the version you deploy:

{ "type": "praxis_token", "name": "PRAXIS_API_TOKEN" }

Your application can call the Develop API without an API key:

export default {
  async fetch() {
    return fetch("https://api-develop.deepraxis.com/application/v1/workers");
  }
};

The application has the same organization access as an API key of its owner organization. Resources of other organizations return not found. No token or secret is exposed to application code, and env.PRAXIS_API_TOKEN is not created. Without the binding, protected platform endpoints return 401 unless you supply your own valid credential. Other destination hosts are unchanged.

The Praxis SDK uses the same outbound path: omit apiKey and use the Develop API as its baseUrl. No SDK change is required. Existing applications must deploy a version with the binding to enable access. Removing the binding takes effect after the deployment becomes active and the routing cache refreshes (up to 10 seconds).