Next Terminal: A Bastion and Session Auditing System for RDP, SSH, VNC and Telnet

The problem Next Terminal solves: recording who did what on a remote host

Every engineer who has SSHed into production leaves a trail in shell history, and shell history is not an audit record. It does not capture what happened inside an RDP session, it does not survive a wiped home directory, and it says nothing about who was behind the key. Next Terminal is built around the other approach: traffic goes through the system rather than directly to the target, and the session itself is recorded so it can be replayed later. The README describes it as "a simple, secure, and user-friendly interactive auditing system" supporting RDP, SSH, VNC, Telnet and HTTP, aimed at enterprise IT environments for "session recording, audit tracking, and compliance reporting".

The intended audience is the operations or security team that has to answer a question after an incident: which account opened that host, when, and what did it type. The repository topics confirm the framing: audit, bastion-host, jump-server, privileged-access, session-recording, zero-trust. If your team already runs a jump host but cannot produce a replay of a suspicious RDP session, that gap is what this project targets.

One thing to settle before anything else. The README states that starting with v2.0.0 the backend code is no longer open source. What sits in this repository is the TypeScript frontend (the package.json declares React 19, antd 6, xterm 5 and the Guacamole common JS bindings). So the auditing logic you are trusting is not code you can read. That is a deliberate commercial choice, and it changes how you evaluate the project: you are adopting a product, not a codebase.

How the pieces fit: a TypeScript frontend over a closed backend

The repository layout is a single-page application. Top-level entries are index.html, vite.config.ts, tailwind.config.js, tsconfig files, a src directory and a scripts directory. There is no Go module, no Dockerfile and no server directory, which matches the note about the backend. The build script runs tsc followed by vite build with NODE_OPTIONS=--max-old-space-size=6144, so the frontend is expected to be compiled with a raised Node heap.

The protocol work is delegated. @dushixiang/guacamole-common-js at version 1.6.0-fix is a fork of the Apache Guacamole client library, which is what makes RDP and VNC possible in a browser tab. Terminal sessions use @xterm/xterm 5.5.0 with the canvas, fit, search and webgl addons. Session replay uses asciinema-player 3.17.0, and video playback uses plyr and plyr-react. Authentication includes @simplewebauthn/browser 13.3.0, so WebAuthn is part of the login surface.

The data flow that follows from this: a browser connects to the Next Terminal server, the server opens the outbound connection to the target host, and the frontend renders the stream through Guacamole or xterm while the server records it. The frontend never talks to the target directly. That is the whole point of a bastion, and it is also why the closed backend matters: the component holding your credentials and recordings is the one you cannot inspect.

Two audit scripts in package.json are worth noting because they reveal the maintenance burden of an i18n-heavy UI: audit:i18n runs scripts/i18n-audit.mjs, and audit:antd:ci runs scripts/scan-antd.mjs with --fail-on-findings, suggesting the project gates its build on component-library usage.

Installing Next Terminal: what the repository does and does not tell you

The README does not contain install commands. It says: "Refer to the installation guide here" and links to https://www.next-terminal.com/docs/. That is the only install instruction in the repository, and it is worth being blunt about the consequence: you cannot reproduce a deployment from this repository alone. The frontend source is here; the server you would deploy is not.

What you can do locally is build the frontend. The package.json scripts are the source of truth for that. Clone the repository, then install dependencies and start the Vite dev server:

npm install
npm run dev

The dev script is simply vite, so you should see Vite print a local URL in the terminal. Point a browser at it. Without a backend the application will not be able to open sessions, because as described above the frontend does not connect to target hosts itself.

To produce a static build instead, the build script runs the TypeScript compiler and then Vite, with a raised Node heap:

npm run build

Because the script sets NODE_OPTIONS=--max-old-space-size=6144 inline, this is a POSIX shell form. On Windows you would need to set the variable separately rather than relying on that line. The build output goes to the default Vite directory, and npm run preview serves it.

There is also a type-check-only path, useful in CI where you do not want a full bundle:

npm run lint

This runs tsc -p tsconfig.app.json. For a real deployment, follow the linked documentation rather than the repository, and treat the version you deploy as a product release: the recent tags are v3.9.1 (2026-09-11), v3.9.2 (2026-09-13) and v3.9.3 (2026-09-17), so releases arrive frequently and you should pin one.

Where Next Terminal is the wrong tool, and what the README leaves unsaid

The clearest limitation is the licence and source boundary. The repository is Apache-2.0, but the README states the backend is no longer open source from v2.0.0. If your organisation requires that every component handling credentials and session recordings be auditable, this project fails that test regardless of how good the recording is. You would be running a closed binary that terminates your SSH and RDP connections. That is a normal arrangement for commercial bastion products, but it is not normal for a project whose GitHub page carries an Apache-2.0 badge.

Second, the README asks you to agree to the LICENSE before downloading, using or distributing, and says the project is provided "as is" without warranties. It also recommends consulting your IT administrator before deploying inside a corporate network. Both lines are doing real work: the first means the licence terms are not fully described by the Apache-2.0 identifier alone, and the second is an acknowledgement that a bastion changes your network topology and failure modes.

Third, the support model is bounded. The README lists [email protected] as "after-sales within 1 year of purchase, workdays 10:00-18:00", with replies on the next workday outside those hours. If your compliance requirement is a multi-year retention and support commitment, a one-year window from purchase is a constraint you should price in. The README does not document rollback, backup or restore procedures for the recordings themselves.

Finally, consider the failure mode of the bastion pattern itself. If Next Terminal is the only path to your hosts and it is down, nobody reaches anything. The README says nothing about high availability, so treat that as unverified and design around it, or keep a break-glass path that bypasses the system entirely.

Next Terminal compared with an Apache Guacamole deployment you build yourself

The obvious alternative for the same job is Apache Guacamole. The comparison is unusually direct here because Next Terminal's browser-side protocol handling already depends on a fork of the Guacamole client library, @dushixiang/guacamole-common-js 1.6.0-fix. The two share DNA.

The difference is where the work sits. Guacamole gives you guacd and a web application under an open source licence, and you assemble the rest: user directory, connection inventory, recording storage, retention, and the audit interface your compliance team will actually accept. Next Terminal ships that assembled product, with a dashboard, access views, session replay through asciinema-player and video playback through plyr, and a frontend you can read. What you give up is the ability to inspect or modify the server side, and the freedom to patch a protocol bug yourself.

There is a second axis: protocol coverage. Guacamole's core strength is RDP, VNC and SSH through guacd. Next Terminal's README lists RDP, SSH, VNC, Telnet and HTTP, so Telnet and HTTP proxying are part of its stated scope. If you still have Telnet-only network gear, that matters.

A third option worth naming is simply a hardened OpenSSH jump host with session logging. It is far less work to stand up, it is fully auditable, and it covers SSH well. It does not give you RDP or VNC replay, and it does not give you a web console with an access inventory. Choose that if SSH is your only protocol; choose Next Terminal if the browser-based, multi-protocol recording is the requirement and the closed backend is acceptable.

Maintenance, upgrade cost and licence questions to settle before deploying

The repository is not archived, and its last push was on 2026-09-21, one day before the date used for this assessment. Releases are frequent: v3.9.1, v3.9.2 and v3.9.3 all landed within a week of each other in September 2026. That cadence cuts both ways. You get fixes quickly, and you also get a moving target. Pin a tag and read the release notes before moving, because there is no documented upgrade or rollback procedure in the README.

The frontend dependency list is large and version-pinned to major releases that move: React 19, antd 6, Vite with @tailwindcss/vite 4, i18next 26, react-router-dom 7. Each of those majors carries its own migration cost, and the audit:antd:ci script with --fail-on-findings suggests the project enforces its own component conventions in CI. If you fork the frontend, you inherit that maintenance load.

On licensing, the Apache-2.0 identifier covers the code in this repository. The README separately instructs you to read and agree to the LICENSE file before downloading, using or distributing, and notes the backend is closed from v2.0.0. Whether your use is covered by Apache-2.0 alone, or by additional terms attached to the distributed product, is a question for your own counsel; the README does not resolve it, and neither can this article. The practical step is to read the LICENSE file in the repository and the terms on next-terminal.com before you put it in front of production credentials.

Frequently asked questions about Next Terminal

The questions below are answered only from the repository and README. Where the material is silent, the answer says so rather than guessing.

Editorial conclusion

Next Terminal fits teams that need recorded, replayable sessions across RDP, SSH, VNC, Telnet and HTTP and are willing to accept a closed backend and a documentation-only install path, since the README sends installation to next-terminal.com/docs. It is the wrong choice if you need to read or patch the server side, if you cannot consult an IT administrator before placing it inside a corporate network, or if you need a documented rollback plan, which the README does not provide. Before adopting, verify three things: what the install documentation at next-terminal.com/docs actually requires, what the LICENSE file you are asked to agree to permits for your distribution case, and whether the paid support window (one year of after-sales from purchase, workdays 10:00 to 18:00) matches how long you intend to run it.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. next-terminal/next-terminal on GitHub
3. Project website
4. README
5. Releases