WORKER HOSTING

Your Worker.Its services, connected.

Deploy supported hand-written Workers from their wrangler config. Inspect the live bindings and reach the data behind each one.

Supported wrangler bindings. Move existing provider data separately.

launchboard / BindingsInteractive example

The resources behind env.

Live release · example inventory

KV NAMESPACE / CACHE
await env.CACHE.get("feature:checkout", "json");
Explore key-value

Choose a binding to follow its resource.

Example project · Your account stays unchanged

BUILT AROUND THE TASK

What this makes easier.

01

Bring the config

Deploy a supported hand-written wrangler Worker.

02

See the live bindings

Inspect resources, overrides and missing values.

03

Follow the connection

Reach KV, D1, buckets, email and timers in context.

THE DETAILS THAT MATTER

Know the flow.
Understand the boundaries.

Go deeper when you need the setup, operating behavior or recovery rules. The guide carries the complete reference.

Read the documentation
01Bring the configuration your Worker already uses.

A hand-written Worker is more than its fetch handler. It can read config values, serve assets, use a namespace, store objects or run on a timer. Fortly reads a supported wrangler.jsonc, wrangler.json or wrangler.toml file with a main entry and bundles that Worker with its pinned wrangler toolchain. The migration reference describes the exact path and the distinction from framework applications and Cloudflare Pages Functions.

The top-level configuration is deployed. Assets can be published with the release and exposed under the configured binding name. Config vars arrive on env, including structured JSON values. Secrets are stored separately in the console’s Variables workspace. A saved variable with the same name takes precedence over a config value, allowing an operational value to change without editing the repository.

This compatibility is specific. Fortly does not provision every Cloudflare product, copy account resources or execute arbitrary Docker containers. A successful JavaScript bundle is not enough to prove that a provider-specific application works. Review the declared services, data migration and runtime assumptions before switching a production hostname. Unsupported binding declarations stop the build with a named diagnostic rather than silently becoming empty objects.

02Inspect the services behind env.

Deployments includes a Bindings workspace for the live release. It shows the resources the Worker actually receives, not only a list copied from an undeployed config file. Assets, rate limiters, R2-compatible buckets, KV namespaces, D1 databases, Cron Triggers, outbound email, vars and expected secrets each have a recognizable kind and state. Missing secrets and overridden config values remain visible.

A namespace links to its exact Key-value view in Storage, where keys, metadata and expiry can be inspected. A bucket links to the matching Files folder, where the same objects are visible. A Cron Trigger leads to Schedules with its next run and outcome. An email binding leads to account setup and its actual allowed recipients. These connections reduce the gap between reading code that uses env.CACHE and finding the data it reads.

Bindings do not erase the differences between resources. KV is project-scoped with values up to 1 MiB. Bucket objects are limited to 64 MB and use public project file storage. Cron Triggers call scheduled(), while HTTP schedules request a path. Outbound mail requires a verified domain and confirmed destinations. The relevant feature guide explains the behavior your application must handle.

03Protect the path from first deploy to change.

The rate-limit binding supports limit({ key }) and returns a success result for a key within a fixed 10- or 60-second window. Use it for application-level admission checks where the documented semantics fit. It is not a reason to omit authentication or a substitute for a transactional counter. Your application chooses the key and decides what to return after refusal.

Configuration changes are published as releases. Follow the build, inspect the live binding inventory after publication and test the application’s important paths. A failed release leaves the previous live release serving. Updating a namespace declaration or bucket name does not migrate stored data into the new resource. Keep the old data and your migration procedure until you have verified the result.

A D1 binding is the project’s own PostgreSQL database in SQLite’s dialect, and its migrations folder is applied before each release goes live. Durable Objects, Queues, service bindings, Workflows and other unimplemented bindings remain outside the supported set. Incoming email handling is also unavailable; send_email is the outbound capability. The compatibility matrix lists each supported config field and difference. Treat that matrix as the deployment checklist, then use the console’s resource links, logs and activity to operate the Worker once it is live.

04Go from the feature to the working setup.

Open the detailed guide for configuration examples, access requirements, limits and troubleshooting. Then use your own project to verify the full flow before depending on it in production.

Check Worker compatibility · Explore the full platform

Before you build

A few useful answers.

Will every Cloudflare project run unchanged?

No. Supported hand-written Workers have a defined compatibility matrix. Pages Functions, provider-specific services and stored data can require a separate migration.

Do I keep my Cloudflare namespace ids and buckets?

The configuration maps to project-scoped Fortly resources. Existing Cloudflare data is not copied automatically.

Where are secrets configured?

Use project Variables with runtime scope when the Worker needs the value during requests. Do not commit secrets into vars.