- What is php-junior/nova-logs and what does it do?
- Nova Logs is a Laravel Nova tool that lets you browse and inspect your application's log files from the Nova dashboard instead of opening a terminal or SSH session. You can read entries with timestamps and log levels, search and filter content, follow recent errors, and download or delete log files when needed. Architecturally it is a small Vue front-end bundle plus a service provider and controller that reads files from storage/logs, with no migrations, queue workers, external services, or persistent state.
- How do I install nova-logs in my Laravel Nova application?
- Run composer require php-junior/nova-logs, then vendor:publish and nova:publish, and finally register the tool inside your NovaServiceProvider::tools() method. Wrap the registration in canSee() so only authorized users see it. First value is typically one to two hours plus a short read of src/ that doubles as your security review. Rollback is just as clean: remove it from tools(), run nova:publish, and composer remove.
- Which versions of Laravel and Nova does nova-logs support?
- The last release was October 2022 and presumes Laravel Nova 4 with Laravel 8-9 on PHP 8.x; behaviour outside that band is unverified. Run a throwaway-branch composer resolution spike against your actual Nova, Laravel, and PHP versions as a go/no-go gate before committing sprint time. If resolution fails on laravel/nova, check your repo credentials in auth.json or COMPOSER_AUTH before assuming a package bug.
- Do I need a paid Laravel Nova license to use this package?
- Yes. laravel/nova is a paid first-party product, so you need an active Nova license and working Composer credentials (auth.json or COMPOSER_AUTH) for nova-logs to resolve at all. Without Nova installed there is no candidate, full stop. A failed install resolving laravel/nova is a repository authentication problem, not a defect in this package.
- Is it safe to expose application logs inside the Nova dashboard?
- Logs routinely contain .env values, DSNs, bearer tokens, and PII, so the viewer changes access from 'someone with shell access' to 'anyone with a Nova login.' Nova authentication alone is not an authorization model here, so add a Gate or canSee check tied to a named ops role. Disable or tightly gate the download and delete endpoints, and confirm the file-serving code resolves against a fixed base path with no directory traversal.
- How do I restrict who can view logs with nova-logs?
- Register the tool conditionally, for example Tool::make()->canSee(fn ($request) => $request->user()?->can('viewLogs')), and define that ability in a policy or Gate for a named operations role. An environment flag such as config('services.nova_logs.enabled') keeps it dark in production while staging validates it first. Verify that the download and delete endpoints carry additional checks beyond basic tool visibility, and decide explicitly whether anyone gets those capabilities.
- Can nova-logs handle a very large log file like a 100MB laravel.log?
- There is no streaming and no index, so parsing happens in-request and a large file can exhaust memory_limit or hit the gateway timeout, taking down the Nova route precisely during an incident. Test against a production-sized log file in staging before you rely on it. Prefer daily channels with bounded retention, and treat the tool as a quick inspection aid rather than a way to page through unbounded logs.
- Does nova-logs work with multiple servers, containers, or autoscaling deployments?
- It reads files from the local storage/logs directory, so it fits a single-node or small-fleet Laravel monolith where Nova is already the internal operations console. On containerized or autoscaling deployments each instance has its own ephemeral log storage, which gives silently partial coverage and can be actively misleading. If you run more than one node, stop and use centralized logging instead.
- How do I configure which log files or paths nova-logs reads?
- Publish the package configuration with vendor:publish and set the log paths you want exposed; the config also governs access behaviour. Point it at your real channel layout, whether that is a single laravel.log or daily files with bounded retention, so the viewer matches what the application actually writes. Keep those paths fixed in configuration rather than user-controllable to avoid path traversal issues.
- Is nova-logs still maintained, and what should I use instead?
- Maintenance risk is material: a single maintainer, zero dependents, no vendor backing, and no release in roughly three years, so assume you own the code once installed. For most teams the durable answer is centralized logging with indexing, retention, alerting, and audit trails; treat nova-logs as an explicitly time-boxed stopgap with a sunset trigger. Exit is cheap, since removal is just tools(), nova:publish, and composer remove, but you should still decide who forks it when Nova 5 lands.