everyapp status: the report and its fixes
Drive `pnpm everyapp status --json` to learn what is left to do on a Gateway and its apps, read the report line by line against `done.data`, and apply each fix in order until `fixes` is empty.
pnpm everyapp status is the one command that says where a Gateway stands and what to run next. Run it after setup, after every deploy or install, and whenever the person asks "is it working", "what is left", "why does it say Needs setup". It reads the Gateway's D1 and cf (packages/cli/src/commands/status/index.ts), asks nothing of the Gateway over HTTPS, changes nothing, and ends with one done event. The user docs explain the same report for the person: Check your setup with everyapp status.
The loop
pnpm everyapp status --jsonfrom the checkout (anywhere inside it;--account-id <id>when the login sees several accounts, elsechoose_account).- Read
done.message:Gateway https://<host>: <n> apps live, nothing to fixor… <m> problems to fix. Onlyerrorandwarningfixes count as problems (needsFixinginproblems.ts). - For each entry of
done.data.fixesin order: ifrunis a command, run it (with--jsonwhen it is aneveryappcommand;notesays what it does); ifrunisnullandfixis words, do what they say; ifseverityissettling, wait and runstatusagain; ifseverityisinfo, tell the person and move on (an update to take or leave). - Run
status --jsonagain. Stop whenfixeshas noerrororwarningleft, and tell the person what is live (data.apps[]withstatus: "active"andbound: true) and what settles by itself (a certificate, a first visit).
Three outcomes that are not a done event: no Gateway in any account the login sees ends with action_required install_gateway (exit 2; run data.rerun, pnpm everyapp setup --domain <hostname>, only when the person wants one); a database with no install row answers done with data.installed: false and one fix, GATEWAY_NOT_INSTALLED (pnpm everyapp setup, it asks for the hostname again); a login the account refuses ends as the login errors on Error codes.
The report, line by line
What the person sees (render.ts), and the done.data field behind each line (the full field table is on Driving setup for a person).
| Line | What it says | done.data |
|---|---|---|
Gateway |
The Gateway's URL and how it is deployed: self-hosted (in the person's account) or hosted; no mode before the first upload. |
gatewayUrl, mode |
Cloudflare |
The account the login sees, by name. | accountId |
Owner |
The owner's email and organization, or none yet: the owner link was never opened, nobody can sign in, apps still deploy. |
owner, claimed |
Access |
on · in step with this Gateway · everyone signs in through Cloudflare Access first; on · drift: … naming what Zero Trust has that this release doesn't want (paths differ on <hosts>, sign-in methods differ on <hosts>, no application in front of <hosts>, the settings name other applications; the problem ACCESS_DRIFT then says to run pnpm everyapp access on); on · in step? this login can't read Access or on · in step? couldn't check (ACCESS_DRIFT_UNKNOWN); or off (then Next: carries pnpm everyapp access on), or ! couldn't check. Absent for a hosted Gateway or before the first upload. |
access ({ on, teamDomain, drift, driftUnread } or null) |
Release |
The live release, then how it stands: matches this checkout; this checkout has newer Gateway changes (an update to take or leave); this checkout is behind (deploys from here are refused until git pull); changed outside everyapp (the Worker serves a version setup didn't upload); never uploaded. |
release, versionId, recordedVersionId, upToDate, checkout |
TLS |
ready on <n> hostnames, waiting for <hosts> · usually a few minutes, no hostnames yet, or ! couldn't check. |
tls, certificates[], domains, liveDomains |
Deploys |
One row per run in progress: who, from where, started how long ago. Absent when none. | leases[] |
APP table |
One row per app the registry lists (MCP apps are not here: pnpm everyapp mcp list). STATUS is ✓ live; ○ live on first visit or ○ waiting for certificate (settling); ! needs setup (a required setting is unset, the app doesn't open); ! never deployed; ! not bound (uploaded, the live Gateway doesn't bind it); ✗ Worker missing; ✗ can't be bound; switched off; with · deploying while a run holds it. |
apps[]: id, hostname, status (active, binding, pending, disabled), bound, deployedBy, publicRoutes[], setup |
URL, DEPLOYED BY, PUBLIC |
The app's address; the email of the last deployer, or API token; what its deployed manifest opens without sign-in: its routes (GET /t/*, POST /t/e, GET /health +2 more, the first three) and MCP /mcp (gateway) or (app) where the manifest sets mcp (blank when neither). |
apps[].hostname, apps[].deployedBy, apps[].publicRoutes |
EMAIL table |
Only apps that send or receive: SENDS AS (its senders, or the Gateway's sender), RECEIVES (each inbound address; ! not routed yet until a deploy routes it, ! not delivered when the rule is gone or off, (inbound off) when the manifest no longer declares inbound mail, ! still routed, no longer listed). |
apps[].email (senders, inbound, routed, declaresInbound) |
SETTING table |
Only apps whose manifest declares settings: one row per setting, WHERE is Gateway or the app's id, STATUS is ✓ set, ! not set (required, blocks the app), not set (optional), ! not recorded (set before the Gateway recorded names), ! couldn't check. |
apps[].setup: ready, settings[] (names, holder, need.kind, why, docs, setup, set), unmet[], groups[], command |
| The blocks | After a blank line, one block per problem, led by ✗ (error), ! (warning) or a dim i (info); problems one command fixes share a block; settling ones have no block. Each block: the headline, the detail lines, Fix: in words or Run: with the command and a note. |
fixes[]: { code, severity, message, run, note?, fix? } |
Next: |
After the blocks: what isn't done yet, at most four lines, each a command or a page then what it does (an AI key, an MCP app to turn on, Cloudflare Access, people to invite, an AI client to connect, the first app, email). Nothing is broken; each line goes when its state changes, and none repeats a block's command. Absent when nothing applies. | next[]: { code, command?, url?, note, why } (the codes and the reads) |
message in each fix is the headline and the detail lines joined by newlines; run is the exact command (null when there is none). For an app that needs setup, the block lists each unmet setting as <Label>: <why>, the provider's hint (what the key is and where it comes from), Get it at <docs URL> and Guide: .claude/skills/everyapp/setup/<file> (the skill's setup file for that integration; read it before asking the person for a key; a provider registered on the Gateway has none, and its line is Guide: pnpm everyapp provider show <id>), then Run: pnpm everyapp configure <app> (it asks for each; agents drive it with NAME=value lines on stdin or --from-env, see the secrets page).
Fixes by code
The headline, the command and where each is documented: What status reports as fixes on the error codes page, one heading per code, and the one-table summary under Troubleshooting by symptom. In the order a person finishes a setup:
| Finish the Gateway | Run |
|---|---|
GATEWAY_NOT_INSTALLED, GATEWAY_NOT_UPLOADED, NO_OWNER, GATEWAY_CHANGED, BINDINGS_DIFFER |
pnpm everyapp setup (it resumes, repairs, or prints a new owner link) |
CHECKOUT_BEHIND |
git pull, then pnpm install |
GATEWAY_OUTDATED (info) |
pnpm everyapp update, or leave it |
| Finish an app | Run |
|---|---|
APP_NEEDS_SETUP |
pnpm everyapp configure <app>, with the key the setup file says how to get |
APP_NOT_UPLOADED, APP_WORKER_MISSING |
pnpm everyapp deploy in the app's directory, or pnpm everyapp delete <app> |
APP_NOT_BOUND |
pnpm everyapp delete <app>, then deploy it again |
APP_BINDING, CERT_PENDING, DEPLOY_RUNNING (settling) |
nothing; status again in a minute |
EMAIL_ROUTE_PENDING, EMAIL_ROUTE_MISSING |
pnpm everyapp deploy in the app's directory (the deploy makes the rule; --enable-email-routing when the domain's Email Routing is off) |
EMAIL_INBOUND_UNDECLARED |
email: { inbound: true } in everyapp.config.ts and deploy, or pnpm everyapp email unset inbound |
ACCESS_DRIFT |
pnpm everyapp access on: brings Cloudflare Access in step with this Gateway (the paths it lets through, the sign-in methods, a missing application, the settings) |
SETTINGS_UNKNOWN, EMAIL_ROUTES_UNKNOWN, CERTIFICATES_UNKNOWN, ACCESS_UNKNOWN, ACCESS_DRIFT_UNKNOWN (cf couldn't answer) |
run status again; if it repeats, the message's Cloudflare said: names the cause (a token missing a permission, an API outage) |
What it does not check
It never opens the Gateway or an app over HTTPS: a live row means the registry and Cloudflare agree, not that a request succeeded. To prove an app answers, fetch https://<app host>/ (a sign-in redirect is the expected answer behind the Gateway; behind Cloudflare Access it is Access's login page) and a public route the deploy printed, if it has one (the starter has none; GET https://<gateway>/health answers {"status":"ok"} without a sign-in). It does not list MCP apps (pnpm everyapp mcp list --json), and it does not read what everyapp dev runs locally.
Troubleshooting by symptom
What a symptom from everyapp, the Gateway or an app usually means, how to confirm it (status --json fixes, --verbose, the log file) and the fix, with a link to each error code's entry.
Build an app
Build or change an app on EveryApp: create one, add a feature, a page, a table, an AI tool, a capability, a public route or a secret, the way the apps already on EveryApp do it. Use before writing any code for an EveryApp app, for "build me an app", "add X to the app" or "make the app do Y".