Skip to main content
The Yboard CLI handles building and deploying your application to Cloudflare Workers with a single command.

​
Basic deployment

This runs the full deployment pipeline:
  1. Fetches database URL from Yboard.
  2. Pushes database schema using drizzle-kit push from packages/db.
  3. Builds the application with bun vite build in apps/web.
  4. Uploads client and server files to Yboard.
  5. Prints the live URL.

​
Skip database push

If you haven’t changed the database schema, skip that step:

​
Deployment environments

Yboard supports multiple deployment environments via the project’s npm scripts: Preview and rollout deployments use the project’s npm scripts (defined in apps/web/package.json) which build with environment-specific Astro configs and deploy via Wrangler.

​
What gets deployed

The CLI reads the build output from apps/web/build/:
  • build/client/ — Static assets (HTML, CSS, JS, images) served from the edge.
  • build/server/ — Server-side code running on Cloudflare Workers.
Files like .dev.vars and wrangler.json in the server directory are excluded from upload.

​
How deployment works under the hood

Yboard deploys your app to Cloudflare Workers for Platforms, which provides isolated worker scripts per app. The deployment pipeline:
  1. Asset upload session — Starts an upload session with Cloudflare. A manifest of file hashes determines which assets need uploading (unchanged assets are skipped).
  2. Asset upload — New or changed static assets are uploaded to the edge.
  3. Worker script upload — Your server-side code is uploaded with bindings:
    • YB_URL, YB_API_HOSTNAME — Yboard service URLs
    • YB_ORGANIZATION_ID, YB_APP_ID — Your app identity
    • YB_WORKOS_CLIENT_ID — Authentication config
    • Your custom secrets
  4. Configuration — The worker is configured with:
    • nodejs_compat compatibility flag
    • Auto trailing-slash HTML handling
    • Log forwarding via tail consumers
    • Asset serving from the edge

​
Deployment environments in detail

Each environment (dev, preview, production) maintains its own:

​
Moving between environments

From the web dashboard, changes flow through environments:
  1. Dev → Preview — Deploy your development state to a preview environment for testing.
  2. Preview → Production — Promote a tested preview to production.
Each promotion copies the worker script and runs any necessary database migrations automatically.

​
Viewing your deployment

After deployment, the CLI prints the URL. You can also find it in:
  • The terminal output of yboard deploy.
  • The Version History tab in the web dashboard.

​
Viewing logs

After deploying, view runtime logs:
This fetches recent logs from your deployed worker. Requires at least one successful deployment.

​
Prerequisites

  • Run yboard login first to authenticate.
  • Run yboard init first to provision the database.
  • Run from the project root (the CLI expects apps/web/ to exist).