Emdash CMS Deployment Verification and First Login FAQ

Practical acceptance checks after deployment, including first admin setup and diagnosing partial-success states.

What should I verify first after deployment?

Use a three-layer acceptance sequence:

  1. Frontend reachable: homepage returns expected content.
  2. Admin reachable: /_emdash/admin loads.
  3. Data writable: create and read one content item.

Route reachability alone is not deployment completion.

Why can frontend work while admin initialization fails?

Most common causes:

  • binding mismatch (DB, MEDIA, etc.)
  • missing environment variables or secrets
  • unsupported config retained for Free plan

Recommended triage order: bindings first, env vars second, feature-tier constraints third.

What happens during first admin login?

First login typically triggers:

  • admin identity creation
  • credential enrollment (such as Passkey)
  • initial system state write

This step depends on browser and account state. Complete it on a stable network and supported browser.

What should I check first if Passkey setup fails?

Check in this order:

  • browser support and Passkey availability
  • system clock accuracy
  • cross-origin or reverse-proxy header issues

Do not start with database suspicion. Most auth failures are client or edge-proxy related.

What is a minimal production acceptance script?

Use this repeatable flow:

  1. Open frontend homepage and record response.
  2. Log in to admin and complete initial setup.
  3. Create and publish one test content item.
  4. Upload one media file and verify retrieval.
  5. Confirm published content is visible on frontend.

This validates route, auth, write, storage, and read paths.

Deployment looks successful, but content is missing. Where do I start?

Use shortest-path diagnostics:

  1. Confirm item is published (not draft).
  2. Confirm frontend queries the expected collection.
  3. Check runtime logs for query or permission errors.

Most missing-content incidents are state or query-path issues, not platform outages.

How can teams institutionalize acceptance quality?

Add acceptance actions into release workflow:

  • pre-merge: run three-layer acceptance in local or staging
  • post-release: on-duty engineer runs minimal script within 10 minutes
  • post-incident: add one new deterministic check to prevent recurrence

Reliable launches come from process controls, not tribal memory.

Verification command snippet

# Example runtime checks
curl -I https://your-site.workers.dev
curl -I https://your-site.workers.dev/_emdash/admin
npx wrangler tail your-worker-name