Syndroo docs
Version 0.2.0-rc.1 unpublished release candidate Website GitHub

Deploy the Worker to Cloudflare

This is the production path: the Worker runs in your own Cloudflare account, with your database, your queue and your credentials. It shares no steps with local development, and it does not need a checkout on your machine.

Status of this path

The steps below are the deployment procedure recorded in the product repository for the 0.2.0-rc.1 candidate. They were not executed while writing this page: this candidate has not been deployed or accepted as a release, and no live account has been exercised. Where the procedure says "pending", treat it as pending.

What you own after deploying

ResourcePurpose
WorkerThe Bearer-authenticated HTTP API. It is the only runtime.
D1 databaseStores one post row and one publication row per selected platform.
QueueCarries immediate delivery jobs to the Queue consumer.
Cron TriggerScans every 15 minutes for scheduled posts and stale jobs.
SecretsSYNDROO_API_KEY plus the credentials of each platform you enable.

Steps

  1. Deploy from the repository

    Follow the deploy section of the product README: Syndroo README (deploy procedure). It links a Deploy to Cloudflare button, whose documented behaviour is to create an independent repository in your account, ask for SYNDROO_API_KEY, provision the D1 database and Queue, apply the migrations, configure the Cron Trigger, and deploy the Worker.

    Two limits are recorded for this candidate: the button still deploys this source repository, and the thin deployment template passed isolated local installation, migration, build and startup checks but is not wired to the button and is not published to a registry. There is no npm install syndroo path in this candidate.

  2. Choose the API key at deploy time

    SYNDROO_API_KEY is a long random secret that you invent. It is the Bearer token every client sends, and it can publish. Store it in your own secret manager as well; the Worker cannot show it back to you.

  3. Add platform secrets after the deployment

    Open the deployed Worker, then Settings → Variables and Secrets, and add only the credentials for the platforms you intend to publish to. Each platform guide lists the exact names and what the platform requires.

    • Platforms are enabled independently; a platform without credentials returns HTTP 422 and PLATFORM_NOT_CONFIGURED.
    • A deployment with no platform credentials can still answer health checks, but it cannot accept posts.
    • Keep platform secrets out of any template's required-secret list; they are optional per deployment.

  4. Verify the deployment

    curl "https://your-worker.your-subdomain.workers.dev/health"
# {"status":"ok"}

    Then publish one post to one platform, exactly as in Publish your first post. If the API key is missing or wrong, the request fails with HTTP 401; if a platform is not configured, it fails with 422 before anything is stored.

Boundaries and cautions

  • Never deploy using the local Wrangler environment. Local runs read .dev.vars and a local database; production reads Worker secrets.
  • No dashboard. Everything after deployment goes through the HTTP API, wrangler or the Cloudflare dashboard's own secret and log views.
  • Migrations are part of deployment. Local development applies migrations to a local database; that does not migrate production.
  • You maintain the credentials. Renew, rotate and revoke each platform credential according to that provider's own rules, and replace the Worker secret when you do. Syndroo has no automatic token refresh.
  • Scheduling has a scan cadence, not a completion guarantee. Cron looks for due posts every 15 minutes, then queue and platform time are added on top. The requested scheduledAt is the earliest intended time, and no upper bound is promised.

Applies to

Syndroo 0.2.0-rc.1 (unpublished release candidate). For the local path instead, see Local development.