- How do I install filaforge/filament-terminal-console in a Laravel Filament app?
- Install it with Composer using composer require filaforge/filament-terminal-console, then register the plugin on the target Filament panel in your PanelProvider. Because the package is pre-1.0 and the published metadata does not include a full setup guide, pull the exact registration snippet from the repository README before wiring it into an existing panel. Plan to publish and review the config file and place the console page behind a policy or role gate as part of the same change.
- Which Laravel, PHP, and Filament versions does this package support?
- The v0.1.2 release metadata does not publish a compatibility matrix, so confirm the Laravel, PHP, and Filament constraints on Packagist before adopting it. Since this is a Filament plugin, the Filament major version is the constraint most likely to break your panel, so check that first. Pin exact versions in composer.json and validate the install in a throwaway branch rather than floating the constraint.
- How do I restrict which users can open the terminal console?
- The package advertises configurable access, and the practical approach is to combine a Filament policy or Gate with the plugin's own config-level restrictions. Register the plugin only on the panels that actually need a terminal so the page does not exist on customer-facing panels at all. Enforce the same rule per environment as well, so a staging panel and a production panel do not inherit identical access.
- Can I allowlist commands or disable shell execution while keeping the UI?
- The package description mentions command controls, but the release metadata does not confirm whether an allowlist is enforced at execution time or only used to hide options in the UI. Treat UI-only filtering as insufficient, because the real control boundary is the process that actually runs the command. Verify this in a spike before relying on it, and if no hard allowlist exists, gate the capability behind a stricter policy or do not expose it.
- Is it safe to run a web terminal plugin in production?
- An in-panel terminal turns any compromised admin account into host-level command execution, so it should be reviewed as a privileged operations component rather than a normal CRUD plugin. Confirm how commands are executed, which OS user the child process, timeout, and output buffer limits apply, and whether every invocation is attributable to a named user. Restrict it to non-production environments first, and only widen access after a security review signs off.
- How does the console stream command output, and what are the timeout and buffer limits?
- The package is described as streaming output into the console UI, but the release metadata does not state whether execution happens synchronously in the request, in a queued job, or in a persistent PTY session. That detail determines how long-running commands behave and whether a request can hang or time out. Ask the maintainer or inspect the source, then set explicit timeouts and output caps before letting anyone run anything expensive.
- Does the package log commands and their output for auditing?
- Audit logging is not described in the available release metadata, so assume it is not provided out of the box. If you need attribution, plan to record the user, the command, the timestamp, and the captured output in your own log channel with a defined retention period. That requirement alone is often the deciding factor for whether a browser terminal is acceptable in a regulated environment.
- Why is v0.1.2 missing a changelog, and is it safe to upgrade?
- The v0.1.2 release notes contain only an auto-generated compare link from v0.1.0, with no substantive changelog body and no visible v0.1.1 tag in that range. That means you cannot tell whether the release is a patch, a bug fix, a security fix, or a breaking change, which blocks routine upgrade consumption. Pin the exact version you have reviewed and diff the source before bumping, since 0.x SemVer guarantees nothing about backwards compatibility.
- What are the alternatives to an in-panel terminal for Laravel admins?
- Common alternatives are SSH plus artisan and Tinker on the host, a local tool such as Tinkerwell, or a small custom Filament page that exposes a fixed set of safe, pre-defined artisan commands. Those options trade convenience for a much smaller attack surface, because nobody types arbitrary shell input into a browser. This package is worth considering only if you are already standardised on Filament and can hard-gate access and commands.
- How do I remove the plugin, and how is it tested?
- Because integration is limited to registering the plugin in a PanelProvider plus a published config file, removal is a matter of unregistering the plugin, deleting the config, and running composer remove, so the blast radius is small. The available metadata does not document a test suite, so review the repository for coverage and write your own feature tests that assert the console page is unreachable for unauthorised users. Verify the licence and provenance of the filaforge namespace before shipping it in a client deliverable.