Deploy to Cloudflare

The guided installer at discoflare.com/deploy provisions Discoflare directly into your Cloudflare account. It uses a temporary OAuth session for provisioning; the installed Worker does not retain the Cloudflare access token.

Before you begin

You need:

• a Cloudflare account with Workers Paid enabled;
• an active DNS zone in that account;
• an unused application hostname, such as chat.example.com;
• an email address for the first workspace owner; and
• an unused email subdomain if you want workspace mail.

The installer stops instead of replacing a hostname attached to another Worker, non-Cloudflare MX records, or another enabled catch-all email route.

1. Connect the account

Open Deploy Discoflare, select Connect Cloudflare, approve the requested permissions, and return to the installer.

The OAuth consent includes email-routing and email-sending permissions because the workspace-email choice is made after account discovery. Turning Workspace email off prevents the installer from using those permissions or changing email configuration, but it does not narrow the already-approved OAuth scope.

Select the account and active domain that will own the workspace.

2. Describe the workspace

Choose:

• a Worker name;
• the public workspace name;
• the application subdomain;
• whether to enable workspace email and, if enabled, its subdomain and first mailbox;
• invite-only or open registration; and
• the first owner's email address.

These choices become deployment configuration. They are not inferred from the marketing site repository.

3. Install

Select Install or update. The installer loads a pinned Discoflare release, provisions its bindings, enables the selected email routing, deploys the Worker, attaches the hostname, and returns a private owner-setup link.

4. Check platform readiness

Before creating the owner, open the health endpoint on the workspace origin:

curl -fsS https://chat.example.com/api/setup/health

For a fresh guided installation, the response should include:

{
  "ok": true,
  "ready": false,
  "migrated": true,
  "ownerSetup": true
}

ok: true proves the database binding exists and migrations completed. It does not mean owner setup is finished.

5. Claim the workspace

Open the private setup link returned by the installer. The claim is carried in the URL fragment and removed from the address bar before it is submitted. Create the owner name and password.

The owner and workspace are created together before the workspace is marked ready. When workspace email is enabled, the first mailbox is provisioned during the same setup. The claim is single-use by state: after setup, another claim attempt is rejected.

6. Run workspace checks

Perform one observable check for each capability you plan to use:

1. Create a channel and send a message.
2. Reload the page and confirm the message persists.
3. Upload a small attachment and download it again.
4. If using open registration, test it in a private browser window with a second address.
5. If using invite-only registration, confirm an uninvited identity does not become an active member.
6. Create an Agent and a Task only after the Sandbox image has had several minutes to provision.

If the first Agent run reports that the Sandbox is unavailable immediately after deployment, wait for provisioning and retry. Chat readiness and Agent Container readiness are separate checks.

Optional integrations

Configure authentication methods in Workspace Settings → Authentication and RealtimeKit in Workspace Settings → Huddles. The Huddles screen includes a read-only connection test. Text chat works without RealtimeKit.

Deployment-managed provider credentials override credentials saved in the workspace UI and appear as managed by deployment. See Environment variables.

Manual GitHub deployment

The Deploy with GitHub option is for operators who want to own a repository fork and Workers Builds configuration. It is not another guided installer. The button transfers the public source to Cloudflare, but you must manually create or select the storage resources, adapt wrangler.jsonc, configure bindings and secrets, choose the build and deploy commands, attach the hostname, configure optional email routing and providers, apply migrations, create the first-owner setup claim, and run the readiness checks above.

Use pnpm run build as the Workers Builds build command and pnpm run deploy:built as the deploy command. Follow the application deployment guide for the current resource checklist. Do not reuse the public sandbox's account-specific resource IDs, names, or hostname in another account.