> ## 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 and test loop

> EdgeSpark has no local dev server. Use dry runs, cautious deploys, and live log inspection while public staging support is still coming soon.

EdgeSpark has no local development server. Today, new public projects also do not have a separate staging environment yet, so `edgespark deploy` updates the current live project environment.

That changes the agent workflow:

* use `edgespark deploy --dry-run` aggressively
* keep live deploys small and intentional
* do not stop for routine deploys; stop only when the live impact is clearly dangerous or still not understood

## The deploy command

```bash theme={null}
edgespark deploy
```

This runs five steps automatically:

1. **Schema sync** — refreshes generated files in `server/src/__generated__/`
2. **Type check** — runs `tsc --noEmit` and fails on any error
3. **Build** — bundles your code with esbuild into `dist/bundle.js`
4. **Route analysis** — scans your routes and shows a categorized summary
5. **Deploy** — uploads the bundle and makes it live on the current default environment

## Read the route analysis first

Before uploading, the deploy command shows every route categorized by its auth convention. Read this carefully because it is your last safe checkpoint before a live deploy:

```text theme={null}
Route Summary:
────────────────────────────────────────────────────────────
Protected (login required, auth.user guaranteed):   3 routes
  GET    /api/posts
  POST   /api/posts
  DELETE /api/posts/:id

Public (login optional, auth.user if logged in):   1 routes
  GET    /api/public/feed

Webhooks (no auth check):                          1 routes
  POST   /api/webhooks/stripe
```

If a route appears in the wrong category, fix the path prefix before deploying.

## Dry run first

Use `--dry-run` to run build validation without uploading anything:

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

Use this whenever:

* you have not yet validated the route summary
* the change touches auth, migrations, storage, or secrets
* the deploy is risky enough that human confirmation is still needed

## Test deployed routes carefully

After a real deploy, test with your project URL:

```bash theme={null}
# Public route
curl https://my-app.edgespark.app/api/public/feed

# Protected route
curl -H "Cookie: better-auth.session_token=<token>" \
  https://my-app.edgespark.app/api/posts
```

Because there is no public staging environment yet, treat deployed testing as live-environment testing.

## Read logs immediately after requests

```bash theme={null}
edgespark log tail
```

Logs stream from the current default environment and show `console.info`, `console.warn`, `console.error`, request summaries, and unhandled exceptions from your handlers.

For longer debugging sessions, it is usually better to keep the stream running in the background and inspect a file:

```bash theme={null}
mkdir -p .logs
edgespark log tail > .logs/edgespark.log 2>&1 &
```

For AI agents, the important part is the pattern: keep the stream running in the background, then read `.logs/edgespark.log` between deploys and requests to understand the latest runtime behavior. That works better than staying attached to a continuously streaming terminal session. See [View EdgeSpark logs](/guides/logs) for the full workflow.

## Current safe loop

The loop today is:

```text theme={null}
edit code
  → edgespark deploy --dry-run
    → human confirmation only if needed
      → edgespark deploy
        → curl https://my-app.edgespark.app/api/...
          → edgespark log tail
            → fix → repeat
```

## Staging is coming soon

Public staging support is planned but not available yet. When it lands, this page will expand to cover isolated staging URLs and promotion workflows.

## See also

<Columns cols={2}>
  <Card title="Declarative workflow" icon="database" href="/agents/declarative-workflow">
    How to pull schema and write code against generated types before deploying.
  </Card>

  <Card title="Minimal human input" icon="comment" href="/agents/when-to-ask">
    Keep the deploy loop seamless and stop only when a user action is truly required.
  </Card>

  <Card title="Testing" icon="check" href="/guides/testing">
    Unit testing pure functions and running deployed integration tests.
  </Card>

  <Card title="Handling errors" icon="triangle-exclamation" href="/agents/handling-errors">
    How to read deploy errors, type errors, and SQL validation failures.
  </Card>
</Columns>