Web Terminal Laravel Package

Product Decisions This Supports

• Build vs. buy for internal ops tooling. If your roadmap includes any "admin needs to run a quick artisan/ls/tail on the server" workflow, this package is a credible buy candidate versus building a whitelisted command runner + audit log + Filament UI from scratch. The included terminal:install scaffolder, Terminal Logs resource, and stats widgets represent weeks of undifferentiated work you can skip.
• Feature scoping for "safe shell" vs "full shell." The maintainer's decision to freeze Stream mode (full PTY over WebSocket) and split it into a separate plugin is a useful signal: treat "whitelisted command execution" and "interactive TUI shell" as distinct roadmap items with distinct risk profiles, not one feature. Product framing, threat model, and approval gates should differ for each.
• Permissions and compliance model. Enum-based TerminalPermission and per-instance allowedCommands give you a concrete artifact to point to in security reviews and SOC2/ISO control narratives — "operators can only execute a documented allowlist, and every command is logged."
• Multi-tenant SaaS feature expansion. The --with-tenant migration and built-in tenant isolation open a use case for exposing terminal-adjacent tooling (or restricted command surfaces) inside customer workspaces — but only after deciding whether that's a support capability or a customer-facing one (see risk below).
• Roadmap risk tracking. A 30-star, single-maintainer package with a major version churn (v1→v2 dropping Laravel 11 / Filament 4) and a scheduled feature removal is a dependency risk line item you should track on the roadmap, not a silent assumption.
• Documentation/onboarding decisions. The --allow-secure-commands default, install flags, and migration guidance give you a template for "safe-by-default" adoption paths in your own platform team's tooling.

When to Consider This Package

Good fit when:

• You're already on Filament 5 / Laravel 12–13 / Livewire 4 — the integration story (WebTerminalPlugin::make(), embeddable Schema component, logs resource) is the primary value prop.
• Your use case is whitelisted, auditable command execution (restart a queue, tail a log, run a specific artisan command), not "give ops a terminal."
• You need audit trails and can defend the allowlist in a security review.
• You have internal technical users only — this is not a customer-facing surface.
• You want a starting point (scaffold, migration, logs) and are comfortable pinning a version and owning upgrades.

Look elsewhere when:

• You're on Laravel 11 / Filament 4 and unwilling to upgrade — you'd be locked to v1.x, which is now legacy.
• You need full interactive shell / TUI apps (vim, htop) — that's the frozen Stream mode, migrating to a separate plugin; don't build a roadmap around it here.
• You need enterprise support, SLAs, or a large maintainer base — 0 dependents, 30 stars, single author.
• Your security posture forbids web-based shell execution regardless of allowlisting — no package choice fixes that.
• You need non-Laravel or non-Filament admin surfaces.
• You need SSH to a large fleet with credential management as a first-class feature — SSH here is present but thin; you'd likely want a dedicated bastion/session manager.

Minimum adoption gate: pin ^2.0, run terminal:install --no-tenant (or --with-tenant if applicable), start with --allow-secure-commands only, enable logging, restrict the terminal page to a named role, and review the allowlist with security before any production exposure.

How to Pitch It (Stakeholders)

To executives / leadership:

We can give trusted operators a controlled way to run a small, approved list of server commands — restarting queues, checking logs, running specific artisan tasks — from the admin panel, without giving anyone a raw shell. Every command, output, and error is logged, and access is gated by an explicit command allowlist and a permission enum. It's a ~30-day build we'd otherwise own; adopting the package gets us there in days with an audit trail built in. Key caveats: it's a small open-source project (single maintainer, ~30 stars), so we pin the version, restrict it to technical staff, and treat upgrades as planned work. The packaged "full interactive shell" feature is being deprecated into a separate plugin, so we intentionally are not dependent on it.

To engineering:

Drop-in Filament plugin — WebTerminalPlugin::make() and you have a terminal page plus a searchable Terminal Logs resource with stats. Use WebTerminal::make()->local()->allowedCommands([...]) for embedded scenarios, or SSH for remote hosts. Interactive PTY/tmux works for artisan tinker and queue:work. Requires Laravel 12–13 / Filament 5 / Livewire 4 / PHP 8.3 — if we're on older, we're stuck on v1.x. Default install is --allow-secure-commands (readonly-ish); do not ship --allow-all-commands. Enable logging and multi-tenancy only if we actually need tenant isolation. Ignore Stream mode — it's frozen and moving to a separate plugin; don't architect around it. Watch the v2 major-version removal of Stream when planning upgrades.

To security / compliance:

The package is explicit that it provides real shell access to real servers and ships with an "use at your own risk" disclaimer. Our mitigations: allowlist per terminal instance, enum-based permissions, mandatory audit logging (commands, outputs, errors, connections), rate limiting, session inactivity timeout, and access restricted to a small named role. We treat it as an internal-ops tool, not a customer surface. Reviewable allowlist is the primary control; logging is the secondary.

Bottom line: strong internal-ops fit if we're on Filament 5 and want a fast, auditable, whitelisted command runner; weak fit as a strategic dependency, a customer-facing feature, or a full-shell solution. Adopt with version pinning, a security-reviewed allowlist, and a small blast radius.