Bring the config
Deploy a supported hand-written wrangler Worker.
WORKER HOSTING
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.
Live release · example inventory
Example project · Your account stays unchanged
BUILT AROUND THE TASK
Deploy a supported hand-written wrangler Worker.
Inspect resources, overrides and missing values.
Reach KV, D1, buckets, email and timers in context.
THE DETAILS THAT MATTER
Go deeper when you need the setup, operating behavior or recovery rules. The guide carries the complete reference.
Read the documentationA 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.
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.
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.
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.
Before you build
No. Supported hand-written Workers have a defined compatibility matrix. Pages Functions, provider-specific services and stored data can require a separate migration.
The configuration maps to project-scoped Fortly resources. Existing Cloudflare data is not copied automatically.
Use project Variables with runtime scope when the Worker needs the value during requests. Do not commit secrets into vars.