A remote workspace can show a “ready” listener and still be unreachable from another network. That distinction matters when a solo developer expects to check an AI coding task from a phone or another computer. The listener describes a service on the host; it does not prove that the network path, certificate, and external approval have all worked.

 

BOMTOBE makes Orke. This guide is based on Orke’s published English remote-access documentation, not a connection test or customer report. The diagram and checklist are original BOMTOBE materials, not Orke screenshots. Check the current documentation before changing network settings because setup requirements can change.

 

What connects to what

 

Orke’s remote and mobile guide describes direct HTTPS access to the public IP-and-port address of the PC or server. The terminal, shell, AI agent, and project files remain on that host. A remote browser or phone app provides another view of its workspace. The guide says terminal and web views travel directly to the host; the separate Orke account service handles Google sign-in and device or connection approval.

 

That is also separate from the AI provider login. A phone being approved to view a workspace does not sign in Claude Code, Codex, or another CLI on the host. Conversely, a provider login on the host does not make its workspace reachable from another network.

 

“Waiting for connections” is a local readiness signal

 

The documentation says “Waiting for connections” means the host’s HTTPS listener is ready. It explicitly cautions that a displayed address or ready listener alone does not confirm internet reachability. The last confirmed connection appears only after an actual authenticated external connection.

 

Treat these as different observations:

 

• The Orke setting says external access is enabled.

• The HTTPS listener starts on the host.

• The address is reachable from a genuinely external network.

• The browser or app completes Google sign-in and the access approval.

• The workspace opens on the remote device.

 

One step does not prove the next. In particular, checking from the same Wi-Fi is not the external test described in the guide.

 

Follow the documented setup in order

 

For a PC, the current English guide says to sign in to Orke with Google, prepare a suitable HTTPS certificate, choose a connection port (48650 by default), configure router forwarding and PC or cloud firewall rules, enable external access, then connect from another network and approve access with the same Google account. Orke does not provide automatic router port forwarding or a relay.

 

For a Linux server, use the current [Linux installation guide](https://orke.bomtobe.com/en/docs/orke/linux/) and [Remote and mobile guide](https://orke.bomtobe.com/en/docs/orke/remote/) together. The remote guide includes CLI setup for certificates and ports. Follow its current requirements rather than copying an old command or assuming that a desktop setting is available in every environment.

 

The certificate must match the public IPv4 address and have a trusted chain, valid dates, server usage, and the matching private key. The guide describes automatic certificate management through Let’s Encrypt and importing a certificate obtained separately. It also says Orke does not renew manually imported certificates. A certificate, private key, and PFX are sensitive; follow the official instructions for permissions and password handling. Do not disable certificate trust checks to make a connection work.

 

Diagnose the failing layer

 

If a remote device cannot open the workspace, check the host and Orke process first. Then compare the current public IP, certificate validity and trust, configured HTTPS port, router forwarding, and operating-system or cloud firewall rules. After that, confirm that the remote device is using the intended address and the same Google account for approval.

 

The failure location narrows the next check. If no external connection is confirmed, focus on address, routing, firewall, and certificate reachability. If the connection reaches an approval page but the workspace does not open, inspect the account and the original waiting browser or app. If the workspace opens but an agent does not respond, inspect that host’s session state and the CLI’s provider sign-in separately.

 

A successful listener start, an address on screen, or access on the local network is not enough evidence to claim remote access works. The useful end-to-end check is a completed authenticated connection from another network.

 

Know when direct access may not fit

 

Orke’s guide warns that direct access may fail behind carrier-grade NAT (CGNAT), corporate networks, or two layers of routers. It does not provide a relay or automatic port forwarding. If the network does not permit a direct connection, ask its administrator about the network constraint or choose a host and network that meet the documented requirements. Do not infer that opening the HTTPS port alone solves certificate issuance or IP-control checks; the guide describes separate certificate validation requirements.

 

A compact verification record

 

Before relying on a remote workspace, record the host, the configured address and port, certificate status, firewall and forwarding checks, the external network used, the Google account approval outcome, and whether the workspace actually opened. Keep secrets out of the record. This makes a “listener ready” observation useful without overstating what it proves.

 

The independent checklist is a planning aid only; it does not configure Orke or test a connection.

 

Sources and limits

 

Orke Remote and mobile documentation: https://orke.bomtobe.com/en/docs/orke/remote/

Install on a Linux server: https://orke.bomtobe.com/en/docs/orke/linux/

Orke English overview: https://orke.bomtobe.com/en/

 

This is a documentation-based explanation, not a live setup walkthrough. BOMTOBE makes Orke, and AI assisted with drafting. No network, certificate, account, or mobile connection was tested for this article.