Skip to main content

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.

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

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: 
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: 
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: 
# 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

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: 
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 for the full workflow.

​
Current safe loop

The loop today is: 
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

Declarative workflow

How to pull schema and write code against generated types before deploying.

Minimal human input

Keep the deploy loop seamless and stop only when a user action is truly required.

Testing

Unit testing pure functions and running deployed integration tests.

Handling errors

How to read deploy errors, type errors, and SQL validation failures.
Last modified on April 9, 2026