OpenCode Portal: a mobile-first OpenCode interface that binds every network by default

The default hostname is 0.0.0.0 and no password step is described

The options block is where the deployment story is decided:

openportal [command] [options]

Options:
  -h, --help              Show help message
  -d, --directory <path>  Working directory (default: current directory)
  -p, --port <port>       Web UI port (default: 3000, auto-finds if busy)
  --opencode-port <port>  OpenCode server port (default: 4000, auto-finds if busy)
  --hostname <host>       Hostname to bind (default: 0.0.0.0)
  --name <name>           Instance name (default: directory name)

A default of 0.0.0.0 means the web UI listens on every interface the machine has, and the automatic port fallback means it will silently move to a free port rather than tell you the default was taken. Nothing in the documented flow asks for a token, a password or an account before the interface is reachable.

That matters because of what this interface is for. It lists sessions, opens chat with the coding agent, mentions files with @filename, and selects models, and its stated purpose is remote access from a phone. The README's answer to the exposure question is network level rather than application level: deploy it on a VPS next to OpenCode and reach it over Tailscale or a similar VPN.

That is a reasonable design, but it is a default, not a requirement, and a laptop on cafe wifi is exactly the case where the default matters.

Three features in the description never appear in the README

The repository description promises Git integration, an in browser terminal and isolated workspaces, alongside the mobile-first interface.

The README describes none of them. The feature list under Overview is five items: session management to create, view and delete sessions, a real-time chat interface, file mention support with @filename, model selection, and dark and light theme support. There is no terminal, no git panel, no workspace isolation or sandboxing anywhere in the overview, the use case section or the tech stack.

The tech stack does not fill the gap either. It is five entries: React Router as the framework, IntentUI for components, Tailwind CSS for styling, Nitro for the server, and the OpenCode SDK as the API client.

So the description describes a product one step ahead of the documentation. That may simply mean the work is in progress, but a reader who installs this expecting a terminal and a git view will find a chat interface with file mentions, and the README gives no indication that the other three are planned rather than abandoned.

Bun everywhere, with a Node floor still declared

Every command in the document is a Bun command. The quick start is cd into your project directory and run bunx openportal. The global install is bun install -g openportal. Development is bun install followed by bun dev, and the OpenCode prerequisite itself is offered as bun install -g opencode alongside brew install sst/tap/opencode.

The note under the quick start is blunt about the alternative: OpenPortal works best when paired with Bun, and Node.js may have some rough edges.

The manifest is more accommodating. The root package.json sets engines.node to >=20.19.0 and declares packageManager as [email protected], so the tool declares support for a runtime the documentation declines to recommend. Whether that floor is honoured is exactly the question the note raises.

The root package is private and named portal, while the executable everyone installs is openportal, so the published CLI name comes from one of the workspace packages rather than from the root.

Five commands, and one of them is called run

The command surface is short enough to read in one screen:

openportal                    # Start OpenCode + Web UI
openportal run                # Start only OpenCode server (no Web UI)
openportal stop               # Stop running instances
openportal list               # List running instances
openportal clean              # Clean up stale entries

Four of the five verbs act on state that outlives the process. list reports running instances, stop ends them, and clean removes stale entries, which together imply a registry somewhere on disk that openportal maintains and can disagree with reality about.

The naming is the odd part. openportal run starting only the server is not what run usually means, and there is no start verb at all even though the default invocation starts two processes.

Three port numbers appear across the document. The web UI defaults to 3000, the OpenCode server to 4000, and the example of launching the official interface uses 4096. Both of the portal's defaults auto-finds a free port, and the --name option defaults to the directory name, so two checkouts of the same project would collide by name.

The reason this exists is that the official UI is not built for a phone

The Why This Project section is the clearest part of the documentation. OpenCode ships its own web interface, launched with opencode --port 4096, but that interface is described as currently under development with two named limitations: it is not mobile responsive, and the mobile experience is limited.

The portal was built to fill that gap, from a personal need to reach an OpenCode instance from a phone without a laptop. That origin also explains the disclaimer at the top of the README, which states that this is a personal project not related to the sst/opencode repository or the SST team.

The use case section then describes the intended deployment in one line: put the portal on a VPS alongside OpenCode, then connect from a phone or another machine over Tailscale or a similar VPN. The diagram is two boxes, a phone and a VPS running both processes, with the tunnel between them.

So the security model is a VPN, and the operational model is one long-lived process on someone else's server.

Turborepo workspaces, and no test command anywhere

The root manifest is a Turborepo workspace: workspaces globs of apps/* and packages/*, with build, dev, lint, check-types and format scripts all delegating to turbo, plus a prettier pass over ts, tsx and md files. The only dev dependencies are prettier, turbo, typescript, and the Tailwind typography plugin.

There is no test script at the root, and none is mentioned in the development setup either. The pull request checklist still asks contributors to test their changes thoroughly, so the step is required and the command is not given. Code style is otherwise specific: TypeScript for all new code, existing component patterns in apps/web/src/components, Tailwind for styling, consistent naming, and proper types.

The contribution flow is the conventional one, and its clone command is a template with a placeholder:

git clone https://github.com/YOUR_USERNAME/portal.git
cd portal

Feature requests and general feedback do not go to the repository. They go to a form at oc-portal.userjot.com, so the roadmap lives outside the project history.

The release tags track the CLI, and they say so in their names

The three most recent releases are all prefixed for the command line tool: cli-v0.1.32 published on 2026-05-12, cli-v0.1.31 on 2026-05-09, and cli-v0.1.30 on 2026-04-04.

There is no tag for the web interface, so a reader cannot tell from the release list which version of the UI shipped alongside any given CLI build. The naming does at least remove the ambiguity in the other direction: these are CLI releases, and the web UI is versioned by whatever happens to be on the branch.

The newest tag lines up with the branch tip. The last push to the default branch is dated 2026-05-12, the same day and effectively the same moment as cli-v0.1.32, and no commit has landed since. As of early October that puts the whole project about five months without a push, which is worth knowing before adopting it as a daily driver.

The rest of the top level is small and conventional: .github/, .gitignore, .npmrc, LICENSE, README.md, apps/, banner.png, bun.lock, package.json, packages/, turbo.json, under the MIT licence the README states in one word.

Editorial conclusion

OpenCode Portal does one thing and does it in about five commands, and its reason for existing is a real gap: the official OpenCode interface is not built for a phone. Before deploying it, change the default hostname from 0.0.0.0 to a loopback address, put it behind whatever access control you already trust rather than assuming a VPN is the only layer, and remember that feature requests go to a form outside the repository, so nothing about the roadmap is tracked in git.

Frequently asked questions

Official sources

1. hosenur/portal on GitHub
2. License: MIT
3. Project website
4. README
5. Releases