How to use local Qwen remotely from any device

Your staff do not each need a GPU. Qwen can run on one server while people use it through a browser on a laptop, tablet or phone. The server performs inference; the user device displays the result.

Shared access needs sign-in, permissions and device controls. Keep the model port on a private network and let the application identify users and enforce document access. Decide separately whether users can only read answers or also invoke tools.

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

Syntalith deploys private models for team access, including the server, network, interface, sign-in, limits and monitoring. We test concurrent use and document how to revoke access, including after a lost phone.

We also help individuals connect their own model server to another device. Tell us about your hardware and intended use so we can scope the setup.