Deployment

When you’re ready to share your app with the world (or your team), you’ll deploy it to Cloudflare Workers via the deco CLI. Deployment in deco is remarkably simple compared to traditional apps – since your entire stack is serverless and lives at Cloudflare’s edge, going to production is often just one command.

On the default template, all it takes is to run npm run deploy at the root of your project.

Build and Deploy Process

1. Build the frontend

The npm run deploy script will typically run npm run build in the /view directory to produce optimized static files (if you have a frontend). This yields an dist/ or build/ folder with your HTML, JS, CSS assets ready for production.

2. Building the worker and uploading view assets

After building the view, the deploy script triggers the Cloudflare Workers build. Under the hood this will call wrangler build or use the deco CLI’s deployment API directly with Typescript. It takes your server/main.ts (and bundled dependencies) and uploads it to Cloudflare, along with the static assets (which get uploaded to Workers KV or as an asset bundle). The wrangler.toml is used to identify your project and bindings configuration.

This will require that you’re locally authenticated (you can always run npx deco-cli login ) on your own machine; But can also be done by passing in an API token with permission to access the HOSTING_APP_DEPLOY resource on your project, often useful for running automated CI/CD deployment.

The api token can be specified on the deco deploy -t argument.

When deco deploy finishes, your app will be live at a URL, likely something like https://<app-name>.deco.page . The CLI or output will show the deployed address.

Cloudflare Workers Runtime Notes

• Your code runs on Cloudflare’s global edge network. It means low latency access for users around the world and automatic scaling.

• If your workflows or tools do heavy computation or wait on external APIs, that’s okay – just be mindful to use asynchronous waits properly (which you likely are, since most I/O is via await calls). Cloudflare will suspend the worker during fetch waits so it doesn’t count against CPU time heavily.

Custom Domains

Guide Coming Soon

Post-Deploy Testing

Always test your deployed agent as a user would:

• Open the production URL, ensure the frontend loads.
• Try interacting with the agent (the Worker should be live and responding).
• Check that integrations (which might have different credentials in prod) work as expected.

Rollbacks and Updates

If something goes wrong, you can update your code and deploy again. We doen’t have a built-in version rollback via CLI, but since deployments are fast, you can re-deploy an earlier stable version of your code. It’s wise to use version control (git) for your project so you can revert changes locally and redeploy.