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:
- Frontend reachable: homepage returns expected content.
- Admin reachable:
/_emdash/adminloads. - 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:
- Open frontend homepage and record response.
- Log in to admin and complete initial setup.
- Create and publish one test content item.
- Upload one media file and verify retrieval.
- 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:
- Confirm item is published (not draft).
- Confirm frontend queries the expected collection.
- 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