Deploy a server

Use the optional server commands to run Syndroo in your own Cloudflare account. This path connects one Threads account and can publish from GitHub Actions. The local connect, publish and status workflow remains separate.

What you need

• Node.js 24.19.0 or newer on macOS or Linux.
• Git with your name and email configured, plus npm.
• A Cloudflare account and a Threads app in Meta.
• GitHub CLI gh if you want a repository and manual CI.

Let an agent run the setup

Paste this prompt into an agent:

You are a local-shell coding Agent. Set up Syndroo 0.7.0 for me.

1. Check that Node.js 24.19.0 or newer and npm are available, and confirm that my platform is macOS or Linux for supported local writes.
2. Install Syndroo and its official platform plugins with:
   npm install --global @syndroo/[email protected] @syndroo/[email protected] @syndroo/[email protected] @syndroo/[email protected] @syndroo/[email protected] @syndroo/[email protected] @syndroo/[email protected]
3. Run `syndroo --version`. Resolve the global npm root with `npm root --global`, then read `<global-root>/@syndroo/cli/skills/syndroo/SKILL.md` and follow that bundled Skill. Do not run or invent a separate Skill-installer command.
4. Ask whether I want the local workflow or the self-hosted Server workflow, then continue with my choice.
5. For Server setup, ask whether I want GitHub. Create or push a repository only when I explicitly authorize it. Reuse authorization I have already given.
6. Keep secrets out of prompts, command arguments, logs, and tracked files. Publish content only with authorization for that content and destination.

For this task, use the self-hosted Server workflow, deploy to my Cloudflare account, and connect one Threads app.
Follow https://YOUR-DOCS-ORIGIN/getting-started/server/ after replacing YOUR-DOCS-ORIGIN with the configured docs origin.
Ask whether I want GitHub; if yes, get OWNER/REPO and private/public, defaulting to private.
Use stable request IDs and stop for Wrangler login, Meta authorization or Git push when those actions still need me.

1. Create the project

Install the CLI used by this guide, then check the local tools:

npm install --global @syndroo/[email protected]
syndroo --version

Confirm that syndroo --version prints 0.7.0 before continuing.

node --version
git config --get user.name
git config --get user.email
npm --version

For a local-only project, run:

syndroo server init ./syndroo-site

For GitHub, log in first and add the repository flags to the same command. Private is the default; use --public only when that is your choice.

gh auth login
syndroo server init ./syndroo-site --github OWNER/REPO --private

server init creates the application and Wrangler configs, pinned dependency files, a sample post and the first Git commit.

2. Run doctor

cd syndroo-site
syndroo server doctor --json

Doctor is read-only and does not repair the project. Fix any local check reported as missing or attention_required before deploying. Deployment and credentials are expected to be not_configured, while OAuth and publication readiness remain unverified.

3. Log in and deploy

Wrangler must already be logged in. server deploy reuses that login and does not launch a login flow itself.

npx wrangler login
syndroo server deploy --yes

The result reports a deployed Worker and its confirmed HTTPS origin. Review the Cloudflare account and resources before running --yes.

4. Register the callback

In your Meta app, register the Worker origin followed by the callback path. For example, replace the example host with your complete confirmed origin:

https://YOUR-WORKER.YOUR-SUBDOMAIN.workers.dev/oauth/callback/threads

5. Connect Threads

syndroo server connect threads --app-id APP_ID

Replace APP_ID with the Threads app ID and complete the Meta browser prompt. A terminal reads the App Secret without echo; automation can use THREADS_APP_SECRET or --app-secret-stdin. The command prints the connection ID and saves the verified App ID and connection reference in syndroo.config.jsonc.

Steps 6 and 7 are optional. If you do not want GitHub CI, setup is complete after step 5.

6. Optionally prepare GitHub Actions

Run gh auth login if you have not already. Then configure the repository:

syndroo server ci setup github --repo OWNER/REPO --yes

This creates .github/workflows/threads-publish.yml and configures the threads-ci GitHub environment. It does not commit, push or publish.

Your post is strict JSON with one text property:

{
  "text": "Hello from Syndroo CI"
}

Review the updated config, workflow and post, then commit and push them using the authorization you already have, or ask if this push is not covered:

git add syndroo.config.jsonc .github/workflows/threads-publish.yml posts/hello.json
git commit -m "Configure Threads publishing"
git push

7. Optionally run the workflow

In GitHub, open Actions, choose Publish to Threads and select Run workflow. Use a checked-in post path and a stable request ID:

• post_path: posts/hello.json
• request_id: threads-ci:hello-001

The workflow invokes syndroo server publish threads --input "$INPUT_PATH" --request-id "$REQUEST_ID" --yes --json with a scoped token. Publication succeeds only with a settled succeeded result and at least one successful delivery.

If the response is lost or the result is unknown, inspect the operation. Rerun the same post with the same request ID; do not create a new ID for the same logical publication.

Files and secrets

syndroo.config.jsonc is the tracked application config. wrangler.jsonc is the tracked Cloudflare config. Do not commit wrangler.effective.jsonc, .syndroo/, node_modules/, environment files or private server state.

The App Secret, CI bearer, Cloudflare admin bearer, SECRET_KEY and RUNTIME_KEY must not appear in arguments, logs or repository files. Use hidden terminal input or the documented stdin or environment paths.

If something goes wrong

• Interrupted deploy: preserve its operation ID, confirmed resources and machine receipt, then rerun the same project. Use --recover only with verified non-secret evidence.
• Unknown publication: treat it as possibly published. Inspect the operation and reuse the same request ID for the same content.
• Doctor is not ready: read the named checks in the CLI reference and the server configuration notes.
• Meta callback fails: compare the registered callback with your confirmed origin and see the Threads server notes and credential reference.