Watch a working DBA for an afternoon and you will notice that the database GUI is not actually the center of the screen, because the center of the screen is a terminal, and the GUI is the thing that gets alt-tabbed to when somebody needs a query result pretty-printed or a schema diff eyeballed, so when we built Mongrel we started from the observation that an app which treats the shell as an afterthought is asking its most demanding users to context-switch between the tool they trust and the tool they tolerate, dozens of times a day, for no reason except that most vendors draw the product boundary at the SQL editor and stop.
The interesting question was never whether to include a terminal, since any app that manages SSH tunnels and Kubernetes exec sessions already has ninety percent of one, but whether the terminal would be a real citizen of the connection model or a panel that happens to spawn a shell, and those are very different products wearing the same icon.
A terminal profile is a connection, not a feature
In Mongrel a terminal is created the same way a database is, from Connections → New Connection → Terminal, and it sits in the same workspace tree as your Postgres clusters and Redis instances, which means it inherits everything the connection system already knows: groups, favorites, recents, tab restore, health pulses, and the OS keychain for its secrets, so an SSH profile for the production bastion is a first-class object you can favorite, search, and reopen after a restart rather than a command line you retype.
The transport list is honest about what people actually connect to, which is SSH with password, public key, or agent authentication for anything modern, Mosh for the laptop that roams between the office network and the train, Telnet for the appliance that predates your employment, Serial for the device console on the bench, and Local for the machine in front of you, and each of these is the same profile shape with the same session registry underneath, so logging, resize handling, and close behavior work identically no matter which wire the bytes leave on.
The part that makes it more than a convenience is that the terminal subsystem shares its trust state with the rest of the app, because Mongrel’s managed known-hosts file is shared between the interactive SSH terminal and the in-process russh tunnel backend that carries database connections through bastions, which means a host key you accepted while shelled into a jump box is already trusted when a database tunnel later crosses the same host, and a changed key is rejected in both places instead of just the one you happened to be watching, while the optional system-ssh tunnel transport defers to your own ~/.ssh/known_hosts, which is the split you would expect from a shell-out.
Why the tunnel and the shell being siblings matters
The workflow this unlocks is the one every operations person runs and nobody demos, where you are shelled into a host, you notice something odd, and you want to look at the database from the other side of the same bastion, and in the old world that means opening a second tool, re-entering the same host, the same port, the same key, and hoping the two tools agree about your ~/.ssh/config, while in Mongrel the database connection keeps its tunnel SSH settings on the connection itself, in the same registry and the same keychain as everything else, with three selectable tunnel transports depending on how much resilience you want: plain system ssh -N -L when simple is right, the in-process russh backend when you want a supervisor that notices a dropped tunnel and rebinds the same local port with backoff so the driver’s connection pool never sees the endpoint move, or autossh when you want the classic supervised behavior with OpenSSH’s own dead-peer detection, and the API Client goes one step further by referencing an existing terminal SSH profile directly, so the REST request to the internal service crosses the exact tunnel you already trust for shells.
Mosh gets the same treatment with its limits spelled out rather than discovered, because Mongrel deliberately uses your installed mosh binary instead of bundling one, the session bootstraps over SSH and then hands off to UDP so a sleeping laptop or a roaming Wi-Fi handoff does not kill the session, and the docs say plainly what Mosh cannot carry, namely port forwards, X11, and SFTP on the same session, so when you need a tunnel or a file transfer you open an SSH profile next to the Mosh one and both live in the same window.
The features that matter at three in the morning
A terminal earns its place during incidents, and incidents are where the secondary features stop sounding like checklist items, because the session logging and asciinema recording mean the command you ran at 3 a.m. is replayable at 9 a.m. when someone asks what changed, the quick commands keep the twenty incantations everybody has memorized slightly differently one click away and identical across the team, the triggers watch the scrollback for the patterns you care about so the log line you would have missed scrolls into an action instead, and the broadcast mode, guarded so you do not fat-finger DROP TABLE across twelve hosts, lets you run the same read-only diagnostic across a fleet of sessions that you selected on purpose.
Migration off the tools people already use was treated as a product problem rather than a documentation problem, so the import path reads PuTTY and KiTTY sessions from the Windows registry or their on-disk session files, walks SecureCRT’s recursive INI layout including its typed prefix format, and scans Termius’s SQLite store tolerantly enough to survive schema drift, and because SecureCRT can store passwords, that import is opt-in, decrypted backend-side, and written straight into the OS keychain without the plaintext ever crossing into the renderer, which is the level of paranoia a session importer deserves when the thing being imported is your production access.
And because the terminal is the same app as the rest of the workbench, the adjacent workflows stop being separate tools entirely, so the dual-pane File Manager gives you SFTP and SCP off any SSH profile with a durable transfer queue that survives a restart, Kubernetes exec and debug containers put a shell into a pod without leaving the window where you were reading its logs, and the AI assistant can summarize a noisy terminal session when you inherit someone else’s three-hour debugging scrollback and want the two lines that mattered.
What it costs, said out loud
The honest tradeoff is that a terminal inside a workbench will never replace the terminal as a way of life, and it is not meant to, because tmux muscle memory, a decade of dotfiles, and the shell you have tuned since 2009 are not things a GUI should try to absorb, so Mongrel’s terminal is instead the answer to a narrower question: when the database, the tunnel, the file transfer, and the cluster are already in one app, why should the shell be the one surface that makes you leave, and the cost we pay for answering it is maintenance surface, since every transport is a real integration with real edge cases, which is exactly why Mosh and autossh stay user-installed binaries we orchestrate rather than code we vendor and pretend to understand better than their authors.
Twenty years ago the equivalent move was keeping PuTTY and WinSCP and your database admin tool pinned to the same taskbar and calling it a workflow, and the modern equivalent is that the boundaries between those three were always arbitrary, so the shell got a seat at the same table as the query editor, and if that sounds like the way you already work, the download is at visorcraft.com/download and the rest of the workbench story is at visorcraft.com/workbench.