The Web UI works on the remote machine, but you cannot decide whether to expose it, tunnel it, or place it behind a proxy.

Fastest answer: this week, keep DeepSeek Harness Remote Web UI on loopback and use an SSH tunnel for personal or small fixed-group access. Move to a non-loopback public entry only after you have independent authentication, TLS, source restrictions, audit logs, and a tested shutdown path.

This article is for:

  • Individual developers who need occasional access from another device.
  • Platform engineers who need a stable entry for several people.
  • Security owners who must verify that the proxy, Host trust, and application permissions form a complete control chain.
01

The decision starts with access scope

The correct entry point depends on who needs access and how much governance the service requires.

DeepSeek Harness starts its Web UI at http://127.0.0.1:3080 by default when launched with the documented npm command. The official repository also warns that the project is still in developer preview and may introduce compatibility-breaking changes. Review the official DeepSeek Harness repository before copying commands or parameters.

Access pattern Recommended entry Why it fits Main limitation
One developer, occasional access Loopback listener plus SSH tunnel Keeps the service off the network and uses the SSH account as the outer gate Each user needs SSH access and tunnel setup
Two to five fixed members Loopback listener plus controlled bastion or per-user tunnels Limits exposure while the team is still small Weak central session visibility
Formal team or external users Non-loopback listener behind a controlled HTTPS entry Supports separate identity, session policy, source filtering, and audit Requires continuous security and maintenance ownership

The first mistake is treating a network setting as an authentication setting. A loopback listener limits where the TCP service can be reached. A non-loopback listener expands reachability. Neither setting proves who the browser user is.

The second mistake is using trustedHosts as if it were a login system. It is a Host authority boundary. It can help reject unexpected Host values, but it does not create accounts, sessions, roles, or revocation. HTTP uses the Host request header to identify the host and port targeted by the request, which is why Host validation matters. It remains separate from user authentication. See the HTTP Host header definition.

02

Exposure surface and listener state

Loopback is a reachability decision

A service bound to 127.0.0.1 accepts traffic from the local host. An SSH tunnel then creates a second local endpoint on your client device and carries the request through the encrypted SSH connection.

A typical local-forwarding pattern is:

ssh -N -L 3080:127.0.0.1:3080 user@remote-host

The local 3080 is only an example. Confirm the actual Web UI port and listener before using it. The OpenBSD SSH manual describes a local bind address of localhost as local-only, while an empty address or * can make a forwarded port available on all interfaces. Use the local-only form unless you have a specific reason to share the forwarded port. Check the OpenSSH local forwarding behavior.

The practical benefits are clear:

  • The Web UI does not need a public firewall rule.
  • The remote service can remain on its documented loopback address.
  • Closing the SSH process closes the access path.
  • Access can be limited through SSH keys, accounts, and server-side policy.

The hidden costs are also real:

  • A team member needs an SSH identity.
  • A tunnel can disappear when the laptop sleeps or changes networks.
  • SSH connection logs do not automatically equal Web UI activity logs.
  • One shared SSH account makes later revocation and attribution difficult.

For a single developer using a remote Mac, these costs are usually acceptable. For a team that needs browser-based access without shell access, they become a governance problem.

Non-loopback expands the reachable population

If you change the Web Server configuration to listen on a non-loopback address, the service may become reachable from additional interfaces. That can include a private network, a public address, or both, depending on routing and firewall rules.

Do not stop at “the page loads.” Check the full exposure path:

# Confirm the actual listening address
lsof -nP -iTCP:3080 -sTCP:LISTEN

# Test locally
curl -I http://127.0.0.1:3080

# Test through the intended private or public address
curl -I http://YOUR_INTENDED_HOST:PORT

Run the external test from a device outside the server’s local network. A successful local request only proves local reachability. A successful external request proves that routing, firewall rules, and the listener combine to expose the service.

Check Loopback plus SSH tunnel Public or private non-loopback entry
Listener exposure Local host only Depends on bind address and firewall
External port scan Should show no direct Web UI port Must show only the intended entry
Shutdown method Stop the SSH tunnel or SSH access Disable proxy route, firewall rule, or listener
Source restriction Usually enforced by SSH access policy Must be enforced at the network or proxy layer
Failure risk Tunnel drops Proxy, certificate, firewall, and app can fail separately

Can DeepSeek Harness Web UI be opened directly to the public internet? Technically, a non-loopback listener can make that possible. Operationally, the answer should be “not by listener change alone.” You need an explicit identity layer, encrypted transport, source policy, logging, and a documented rollback path before treating it as a team entry.

03

Host trust and user identity

trustedHosts is not a login boundary

A browser can send an acceptable Host value without proving that the person behind the browser is authorized. That distinction matters because a correctly configured Host allowlist can still leave the page reachable by anyone who can reach the endpoint.

Keep these layers separate:

  1. Network reachability — can a packet reach the service?
  2. Host authority trust — does the request use an accepted host value?
  3. User authentication — which person or service is connecting?
  4. Harness authorization — what can that authenticated user read, edit, execute, or approve?

If your acceptance test checks only whether the page opens, it has tested reachability. It has not tested authentication or authorization.

The official DeepSeek Harness guide states that the Web UI requires a configured model and a selected workspace before normal task execution. It also notes that the agent may read and edit workspace files, run commands, delegate work, and request approval for operations governed by the active permission policy. Read the official Web UI guide.

Why can a configured trustedHosts list still fail as authentication? Because Host trust validates a request authority, not a human identity. It does not tell the application whether Alice, Bob, an expired contractor, or an attacker is using the browser. It also does not provide session expiry, password reset, multi-factor authentication, role assignment, or immediate user revocation.

A team entry should therefore have independent controls:

  • Per-user authentication.
  • Session expiration and logout.
  • Permission groups or an equivalent authorization model.
  • A way to revoke one member without changing everyone else’s access.
  • Logs that identify the user, source, time, and result.
  • A clear rule for sensitive actions such as command execution or file modification.

OWASP separates authentication from session management and access control. Its guidance also recommends encrypted transport for the complete web session, not only the login request. Review the OWASP session management guidance.

04

Transport, credentials, and proxy boundaries

SSH and HTTPS solve different problems

SSH tunneling gives you an encrypted path between the client and the remote host. It does not automatically provide a multi-user Web UI identity model.

HTTPS gives the browser an encrypted connection to the configured web endpoint and allows the browser to validate the server certificate. It does not automatically identify the user unless an authentication mechanism is added.

Security responsibility SSH tunnel HTTPS team entry
Encrypt traffic in transit Provided by SSH Provided by TLS
Identify the remote server SSH host-key verification Certificate and hostname verification
Identify the human user SSH account or key Must be added through application or proxy authentication
Revoke one member Revoke SSH key or account Revoke the user session or identity
Browser-native access Requires a tunnel on each client Yes, if the entry is correctly configured
Audit detail Strong at SSH connection level Must combine proxy and application logs

OWASP’s TLS guidance is explicit: TLS provides confidentiality, integrity, and server authentication, but it does not verify the client user unless client certificates or another client-authentication method is used. Read the OWASP TLS guidance.

Protect the credential boundary as carefully as the network boundary:

  • Do not place an API key in a client-side bundle or URL.
  • Keep provider credentials in the remote runtime environment or the documented secret store.
  • Never commit .env files containing real credentials.
  • Confirm whether the browser ever receives a credential, rather than assuming the proxy hides it.
  • Check whether forwarded headers are trusted only from the intended proxy.
  • Avoid logging authorization headers, cookies, query strings, or full request bodies.

The official development documentation describes DEEPSEEK_API_KEY and an optional DEEPSEEK_BASE_URL, and warns against committing real credentials. It also describes the Web UI and automation demos as key-backed workflows. Check the official development configuration notes.

Warning: Do not publish a raw non-loopback Web UI and call it secure because the page has no visible login form. “No login prompt” is an unverified access condition, not an authentication result.

05

Auditability and maintenance load

An SSH tunnel is attractive because it removes several public-entry components. That is exactly why it works well for personal access. You do not need to operate a public certificate, proxy route, browser session layer, and external firewall policy for a one-person workflow.

A team entry creates a longer maintenance chain:

  • Listener address changes.
  • Firewall rules.
  • DNS or host routing.
  • TLS certificate renewal.
  • Reverse-proxy configuration.
  • Authentication integration.
  • Session termination.
  • Source allowlists.
  • Application upgrades.
  • Workspace and permission review.
  • Access logs and incident investigation.

DeepSeek Harness is in developer preview, and the official repository warns about compatibility-breaking changes. After an upgrade, repeat the listener, Host rejection, authentication, workspace, and permission checks. Do not assume that a working Web UI path remains safe after a version change.

For long-running work on a remote Mac, also separate process persistence from network exposure. A service can keep running while the public entry is disabled. That is often the safer recovery design: preserve the workspace and process, close the external route, then restore access only after review.

The official user guide says the process uses its invoking directory as the default filesystem location and that a fresh Web UI has no selected workspace until one is added. Record the working directory and workspace selection as part of your deployment evidence. Confirm workspace behavior in the official user guide.

For a team, assign ownership before deployment:

  • One owner for certificates and proxy configuration.
  • One owner for user access and revocation.
  • One owner for Harness upgrades and regression checks.
  • One written location for listener state, allowed sources, and rollback steps.

Without named ownership, a public endpoint tends to remain open after its original project ends.

06

The six-step remote access acceptance test

Use this sequence before choosing an SSH tunnel or a public entry.

1. Record the intended scope

Write down:

  • Number of users.
  • Whether they need shell access.
  • Whether access is temporary or continuous.
  • Whether users need separate identities.
  • Whether the Web UI can execute commands or modify files.
  • Who owns revocation and incident response.

If only you need access from another device, start with loopback and SSH. If several people need browser-only access, continue the evaluation instead of sharing one SSH account.

2. Confirm the listener

Run a listener check on the remote host:

lsof -nP -iTCP:3080 -sTCP:LISTEN

Confirm that the process is bound to the intended address. Also record the exact command, configuration file, and port used. The documented default is 127.0.0.1:3080, but commands and parameters must be checked against the current repository before deployment.

3. Test local and external reachability separately

From the remote host, test the loopback URL. From an external device, test the intended tunnel or public hostname.

Capture:

  • Response status.
  • Redirect behavior.
  • Browser console errors.
  • WebSocket or streaming failures.
  • The source address recorded by the entry layer.
  • Whether an unintended address also responds.

A port that is reachable from the internet but absent from your written exposure plan is a failed test.

4. Test Host acceptance and rejection

Send an accepted Host value and an intentionally wrong value. Verify that the wrong value is rejected at the documented layer.

Do not infer that a rejected Host means the user is authenticated. Record the result under “Host trust,” not “identity.”

5. Test identity and permissions

For every intended user:

  • Authenticate with an individual identity.
  • Open only the assigned workspace.
  • Run a harmless read-only task.
  • Request a controlled write or command action.
  • Confirm the expected approval behavior.
  • Revoke the identity.
  • Confirm that an existing session is terminated or denied according to policy.

The Web UI guide describes workspace selection, task execution, file access, command execution, delegation, and approval behavior. Those functions should be part of the acceptance test rather than treated as optional UI details.

6. Test shutdown and recovery

Close the SSH tunnel or disable the public route. Then verify:

  • The previous browser session cannot continue unexpectedly.
  • The service remains bound only where intended.
  • Logs show the disconnect or denial.
  • The remote process can be restarted without exposing a broader address.
  • A documented rollback returns the service to loopback.

Choose SSH when this test passes with a small operational burden. Choose a controlled public entry only when every identity, TLS, source, logging, and recovery test has an owner.

07

Final choice: tunnel first, public entry only when governed

Your current condition Final choice Next action
One user, occasional remote access SSH tunnel Keep the Web UI on loopback
Small fixed group with technical users Per-user SSH or a controlled private route Avoid shared accounts and document revocation
Team needs browser-only access Controlled HTTPS entry Add independent authentication, TLS, source restrictions, and audit
No owner for logs, certificates, or access removal Return to loopback Do not publish the service
Workspace contains sensitive code or command execution is enabled Strongest available private boundary Add approval and identity tests before wider access

If your current setup is a public listener with no independent authentication, its main weaknesses are broad reachability, unclear user attribution, and difficult emergency revocation. If it is a shared SSH account, the weaknesses are poor per-user accountability, cumbersome member removal, and limited browser-native access. If the service runs on an unmanaged personal machine, you also inherit uptime, sleep-state, patching, and recovery problems.

For a temporary remote development environment, a managed remote Mac can make the operational boundary easier to control than exposing a workstation from a home network. Review the Mac rental pricing overview and the cloud Mac order guide only after deciding whether your workload needs temporary access, persistent execution, or physical-device control. You can also compare the broader remote Mac environment options before choosing where the Harness process should live.

The deciding question is simple: do you need a private path for yourself, or a governed entry for a team? For the first case, keep the Web UI on loopback and use an SSH tunnel. For the second, build the identity, TLS, audit, and recovery controls before opening a non-loopback listener.