OpenCode Portal: a mobile-first web UI for a locally running OpenCode server
Mobile first batteries included web ui for sst/opencode. Git integration, in browser terminal, isolated workspaces.
At a glance
- What is it?
- OpenCode Portal wraps the OpenCode AI coding agent in a browser interface built for phones, and its README is explicit that it is a personal project aimed at remote access over a VPN. The CLI is small, the licence is permissive, and the real constraint is that the server it talks to is still under development upstream.
- Who is it for?
- Adopt OpenCode Portal if you already run OpenCode on a machine you reach over a private network and you want to check or steer a session from a phone. Skip it if you need a supported product, if your workflow depends on the official OpenCode web UI's feature set, or if you cannot tolerate a CLI that changes between patch releases.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 126 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap OpenCode Portal fills: OpenCode without a laptop
OpenCode ships with its own web UI. You start it with opencode --port 4096 and open a browser. The README states that this official interface is currently under development and lists two concrete problems: it is not mobile responsive, and the mobile experience is limited. That is the entire justification for the project. The author describes a personal need to reach a running OpenCode instance from a phone when no laptop is available, and the portal is the answer to that need rather than a general-purpose replacement.
The intended audience is therefore narrow. You are expected to be someone who already runs OpenCode, who wants to interact with sessions from a mobile device, and who is comfortable reaching a server over a private network. The README sketches the deployment as a VPS running both the portal and OpenCode, with Tailscale or a comparable VPN in between, so the phone never touches a public port. If you only ever use OpenCode from the machine it runs on, the portal adds a second process and a browser tab for no gain.
What the portal actually talks to: the OpenCode SDK and a local server
The portal is a client, not an agent. It does not contain a model, a tool runner, or a file indexer. According to the tech stack section, the pieces are React Router for the framework, IntentUI for components, Tailwind CSS for styling, Nitro for the server, and the OpenCode SDK as the API client. The CLI starts an OpenCode server, by default on port 4000, and starts the web UI, by default on port 3000, then the browser side talks to that server through the SDK.
That split explains most of the behaviour you will observe. Session management (create, view, delete), the real-time chat view, model selection, and file mentions written as @filename are all operations against a session that lives in the OpenCode server process, not in the portal. If the server stops, the UI has nothing to render. If you run openportal run, the README says you get the OpenCode server with no web UI at all, which is a useful way to confirm the boundary: the portal is disposable, the server is where state lives.
The README also notes that OpenPortal works best when paired with Bun and that Node.js may have some rough edges. That is a statement about the runtime the CLI and dev server expect, not a claim about the portal's protocol.
Getting it running: bunx, global install, and the flags that matter
The documented happy path is one command from inside the project you want the agent to work on. The README gives this example:
cd /path/to/your/project bunx openportal
Alternatively you install it once with bun install -g openportal and then run openportal in any project directory. OpenCode itself must already be installed, either with bun install -g opencode or, on macOS, brew install sst/tap/opencode. The README lists that as a prerequisite rather than something the portal handles.
The CLI surface is small enough to memorise. openportal starts both processes, openportal run starts only the OpenCode server, openportal stop stops running instances, openportal list lists them, and openportal clean removes stale entries. The options are -h or --help, -d or --directory to set the working directory, -p or --port for the web UI (default 3000), --opencode-port for the server (default 4000), --hostname to choose the bind address (default 0.0.0.0), and --name for the instance name, which defaults to the directory name.
Two details are worth pausing on. Both ports auto-find an alternative when the default is busy, so the port you asked for is not necessarily the port you get. And the default hostname is 0.0.0.0, which binds on every interface; the README's own deployment advice assumes you put a VPN in front of that, and the two positions only make sense together if you treat the network layer as your access control.
Where OpenCode Portal is the wrong tool
The clearest limitation is stated by the author rather than discovered by a user: this is a personal project, not related to sst/opencode or the SST team. It is an interface layered on top of someone else's agent, and the README itself points out that the official OpenCode web UI is under development. A moving upstream target plus a single-maintainer wrapper means feature parity is not promised and breakage is a normal outcome of an OpenCode release, not an incident.
The second limitation is the deployment model. The portal is designed for remote access, which means the machine running OpenCode has to be reachable from wherever you are. The README recommends Tailscale or a similar VPN, and that is not optional decoration: with the default --hostname 0.0.0.0 the web UI listens on all interfaces, so exposing it without a private network puts a shell-adjacent agent UI on the open internet. If you are not willing to run a VPN, the portal's main use case does not apply to you.
The third is runtime fit. Bun is the recommended path and the README warns that Node.js may have rough edges, so teams standardised on Node cannot assume the same experience. Finally, the interface is deliberately narrow: sessions, chat, model selection, file mentions, theme. Anyone expecting the portal to manage agents, repositories, or CI will not find those features described.
The alternative: the official OpenCode web UI
The honest comparison is with what OpenCode already provides. Running opencode --port 4096 gives you a web interface maintained by the OpenCode project itself, which means it tracks the agent's own API and ships with whatever the agent ships with. The portal's README concedes the official UI is under development and names its shortcomings as mobile responsiveness and the mobile experience generally. That is the whole trade: the official UI is closer to the source of truth and further from a phone screen; the portal is the opposite.
There is a second difference in shape. The official UI is a mode of the opencode command. The portal is a separate CLI named openportal with its own instance registry, its own stop and list and clean commands, and its own port allocation. That registry is what makes multiple projects on one host manageable, and it is also another thing that can drift out of sync with reality, which is presumably why openportal clean exists. If you run exactly one OpenCode instance on one machine and you are usually at a desk, the official UI is the shorter path. If the point is reaching that instance from a phone over a VPN, the portal is built for that and the official UI, per its own README, is not.
Maintenance, release cadence, and the MIT licence
The repository is active and not archived. The most recent push recorded is 2026-05-12, and the release list shows cli-v0.1.32 on 2026-05-12, cli-v0.1.31 on 2026-05-09, and cli-v0.1.30 on 2026-04-04. The pattern is informative: two releases three days apart, then a gap of about a month. Patch-level bumps in the 0.1.x line mean the CLI is pre-1.0, so flags and defaults can change without a major version signal. If you script around openportal, pin the version.
Upgrade cost has three parts. The portal itself is a bunx invocation or a global install, so updating is trivial. The OpenCode server underneath it is a separate install with its own release cycle, and the portal has to keep up with the SDK it consumes. Your own deployment, the VPS plus VPN arrangement the README describes, is the part that does not upgrade itself.
The licence is MIT, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are preserved. The README does not document a separate licence for the web app versus the CLI, so the safe reading is that MIT covers the repository. That is a description of the licence text, not legal advice; if you redistribute the portal inside a product, have someone qualified read the actual LICENSE file rather than this summary.
Editorial conclusion
Adopt OpenCode Portal if you already run OpenCode on a machine you reach over a private network and you want to check or steer a session from a phone. Skip it if you need a supported product, if your workflow depends on the official OpenCode web UI's feature set, or if you cannot tolerate a CLI that changes between patch releases. Before relying on it, run bunx openportal in a scratch project, confirm which ports it actually binds, and read the disclaimer at the top of the README: this is a personal project, unaffiliated with the SST team, so upstream OpenCode changes can break it without notice.
Community notes