How to use local Qwen remotely from any device

A 27B model can stay on one GPU server while approved staff use it from phones, tablets, laptops and office computers. The user device needs a browser or compatible client. Put sign-in, authorization and a controlled network path in front of the model server.

The company should approve specific devices and people. Keep the model port on the private network, behind a layer that can identify the user and apply their permissions.

Decide separately which devices may join the private network, which sources each user may access and which actions require a human approval.

One model, three client types

approved device
  |
  +-- phone / tablet / browser
  +-- laptop / IDE / API client
  +-- automation / service identity
  |
access gateway
  |
model API -> GPU host

A browser is the practical client for a phone, tablet or ordinary computer. The user signs in to a company interface, chooses permitted sources and sees citations or task history. The interface needs authentication, per-user sessions, limits and an operation log.

A coding client has broader permissions. Qwen Code can read a repository and run local tools, so it belongs on a developer device covered by the relevant policy. Server automation gets its own identity and limits, without borrowing a person's key.

What we actually tested

In the recorded evaluation, Qwen Code ran on a MacBook while the model ran on a home PC with an RTX 3090. The client read a local repository copy and sent the prompt plus required tool results to the server. It used HTTP on a trusted home LAN, authenticated with an API key, and addressed the selected vLLM configuration on port 18020. The service handled one model request at a time, meaning one inference slot.

OpenAI Codex evaluated the recorded coding-task changes against Syntalith criteria for correctness, regression tests, compatibility, scope discipline, verification and documentation. We did not test task quality on a phone or a service with concurrent users. Browser access, a private overlay network and per-user identities are deployment patterns that require checks on the target devices. The MacBook run demonstrates separation between client and GPU; it does not benchmark the complete remote architecture.

Route 1. A web interface on the private network

A phone or tablet needs a web application that accepts the question, authenticates the user, attaches permitted sources and only then calls Qwen over localhost or a protected server network.

HTTPS + company sign-in
          |
 web interface / application gateway
          |
  http://127.0.0.1:18020/v1

With Tailscale, approved devices can reach the application through Tailscale Serve. Its documentation distinguishes private Serve from public Funnel. This pattern uses a private route, keeping the model API address outside Funnel.

An example for an interface listening locally on port 3000, with values to replace:

tailscale serve --https=443 http://127.0.0.1:3000
tailscale serve status

HTTPS encrypts the connection, but it does not decide application permissions. The gateway still needs to know who is asking, which documents they may access, how many tasks they may start and where the audit trail belongs.

Route 2. A private network for apps and clients

A device running Qwen Code, a desktop application or an approved mobile client can join a private overlay network. Tailscale provides clients for platforms including Windows, macOS, Linux, iOS, Android and ChromeOS.

The access rule should name a specific group, service and port. Tailscale Grants describe source, destination and allowed capabilities under a deny-by-default model. Add device approval, posture requirements, a lost-phone revocation procedure and periodic policy review.

On a fixed office network, a private address, firewall and rule for a selected subnet can create a similar boundary. Keep the guest network outside it. A 192.168 prefix does not establish trust.

Route 3. An SSH tunnel for one engineer

SSH is a useful fallback for a laptop with a terminal. Daily use from a phone, tablet or larger group needs a more convenient layer. A port forward can look like this:

ssh -N \
  -L 18020:127.0.0.1:18020 \
  gpu-user@gpu-host.example

The client then calls http://127.0.0.1:18020/v1. The setup includes host-key verification and a restricted SSH account. The API key creates a second boundary, and a broken tunnel should stop the task without a risky automatic replay. Replace the port when using another server profile.

Name the secret and the data flow

Keep the key out of repositories, files synchronized to a personal cloud account and mobile application code. One person may use a mode-0600 user file. A company needs a secret store, rotation and an identity assigned to each user or service.

A file opened on a laptop can remain there, while the content Qwen needs crosses to the GPU workstation. A phone attachment may pass through the gateway, file reader, logs or cache according to the application design. A local model removes one external provider from the route; the data still travels through the system.

Seven checks before handover

1. New device: without approval it cannot see the interface or port.
2. Lost phone: device revocation ends active sessions and blocks new ones.
3. Wrong role: the user cannot retrieve a source outside their scope.
4. Missing key: the API refuses the request.
5. Second user: queueing, a limit or refusal is visible.
6. Broken connection: the client does not repeat a side-effecting action.
7. GPU restart: the interface reports failure and a synthetic test confirms recovery.

Run these checks on at least one phone, one computer away from the office and a device that deliberately fails policy. This tells you which devices the service has actually been tested on.

Where self-service stops

One person can set up a private tunnel and client. A company also needs an interface, sign-in, roles, limits, observability, a lost-device procedure, a service owner and rules specifying which actions require human approval. One GPU adds queueing because the measured home profile had one active slot.

Syntalith designs the route from user device to model: web interface, private network, API gateway, data policy, load measurement, monitoring and administrator handover. An AI process audit defines the architecture and scope. Book a free process scan to decide which devices and data should receive access.