Our new free myzrok.io account cannot register its first Windows environment. The API consoles load and account sign-in works, but the consoles show only the account node and no registered environments.
Latest reproduction:
- Time: 8 September 2026, 05:03:30.531 UTC.
- Client: official zrok2 2.0.4 for Windows; release checksum verified.
- API endpoint: https://api-v2.zrok.io.
- Operation: POST /api/v2/enable, with the X-TOKEN credential obtained from the signed-in v2 console's Getting Started Wizard.
- Result: HTTP 500; no usable environment identity returned and no local environment identity file written.
- The legacy v1 client and endpoint also failed earlier. Regenerating the account token, with the account owner's approval, did not resolve registration. The current v2 console token was retrieved and retried separately after signing in to that console.
- The computer has working outbound HTTPS access. An unrelated HTTPS relay works from the same machine. This does not establish the cause of zrok's failure, but registration receives an HTTP response rather than simply timing out.
Could a maintainer check whether hosted environment registration is currently failing, and whether this account has incomplete resources from the failed attempts? Please provide a private support channel if the account email or additional identifiers are needed.
No account password, account token, customer data, or application records are included in this report.
Related reports:
Follow-up after reviewing the current v2 setup guide and source:
- The official Windows executable reports v2.0.4 [6ff92039]. A clean writable profile accepts configuration and status shows the documented endpoint,
https://api-v2.zrok.io. It has no enabled environment. The signed-in v2 console still shows only the account.
- The enable guide places registration before the first-share demo. We found no documented sandbox-promotion or prerequisite test. Could the operator confirm whether this account needs any additional provisioning?
- Clarification to the original report: the exact 05:03:30.531 UTC HTTP500 was from our application's direct POST to
/api/v2/enable, with the wizard token in X-TOKEN and JSON description/host fields. The official client is installed, but this timestamp should not be read as a fresh stock CLI reproduction. That independent online comparison is pending because our automation tool currently blocks its own network access despite an accepted grant; this is separate from the application's earlier HTTP500 response.
- The current status page reports operational, while topics 6041 and 6047 contain other recent enable500 reports. We are not assuming those establish the same root cause.
A request was also successfully submitted through NetFoundry's official support form under component zrok, identifying this as a free hosted account and asking for routing to hosted operations.
Could a maintainer correlate the recorded request time and check account provisioning/limits, underlying controller operations, and any partial resources from failed registration? We can provide further identifiers privately through support. No tokens or business records are included here.