> ## Documentation Index
> Fetch the complete documentation index at: https://docs.edgespark.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# The EdgeSpark deploy pipeline

> What edgespark deploy does: schema sync, TypeScript type check, esbuild bundle, route analysis, upload, and live deployment to Cloudflare Workers.

Running `edgespark deploy` triggers a multi-step pipeline that goes from your local TypeScript code to a live Cloudflare Worker.

## The steps

<Steps>
  <Step title="Schema sync">
    Before building, EdgeSpark refreshes the generated files in `server/src/__generated__/`:

    * `sys_schema.ts` — platform-managed table definitions
    * `sys_relations.ts` — platform-managed relations
    * `edgespark.d.ts` — generated imports from `edgespark`
    * `server-types.d.ts` — generated runtime SDK types

    This keeps generated platform schema and runtime types current without overwriting your repo-authored files in `server/src/defs/`.
  </Step>

  <Step title="Type check">
    The build runs `tsc --noEmit` to check your code for type errors. The build fails if there are type errors. This catches issues like accessing a column that no longer exists in the schema.
  </Step>

  <Step title="Bundle">
    Your application is compiled to a single JavaScript bundle using esbuild. The bundle includes your route handlers and the Drizzle schema. Platform internals are excluded — they are injected by the EdgeSpark runtime at execution time.

    ```
    src/index.ts → dist/bundle.js
    ```
  </Step>

  <Step title="Route analysis">
    The CLI scans your bundle and reports the routes it found, grouped by auth convention:

    ```
    Routes:
      /api/posts           GET  (login required)
      /api/posts           POST (login required)
      /api/public/feed     GET  (public)
      /api/webhooks/stripe POST (no auth)
    ```

    Use `edgespark deploy --dry-run` to run steps 1–4 without uploading. Useful for verifying the build and route analysis in CI.
  </Step>

  <Step title="Upload">
    The bundle is uploaded to the platform. The CLI uploads your compiled code directly — no manual configuration needed.
  </Step>

  <Step title="Deploy to Cloudflare">
    The platform deploys your worker to Cloudflare's edge network, configures all bindings (database, storage, secrets, environment), and makes it live on your current project environment within seconds.
  </Step>
</Steps>

## Dry run

Run a dry run to validate your build without deploying:

```bash theme={null}
edgespark deploy --dry-run
```

This runs schema sync, type checking, bundling, and route analysis, then exits. The output includes your bundle size and any type errors. Use this in CI pipelines to catch issues before deploying.

## What changes between deploys

Each deploy is independent. `edgespark deploy`:

* Always replaces the worker script with the new bundle
* Always re-applies worker bindings and environment variables
* Does **not** run database migrations — schema changes require explicit migration commands
* Does **not** modify secrets — secrets are managed separately

## Staging support

Staging support is coming soon, but it is not part of the public deploy flow for new projects today. The current docs only cover `edgespark deploy` because that is the public deploy path that exists now.

## See also

<Columns cols={2}>
  <Card title="Deploy your project" icon="globe" href="/guides/deployment">
    The current public deploy flow with `edgespark deploy` and `--dry-run`.
  </Card>

  <Card title="Environments" icon="server" href="/concepts/environments">
    The current single-environment model and what staging will add later.
  </Card>

  <Card title="Declarative workflow" icon="database" href="/agents/declarative-workflow">
    How schema sync at the start of every deploy works and why it matters.
  </Card>

  <Card title="CLI commands" icon="terminal" href="/cli/commands">
    Full reference for edgespark deploy flags and options.
  </Card>
</Columns>